My deploy is a target in a Makefile (make deploy) that builds system-installable packages (for archlinux, because that’s what I deploy on, but it could reasonably be adapted for anything else if the tooling exists), copies the packages over to my machine via scp, and uses ssh to both install the packages and restart the necessary services on the target.

Pros:

• very minimal and easy to understand (it’s a few lines of bash)
• easily retargetable (all I need to do is shift my credentials and the machine specification and it can deploy to a different target)

Cons:

• it is not through CI/CD (though it could easily be if I actually set a runner up, as all the CD step needs to do is run make deploy)
• if you don’t like using system package-managers, that’s a con (personally, I like them)

This has worked really well for me for quite some time. Though, to be fair, my website isn’t hugely complex.

All the best,

-HG

I wouldn’t be so quick to write off static websites. The use cases you listed are entirely do-able with a static site, and modern generators (hugo, jekyll, pelican) are miles ahead of where static site generation was even a few short years ago.

I serve my blog with Github Pages, so deploying is git push (wrapped in a script that does some other stuff like re-generating the static files). Things like comments (or photo galleries) can be embedded if you really want to go that route. Though there are often clever ways to accomplish stuff like this anyway (e.g staticman for comments).

I use Caddy to serve static files. I couldn’t be happier with it: totally takes care of https which was a pain even with nginx and let’s encrypt.

Digital ocean droplet + namecheap = best money I’ve ever spent.

Edit: Oh yeah and rsync for actually moving the files. (Way faster than scp since it does diffing)

• Lobsters has an ansible playbook.
• Barnacles is Heroku’s git-based deploy. Wanted to try nix/nixops but bounced off pretty hard.
• My blog is in a git repo; 95% of the time I’m using Wordpress’s update mechanism and committing results, rest of the time I ssh in and vim because it doesn’t matter if I blow it up for a few minutes.
• Well Sorted Version deploys via a ruby script that’s mostly just rsync -aPv --del. This is pretty typical for most of my little projects - I put it in a script because I know I’m going to forget steps after a week or two. Builds the site, minimizes assets, any random odds and ends, rsync. Could be a bash script, but there’s always that one thing I want a conditional or a regexp for and Ruby’s more comfortable for me.

The dynamic stuff is always PHP. I never love it, but it’s reliable, doesn’t want to be a framework that takes over the site, and there’s always a snippet or answer one google search away.

I have a VCS for the source, and a VCS for all of my websites deployed HTML/binaries/etc served on a single host(which is basically all of my personal stuff)

So my CI/CD will take commits from each individual src repo, build the code and then commit it to a subdir of a different VCS repo. Then my host runs a VCS checkout every 5 minutes from the combined deployable repo, and runs a script in that repo that will restart anything if needed.

so an example:

VCS blah.com sources in repo A VCS example.com sources in repo B deployable code for example.com and blah.com in repo C

when I push a commit for blah.com in repo A, my CI/CD will pull it down, and pull down repo c. then build and do any tests, and then push the built code into repo C under a blah.com/ dir.

Then every 5 mins my VPS host pulls down repo C and runs Make that will restart anything if needed. (under a special www-cron user)

This way repo C has all of my deployable websites and history of what has been deployed. Also, this way my CI/CD doesn’t get direct access to my VPS host. Since I don’t run the CI/CD (it’s a SAAS ) I don’t have SSH keys out there waiting to be gobbled up by the latest hack.

slowcgi(8) on httpd(8) on OpenBSD works for me :~)

CGI (and fastcgi) still exists, but even very simple frameworks often use http now, with nginx serving as a proxy.

• Personal blog is make/rsync https://github.com/caius/caiustheory.com/blob/master/Makefile#L24-L38
• Personal website is hand-edited on server, committed into git repo

Webserver for both is nginx on a Debian box.

I host Wordpress for a friend on a FreeBSD VM, that’s using nginx & php-fpm behind it via fastcgi. Did similar when I was hosting a forum for my mother a few years back too.

I dump my files into /var/www/html/ for Apache and that’s the end of it. I write all of the HTML, SVG, and whatnot by hand and when I want to add a new article I copy the HEAD and all of that from a previous article. Then, I add the article to index.html and that’s the end of it.

There is one question I have, however. I’ve recently wanted to add the ability to comment on my website and the current mechanism is sending me an email, as explained here, but this seems a high enough barrier that I’ll receive very few, as I’ve received none so far. I figured it would be sufficient to add a form to that page, but I don’t know how to attach an arbitrary program to a form. As I’ll be doing this all manually, it would even be enough to simply have Apache log the POST requests sent to a certain URL, but every option I’ve come across so far requires me to either install something or perform some heavy configuration, both of which I’m reluctant to do.

I suppose I could tell it to vomit the POST to a port I have listening, but surely there’s a better way, right?

I have a git post-receive hook on my webserver that checks out the latest master to /var/www. It’s a little naive at the moment because it only handles content changes (rather than code changes, which would require the hook to re-start a node process).

It’s only for my personal site, but I’ve been honestly surprised at how well it has worked for the past few years. Just git push web master and the site is deployed.

All of my current stuff is in Ruby. I set it up so that I can git push from my local dev environment to the server. I then have a shell script on the server that I ssh in and run that updates the bundle, runs any migrations, builds the new assets, and restarts the Puma server process. It’s been pretty simple and painless so far.

Personally, I really like Netlify for publish-and-forget types of sites. You point it to a Git repo, and configure it to build your static site from it - be it with a static site generator or by copying some files. Regarding small dynamic parts: they offer ways to include dynamic elements, like a submit form, and take care of handling the data for you. I haven’t tried it myself but it looks quite simple. So, deploying a static site like my blog to Netlify simply consists of committing some changes and pushing to master.

For the “middle ground”: I use Gunicorn (a WSGI server which runs a few threads continuously and runs your Python code when a new request arrives) behind Nginx. Systemd takes care of keeping them running and restarting if needed.

Deploying to this setup is easy as with most low-traffic sites: you pull the latest changes to a repo on the server, and restart the systemd unit responsible for Gunicorn. All of this can be automated using Fabric, so there’s no need to SSH to the server manually.

Also handy, but behind a bit of a learning curve: using Zappa or the Serverless Framework to run your dynamic code in something like AWS Lambda - it’s very cost effective, and you don’t need to do any of the sysadmin work described above.

post-receive git hook

curlftpfs -ossl ftp.host.tld /tmp/x
cp oldpost.htm newpost.htm
vi newpost.htm

I use to work with Drupal, a php/sql cms/framework, and as a result I still use it years later (funny how that works). While professionally I dealt with CI/CD around this subject, I didn’t want that much overhead for my personal blog so it’s effectively a docker container with my site’s code mounted from the host’s filesystem. I don’t run a machine or vm dedicated to it, so there’s other virtualhosts at play too. I have a few containers with the following:

• Nginx - internet-facing, ssl termination, proxies different domains to different machines.
• Varnish - cache server - for domains that use caching, nginx proxies the request here where it can be again proxied to the actual app on cache miss. I use this separate instance instead of plain nginx caching because Varnish is far more flexible - the configuration file uses a DSL that is translated to a C program and compiled at runtime.
• Nginx again - actually, nginx and php in one docker container, along with the actual app code. It talks to mysql but I don’t exactly remember how I built that. It’s probably in docker as well.

What I like about this setup is that it gives me both the flexibility of docker for dependency management and the simplicity of “classic” web hosting techniques. My git repo for the site’s assets also has a scripts folder with things like pull_prod_db.sh, pull_prod_files.sh, push_prod_code.sh, run_nginx_local.sh etc.

I of course use Let’s Encrypt, and using that centralized nginx instance let me have a little fun with how I manage that. Since it’s centralized, I was able to route all requests concerning the /.well-known/ path prefix used by Let’s Encrypt to one instance of a custom LE client. Obviously, this is all rather pointless now that LE supports DNS challenges too, but this setup predates that.

Now if only I had as much patience for writing content for the blog as I did building the infrastructure - https://dpedu.io/

Edit: OP asked about deployment, and I suppose I didn’t answer that directly. The custom docker images flow through a self-hosted registry. The machine running them is configured by puppet. And the site’s code is manually uploaded with rsync.

When I started I ran a small blog hosted on Heroku so I got used to ‘git push heroku master’. I wanted to cut costs from the $7/mo Heroku was charging since I wasn’t making any money, so I switched to a $5 DO droplet but wanted to keep the simplicity of ‘git push xxx master’ so I installed dokku just to have a Heroku-like interface.

After that I realized my $5 droplet had extra capacity for some other side projects so deploying those to the same server was simple thanks to the decision to use dokku.

What’s your purpose? What’s the velocity of changes to the content of the website? Who needs to make changes or submit content? Can the editor(s) use Git? Can you use a static website that consumes dynamic APIs, e.g. comments from Disqus or similar or something self-hosted?

Unless you’re learning or adamant about running your own server, don’t. It’ll detract from your main goal, which likely is to produce content. There are enough free hosting options out there now for static content that running your own static content engine should be an exercise served for learning.

I’ve been meaning to write this up, but I have two personal static websites (one is a blog). They both use git and GitHub for source control and repository management, build with Hugo inside CodeBuild, and deploy to S3 and CloudFront with ACM certificates. (I work for AWS, which is part of why I decided to use a bunch of AWS services, but this is my own paid personal account.)

I’ve been using Dokku to deploy my site.

I edit the Lua code and then I do kill -s HUP $OPENRESTY-PID

For usesthis.com, I push a commit to master on GitHub, which fires a webhook to my server, which then pulls from the repo and generates the site with my own static site generator.

My personal site is completely static and hosted on GitHub despite incorporating a small webapp. Aside from using GitHub for hosting, I use Cloudflare for my domain name, DNS, and CDN.

Said webapp is an American Sign Language dictionary for mathematics consisting of an interactive image/video gallery. Everything is written in HTML5 and CSS without a line of JavaScript.

I use sitecopy for uploading my personal pages, and php for scripting, it is available practically everywhere, and easy to use.

I just ssh into it and overwrite the old rust binary/php stuff. This way I know that there’s only one way to change stuff: get SSH access. No repo-overtake etc. Also nginx in front of everything, as it’s easier to manage TLS this way and remove possible attack surface. Nginx will also cache if required and serve static stuff. I have some lighttpd-reverse-proxy stuff going on as lighttpd can do per-host traffic limiting ( downloads..)

1. I use ansible NGINX role [1] to deploy a web server

It automatically downloads and installs on target host an uptodate version of NGINX

It allows me to me to specify where my site files are (usually in /var/www/

It allows me to configure a bunch of settings (time outs, how to handle URL’s without www, and so on – all by passing arguments to that NGINX role)

It allows to specify where your certificate/private keys files are (I usually put mine in /etc/letsencrypt/ )

2. I created my own ansible role that I call ‘local_build’ that basically runs a build of my webapp, and deposits it into a predetermined location on my build machine.

3. Finally, my 3rd ansible role copies certificates and then webapp files (from 2) onto the target host(s)

so The playbook executes (1), (2), (3)… also I can manually execute just (3) (update certificate).

The NGINX role works well on any of the Linux distros, there is also support for FreeBSD (and maybe OpenBSD), there will be some updates to the role – probably shortly to fix some issues on FreeBSD.

I rarely have have a need to login into the target host, only if I need to debug (although we are pre-prod still).

[1] https://github.com/nginxinc/ansible-role-nginx

A linode + namecheap and nginx. Not really much else to say.

rsync -av $HOME/remote/$DOMAIN_NAME/ my_web_ho.st:www/$DOMAIN_NAME

I have a cheap VPS from Contabo that hosts all of my hobby and personal sites. They’re all Elixir applications, deployed using edeliver

rsync