3 ms·

Start by reading about docker and docker compose. You will have almost everything in docker containers. Pay attention to the basic networking part. Especially

Start by reading about docker and docker compose. You will have almost everything in docker containers. Pay attention to the basic networking part. Especially where it says that you can refer to a container by name in your configurations Then have a look at Caddy, a web server, to use it as a reverse proxy. You will end up with very simple configurations Read about reverse proxy in caddy's excellent doc. Test on a machine in your lan first, by installing docker on it and administrating it via ssh,b this will be how you will interact with your VPS. Install the containers you are interested in and configure them. When you decide to move them to your VPS, make sure to use long passwords (and MFA if available) sans expert only 80 and 443 ( both will be marked by caddy to he right way ootb). The containers for week known apps are usually secure by default, and they highlight in their docs what you ansolutely need to change. ... After some time, when you finally understand everything, you will reorganize everything. No worries, containers are made for that, your data is independent. ... Then you will realize that you actually need an OS that is almost empty except for docker and a backup program (easier to use it at the OS level than as a container). You should consider borg. ... Than you will move to home automation with Home Assistant

kickaha 4y ago
Helpful. Thank you.
yamtaddle 4y ago
> Start by reading about docker and docker compose. You will have almost everything in docker containers. The case for Docker if you don't care about containerization or any of that per se is: 1) It's basically a very-up-to-date cross-distro package & service manager for Linux servers. You can ignore a ton of stuff about your underlying distro if you use Docker, and can use a very stable LTS Ubuntu or stable Debian or whatever and still have recent versions of the services you care about, more easily than you can without it. Anything you learn about managing Docker will transfer to any other distro. 2) It makes backups and recovery of the exact same services (including same versions) easy by default. Most packages are forced by its nature to make important data directories explicit, you can map those wherever you like on your host system's filesystem, and it's very easy to test whether you're backing up all the stuff you need for recovery from scratch (destroy and recreate the container—if you've mapped all the directories you ought to, it'll look exactly the same, nothing missing or broken, when it comes back up). Back up your mapped directories from various containers (since you can define where these live, this may be as simple as backing up a single directory), backup the docker-compose.yml or shell scripts or whatever you're using to define and start up your services, and that's just about everything.
- BrandoElFollito 4y ago
  Thanks for the update, it is very relevant to my comment. I would add one more thing: despite being discouraged, you can use an image (say, vaultwarden/server) with the tag :latest (vaultwarden/server:latest) and automatically update images to the latest version (with for instance watchtower, which is also a docker image). This may break things. From my personal experience (5+ years of self-hosting with docker), I had a problem twice. Once was with Home Assistant and the issue was documented on their site. 5 minutes later I was good to go. The other time was with Nextcloud which failed miserably, I had to revert back to the previous container AND use a backup. So backup! :) If the image allows it (it is usually documented with the image), you can limit the upgrades to major/monor/patch versions. Say your product is today at 3.2.5. If you use image:3, it will be updated up to the major version (3). You will not get version 4. You can also use lower versions (:3.2 in this example) and just get the patches. It is a decision between security, new features and availability. My personal opinion, of someone who works 30 years in IT and information security is that newer is better - you won't be alone if things break (because a lot of people use :latest and do not read teh changelogs when upgrading) Docker is a life saver for self-hosting.

kickaha 4y ago

Helpful. Thank you.

yamtaddle 4y ago

> Start by reading about docker and docker compose. You will have almost everything in docker containers. The case for Docker if you don't care about containerization or any of that per se is: 1) It's basically a very-up-to-date cross-distro package & service manager for Linux servers. You can ignore a ton of stuff about your underlying distro if you use Docker, and can use a very stable LTS Ubuntu or stable Debian or whatever and still have recent versions of the services you care about, more easily than you can without it. Anything you learn about managing Docker will transfer to any other distro. 2) It makes backups and recovery of the exact same services (including same versions) easy by default. Most packages are forced by its nature to make important data directories explicit, you can map those wherever you like on your host system's filesystem, and it's very easy to test whether you're backing up all the stuff you need for recovery from scratch (destroy and recreate the container—if you've mapped all the directories you ought to, it'll look exactly the same, nothing missing or broken, when it comes back up). Back up your mapped directories from various containers (since you can define where these live, this may be as simple as backing up a single directory), backup the docker-compose.yml or shell scripts or whatever you're using to define and start up your services, and that's just about everything.

BrandoElFollito 4y ago
Thanks for the update, it is very relevant to my comment. I would add one more thing: despite being discouraged, you can use an image (say, vaultwarden/server) with the tag :latest (vaultwarden/server:latest) and automatically update images to the latest version (with for instance watchtower, which is also a docker image). This may break things. From my personal experience (5+ years of self-hosting with docker), I had a problem twice. Once was with Home Assistant and the issue was documented on their site. 5 minutes later I was good to go. The other time was with Nextcloud which failed miserably, I had to revert back to the previous container AND use a backup. So backup! :) If the image allows it (it is usually documented with the image), you can limit the upgrades to major/monor/patch versions. Say your product is today at 3.2.5. If you use image:3, it will be updated up to the major version (3). You will not get version 4. You can also use lower versions (:3.2 in this example) and just get the patches. It is a decision between security, new features and availability. My personal opinion, of someone who works 30 years in IT and information security is that newer is better - you won't be alone if things break (because a lot of people use :latest and do not read teh changelogs when upgrading) Docker is a life saver for self-hosting.