22

I am working on setting up a home server but I want it to be reproducible if I need to make large changes, switch out hardware, or restore from a failure. What do you use to handle this?

top 27 comments
sorted by: hot top controversial new old
[-] emerald@lemmy.blahaj.zone 10 points 3 months ago

How do you manage your home server configuration

Poorly, which is to say that I just let borgmatic back up all my compose files and hope for the best

[-] adf@lemmy.world 8 points 3 months ago
[-] xyx@sh.itjust.works 2 points 3 months ago

Out of curiosity: Are you running nix-ops with nix-secrets or how did you cover orchestration & credentials?

[-] adf@lemmy.world 1 points 3 months ago

I use flakes and all hosts are configured from a single flake, where each host has its own configuration. I have some custom modules and even custom package in the same flake. I also use home manager. I have 4 hosts managed in total: home server, laptop, gaming PC, and a cloud server. All hosts were provisioned using nixos-anywhere + disko, except for the first one which was installed manually. For secrets I use sops-nix, encrypted secrets are stored in the same flake/repo.

[-] RheumatoidArthritis@mander.xyz 7 points 3 months ago

Git controlled docker-compose files and backed up docker data volumes.pretty easy to go back to a point in time.

[-] bigchungus@piefed.blahaj.zone 1 points 3 months ago

That's actually a really good idea. From now on I will do the same. Thanks!

[-] Object@sh.itjust.works 7 points 3 months ago* (last edited 3 months ago)

reproducible

You tried writing bash scripts that set things up for you, haven't you? It's NixOS for you.

[-] freeearth@discuss.tchncs.de 6 points 3 months ago

NixOS for configuration and restic for data

[-] yah@lemmy.powerforme.fun 5 points 3 months ago

With NixOS, you get a reproducible environment. When you need to change your hardware, you simply back up your data, write your NixOS configuration, and you can reproduce your previous environment.

I use it to manage all my services.

[-] giacomo@lemmy.dbzer0.com 3 points 3 months ago

systemd unit files, because its all podman containers.

[-] atzanteol@sh.itjust.works 3 points 3 months ago

Terraform and ansible. Script service configuration and use source control. Containerize services where possible to make them system agnostic.

[-] dontsayaword@piefed.social 2 points 3 months ago* (last edited 3 months ago)

I used to have a fille with every cli command and notes on how each thing was set up. When I had to reinstall it from scratch it took all day going through lots of manual steps and remembering how it should all go.

Recently I converted the whole thing to Ansible. Now I could rebuild my entire system on a brand new OS installation with one command that completes in minutes. It's all modular and I can add new services easily whether they are docker containers or scripts or whatever. If I ever break anything, it will reset everything to its intended state and leave it alone otherwise. And it's free and pretty easy to learn and start using.

Plus I use git along with it for version control, so I can always revert to any previous configuration instantly.

[-] antifa_ceo@lemmy.ml 2 points 3 months ago

I got a bunch of docker compose files and the envs documented so its easy to spin things up again or rollback changes. It works well enough if I'm good about keeping everything all up to date and not making changes without noting it down for myself later.

[-] BCsven@lemmy.ca 2 points 3 months ago

MicroOS is a decent choice, because it can cold boot off a configuration that uses ignition and combustion files. https://microos.opensuse.org/

And they have this file configurator so you don't have to manually type all the syntax for your configs.

https://opensuse.github.io/fuel-ignition/edit

[-] Seefoo@lemmy.world 2 points 3 months ago* (last edited 3 months ago)

I use git and commit configs/setup/scripts/etc. to it. I at least have a road map for how to get everything back this way. Testing this can be difficult, but it really depends on what you care about really.

  • Testing my kopia backups of important data? that I manually test every once n' while.
  • Testing if my ZFS setup script is 100% identical to my setup? that's not that important, as long as I have a general idea I can figure out the gaps and improve the script for the next time around. Obviously, you can spend a lot more time ensuring scripts and what not stays consistent, but it depends on what you care about!

For a lot of my service config, git has always worked well for me and I can go back to older configs if needed. You can get super specific here and save versions in git, then have something update the versions (e.g. WUD)

[-] thirdBreakfast@lemmy.world 2 points 3 months ago

Proxmox on the metal, then every service as a docker container inside an LXC or VM. Proxmox does nice snapshots (to my NAS) making it a breeze to move them from machine to machine or blow away the Proxmox install and reimport them. All the docker compose files are in git, and the things I apply to every LXC/VM (my monitoring endpoint, apt cache setup etc) are all applied with ansible playbooks also in git. All the LXC's are cloned from a golden image that has my keys, tailscale setup etc.

[-] _cryptagion@anarchist.nexus 1 points 3 months ago

Well I use Unraid, so I just back up my whole config folder along with the OS itself in case I need to flash it to a new USB. In other words, I just clone the whole thing. It means I can be up and running in a few minutes if everything was corrupted.

A data drive loss is pretty simple too, I just simulate the lost data until I can get a new HDD in. That takes a little longer to fix tho.

[-] eager_eagle@lemmy.world 1 points 3 months ago

I'm the only user of my setup, but I configure docker compose stacks, use configs as bind mounts, and track everything in a git repo synchronized every now and then.

[-] paris@lemmy.blahaj.zone 1 points 3 months ago

Recently switched to ucore. While I cannot for the life of me get SELinux to let my containers run without Permissive mode (my server was previously Endeavour OS and either didn't have it or I disabled it long ago), I've otherwise had great success.

The config is a single yaml file that gets converted into a json file for Ignition, which sets everything up on first boot. It's an OCI-based immutable distro with automatic updating, so I can mostly just leave it to its own devices and everything has been smooth for the first week I've been using it.

My Docker root directory is on a separate drive with plenty of space, so setting up involves directing Docker to that new root directory and basically being done (which my Ignition config handles for me).

[-] i_stole_ur_taco@lemmy.ca 1 points 3 months ago

I’m just using Unraid for the server, after many iterations (PhotonOS, VMware, baremetal Windows Server, …). After many OSes, partial and complete hardware replacements, and general problems, I gave up trying to manage the base server too much. Backups are generally good enough if hardware fails or I break something.

The other side of this is that I’ve moved to having very, very little config on the server itself. Virtually everything of value is in a docker container with a single (admittedly way too large) docker compose file that describes all the services.

I think this is the ideal way for how I use a home server. Your mileage might vary, but I’ve learned the hard way that it’s really hard to maintain a server over the very long term and not also marry yourself to the specific hardware and OS configuration.

[-] realitaetsverlust@piefed.zip 0 points 3 months ago

Terraform and Puppet. Not very simple to get into, but extremely powerful and reliable.

[-] 4am@lemmy.zip 1 points 3 months ago

I was getting into a similar form with Terraform (well, OpenTOFU now) and Ansible before I had to pack up my homelab about a year ago. New place needs electrical work before I can fire it back up.

How is Puppet to work with?

[-] relaymoth@sh.itjust.works 0 points 3 months ago

I went the nuclear option and am using Talos with Flux to manage my homelab.

My source of truth is the git repo with all my cluster and application configs. With this setup, I can tear everything down and within 30 min have a working cluster with everything installed automatically.

[-] radiogen@lemmy.zip 0 points 3 months ago

Are you using selfhosted git? Which one?

[-] moonpiedumplings@programming.dev 2 points 3 months ago

I have a similar setup, and even though I am hosting git (forgejo), I use ssh as a git server for the source of truth that k8s reads.

This prevents an ouroboros dependency where flux is using the git repo from forgejo which is deployed by flux...

[-] irmadlad@lemmy.world 0 points 3 months ago

I use snapshots, once a month an image is made of the entire drive, and I have Duplicati that backs up to cloud. Whatever choice you make tho, remember 3,2,1, and backups are useless unless tested on a regular basis. The test portion always gives me anxiety.

[-] MonkeMischief@lemmy.today 8 points 3 months ago

I'd really like to know if there's any practical guide on testing backups without requiring like, a crapton of backup-testing-only drives or something to keep from overwriting your current data.

Like I totally understand it in principle just not how it's done. Especially on humble "I just wanna back up my stuff not replicate enterprise infrastructure" setups.

this post was submitted on 16 Dec 2025
22 points (100.0% liked)

Selfhosted

57665 readers
88 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS