Welcome to the fourth page of a handbook on self-hosting. Begin here. Read the previous page here. On this page, we’ll cover how to handle self-hosting administration, from system updates to making sure your containers are in tip-top shape.

Topics covered on this page

What's self-hosting administration all about?
Updating your Docker containers
Pruning your Docker system
Using Docker Swarm to strengthen your infrastructure

[cta_inline]

What's self-hosting administration all about?

Generally speaking, a self-hosting infrastructure requires quite little in the way of maintenance and upkeep. Of course, the stakes depend entirely on your unique application.

I’m using my self-hosting stack only for myself, and I’m not running any services I couldn’t go without or duplicate with another app/service I already have on my machines, so I don’t worry about things like nine nines of availability. For example, my self-hosted Nextcloud folder also syncs up with Dropbox via a symbolic link on my desktop, so all my critical files are within reach if (and probably when) I bring my VPS down.

Here are some of my recommendations:

Update your primary system regularly. I think once a week is fair enough—you’ll get the latest security updates, which will help keep your VPS secure. You can also enable automatic updates on Ubuntu servers with two simple commands:

$ sudo apt-get install unattended-upgrades
$ sudo dpkg-reconfigure unattended-upgrades

Check running containers. If you’re already hopping onto your VPS to perform an update, while not also run a quick docker ps?. I’m embarrassed to admit this, but I’ve created test servers with… lax security practices, only to find my VPS running some cryptocurrency miner via a Docker container. A quick ps ensures you know what’s going on, whether that’s a breach or merely a container gone awry.

Create backups! While you can destroy and recreate containers at will without losing your data—thanks Docker volumes!—you can’t predict a catastrophic event. I use a second server as a backup server, and use Borg to synchronize files from one to the next. There’s no automatic restore process, but at least the data duplicated. We’ll soon be posting a guide on backing up your VPS to your local machine, and I’ll be sure to link it here.

Of course, you’ll also want to do some best practices on security, such as running a firewall and something like fail2ban to block malicious access attempts.

And a few things to avoid:

Don’t update the packages inside of your containers. While it’s possible to actually “log into” your running Docker containers using docker exec -it ..., and in theory you could then perform an apt-get update && apt-get upgrade inside of them, I strongly discourage this. Many Docker images are crafted using specific package versions and configuration files, which could conflict or be overwritten via an upgrade. We’ll cover smarter updates in a moment.

Stay away from the docker-compose down command. Running docker-compose down will stop running containers and delete them, and then delete associated volumes and networks. Your data should remain within the volume folders that you specify in your docker-compose.yml file, but it’s better to be safe than sorry. If you need to stop containers, use docker-compose stop instead.