Tell me you don’t live in Germany without telling me you don’t live in Germany :D

And remember, friends don’t let friends use latest. Pin the versions in your manifests and version control everything.

I know what you mean. Most people mean well, some are a bit too aggressive, but probably also mean well. I honestly sometimes roll my eyes when I start reading about tailscale, cloudflare tunnels etc. The main thing is not to expose anything you don’t absolutely need to expose.

For access from the outside the most you should need is a random high port forwarded for ssh into a dedicated host (can be a VM / container if you don’t have a spare RaspberryPi). And Wireguard on a host which updates the server package regularly. So probably not on your router, unless the vendor is on top of things.

Regarding ansible and documenting, I totally get your point. Ten years ago I was an absolute Linux noob and my flatmate had to set up an IRC bouncer on my RPi. It ran like that for a few years and I dared not touch anything. Then the SD card died and took down the bouncer, dynDNS and a few other things running on it.

It takes me a lot of time to write and test my ansible playbooks and custom roles, but every now and then I have to move services between hosts. And this is an absolute life saver. Whenever I’m really low on time and need to get something up and running, I write down things in a readme in my infra repository and occasionally I would go through my backlog when I have nothing better to do.

One word of advice. Document the steps you do to deploy things. If your hardware fails or you make a simple mistake, it will cost you weeks of work to recover. This is a bit extreme, but I take my time when setting things up and automate as good as possible using ansible. You don’t have to do this, but the ability to just scrap things and redeploy gives great peace of mind.

And right now you are reluctant to do this because it’s gonna cost you too much time. This should not be the case. I mean, just imagine things going wrong in a year or two and you can’t remember most things you know now. Document your setup and write a few scripts. It’s a good start.

Same. I buy all my domains there. And in case someone needs a proper API and support for the dns challenge, host your DNS at DeSEC.

You don’t need 8 drives when they are 8 times larger than your current ones. I went from planning for 5+ drives to just downsizing to two drives in mirror. Then I can expand with another mirror.

Unless you need uptime and want to guarantee an SLA for your own services, you are much better off with a mirror or raidz1. Do regular backups (off-site, incremental) and don’t fear the disk failure.

Same, I have a bunch of “inbox” folders and drop files into my server or desktop from my phone with 3 clicks.

LDAC is lossy.

Do you happen to have some resources or links re sshfs? Once I found an app which supports mounting over sshfs but it is barely documented and iirc required passwordless ssh keys to work :(

I am seeding 70 torrents on a private tracker, most of it some niche stuff. It’s getting downloaded, but I have 0.00 seeded across all 70 torrents. I have no port forwarding. 1 + 1 = you need proton / airvpn.

Symfonium is great, it supports a bunch of sources and works really well. Absolutely worth supporting the dev (check his ko-fi too)!

Oh okay that’s a lot of power. For reference, I just set up an old Haswell PC as a NAS, idling at 25W (can’t get to low Package C states) and usually at 28-30 running light workloads on an SSD pool. My plan was to add a 5 disk cage and at least 3 HDDs, with Raidz2 and 5 disks being the mid term goal. Absolutely unnecessary and a huge waste. I settled on less but larger disks, and in mirror I can get 12-18 TB usable space for under 500€. Less noise and power draw too.

Look for 5W idle consumption boards + CPU combos which go down to package C6+ state. HardwareLuxx has a spreadsheet with various builds focusing on low power. Sell half your disks, go mirror or Raidz1. Invest the difference in off-site vps and or backup. Storage on any SBC is a big pain and you will hit the sata connector / IO limits very soon.

The small NUC form factors are also fine, but if your problem is power you can go very low with a good approach and the right parts. And you’ll make up for any new investments within the first year.

The problem is, the libraries and SDK used to build the app will have had vulnerabilities for sure. Same for the underlying image (unless scratch / distroless). We run extensive vulnerability scanning in our pipelines, and Go libs occasionally pop up. The Go SDK also had multiple security fixes in the last year.

For the physical hosts / bare metal I use fluentbit, with Loki as the backend. Grafana for visualization and alerts. This gives me utilization metrics and uptime monitoring. The app containers themselves I do not monitor.

How does this work, some loophole or a business customer? You can drop some info in a private message if you don’t f feel like posting in public. Re server part deals, I am not sure if this is always the case, but the current selection of disks is 90% helium (Exos etc) HDDs, a few IronWolfs which are too large (20TB) and basically that’s it. My DIY NAS is unfortunately in the apartment and I’m reluctant to try He disks due to the intensive sound profile.

I wish this was an option for Europe. Once you slap VAT and shipping, you end up paying more than for new disks. :(

Wifi pretty much excludes k*s and I assume that swarm and Nomad would be impacted by blips in the wireless connectivity. You can try how things work out with a load balancer / reverse proxy on a wired connection, which then checks the downstream services and routes the request to available instances.

Please look into Wifi-specific issues related to the various orchestration platforms before deciding to try one out. Hypervisor is usually a win win, until you try to do failover.

I wasn’t intending on doing this, instead opting to install Pi-hole, Log2Ram, UFW, and the… other… softwares directly to the OS for simplicity. Why would one set up a Pi-hole et al in a containers instead of directly?

So there are many reasons, and this is something I nowadays almost always do. But keep in mind that some of us have used Docker for our applications at work for over half a decade now. Some of these points might be relevant to you, others might seem or be unimportant.

• The first and most important thing you gain is a declarative way to describe the environment (OS, dependencies, environment variables, configuration).
• Then there is the packaging format. Containers are a way to package an application with its dependencies, and distribute it easily through the docker hub (or other registries). Redeploying is a matter of running a script and specifying the image and the tag (never use latest) of the image. You will never ask yourself again “What did I need to do to install this again? Run some random install.sh script off a github URL?”.
• Networking with docker is a bit hit and miss, but the big thing about it is that you can have whatever software running on any port inside the container, and expose it on another port on the host. Eg two apps run on port :8080 natively, and one of them will fail to start due to the port being taken. You can keep them running on their preferred ports, but expose one on 18080 and another on 19080 instead.
• You keep your host simple and empty of installed software and packages. Less of a problem with apps that come packaged as native executables, but there are languages out there which will require you to install a runtime to be able to start the app. Think .NET, Java but there is also Python out there which requires you to install it on the host and have the versions be compatible (there are virtual environments for that but im going into too much detail already).

Basically I have a very simple host setup with only a few packages installed. Then I would remotely configure and start up my containers, expose ports etc. And I can cleanly define where my configuration is, back up only that particular folder for example and keep the rest of the setup easy to redeploy.

If you want to try setting it up in high availability with failover, give me a poke. And until then - go to Teleporter in the settings, and download the backup. You can restore from there.

One thing worth saying is this - you can grab a cheap refurbished ssd (the smaller - the better), check it’s SMART data for any red flags, and attach it to the pi as OS disk. It will be much more reliable than SD, but overkill if you only run pi on the box. Alternatively look into log2ram, it keeps your SD card alive for longer :D but backup first!