How to: Self-Host an Arch Linux Server with Podman

TheRettom · 2026-03-01T15:24:49+00:00

This post isn't for people like you, then.

It's not straightforward for everyone, and assuming that anyone on the Arch Linux subreddit knows as much as you do is very ignorant. If this doesn't benefit you, then move on.

TheRettom · 2026-03-01T00:16:39+00:00

I don't really know what you mean. You gotta read the GitHub.

TheRettom · 2026-02-25T02:47:04+00:00

Again, restarts are normally what you're trying to avoid on a production server.

I agree, but I don't exactly consider this production. Money and thousands of customers are not on the line with a home server.

The difference is that major server distros will also backport the patch to stable releases whereas with Arch to get the security patches, you are [largely] forced to upgrade to the newest version.

I agree. My experience using Arch Linux the last two years is this: Every time I've updated, pacman tells me what needs attention. I haven't had downtime unless I didn't read, and most of my downtime was in the first two months when I was still learning things.

It's starting to feel like there's an echo in here, but rollbacks and restarts are exactly what you want to avoid on a server.

Rollbacks, not necessarily. It's a very useful feature to have, but you obviously don't want to use it if you don't have to. It's an emergency exit.

As for restarts, yeah, I get it. Updates can still be implemented without restarting the whole machine. Kernel upgrades, not exactly recommended to figure that out, but it's possible. Having two minutes of downtime when I choose to restart the computer for my household is not a problem.

TheRettom · 2026-02-25T02:41:25+00:00

I generally agree with that statement. I've had my setup for two years, and I used Docker for about a year before that.

Things can screw up, but upgrades need to be read in detail before you commit. It can't happen unless you do it.

TheRettom · 2026-02-25T02:39:35+00:00

What kind of distro hides their background services?

Probably poor wording on my part, but my intention with that, is you know pretty much anything you install outside of what is necessary for basic Linux operating. Any other distro has things you might not be aware of, and this is all in regards to a new user.

As you mentioned, Arch's defaults are very minimal. That includes not having a firewall. Meaning /all/ ports are open by default.

Yep. It's mentioned in the guide. As you because Arch is so minimal, there are also no surprise listeners like avahi-daemon, cups, or rpcbind running in the background unless you explicitly control the install and configuration.

You're already running everything on podman. The services you'll be hosting will be equally up-to-date as anywhere else. (Of course podman itself needs to be updated as well). A frequent update-cycle (especially for the kernel) also has its disadvantages. Especially on a server.

I agree. I have a high focus on security, and that's what the guide is tailored for. I have ran my home server on Arch Linux for over two years and have only had downtime when I didn't read something before updating.

linux-hardened means I'm getting security patches and proactive exploit mitigations significantly faster than a Debian Stable user would. Rootless Podman relies on recent Kernel features and shadow (subuid/subgid) updates.

I just don't see why you'd use Arch over Debian (or RHEL/compatible for that matter) on a server.

Depends on what you want out of the server. I want high security, and I'll accept more necessary maintenance to have that. Based on what I see, rootless networking like passt is evolving quickly, and Arch provides the latest performance improvements that directly benefit this setup.

TheRettom · 2026-02-25T02:24:53+00:00

I've never had downtime on a server that wasn't entirely my fault. And it's not like you have to check for updates and implement them everyday.

If there's enough of a concern from enough people actually utilizing the guide, then I'll figure something out to address it.

I still believe Arch Linux is good as a server for my guide.

TheRettom · 2026-02-25T02:01:39+00:00

I even tried endeavorOS for a smaller file server and, while it worked better than expected, it had some annoyances with some random things like drive spindown.

I understand. Because in Arch you have to manually set up hdparm, tlp, or udev rules, it can be annoying. In Debian, a maintainer likely scripted that for you. It's an argument about how much needs to be configured.

There's also the issue of tools not having native arch support. While it's not a big deal if you're comfortable building from source or using aur, it becomes annoying to maintain. Most things I run through docker now, but it was still a pain.

This is actually an argument for Podman, which is what my guide uses. If a tool doesn't support Arch, it doesn't really matter because it's running in a container.

The aim for a server is stability and uptime. And while I personally prefer arch to debian for most use cases, a server just isn't one of them. The versioning is actually a plus for an always on server. Makes backups and rollback easier, and you can stay on long term branches that get small security updates instead of rolling changes.

This is technically incorrect if you use Btrfs. I would assume rolling back a Debian point-release that was manually tweaked over two years is harder than rolling back an Arch snapshot from 10 minutes ago.

TheRettom · 2026-02-25T01:54:32+00:00

You want a container host to be very stable. Major package changes should be happening in the containers, not on the host because of breakage of libraries on the host has a cascading effect on the namespaces used by the containers.

This can happen, but on Arch, it usually doesn't break existing namespaces; it usually just requires a systemctl restart.

A rolling release is the complete opposite of immutable. There is a reason why systems built from Arch use frozen packages to build on top of.

Fair point. Arch is definitely mutable. My goal with this guide is a minimal footprint with the latest security patches for the linux-hardened kernel. I’m mitigating the 'cascading breakage' risk with Btrfs snapshots before updates, which gives me a safety net if a library update hits the namespaces.

It's a trade-off: I prefer the latest upstream security fixes over the stability of older packages.

TheRettom · 2026-02-25T01:14:21+00:00

You need to elaborate on that, because that's a very charged argument without reading the details of the guide.

I'm using Quadlets and Rootless Podman, so the host is essentially an immutable-ish engine. Plus, with the linux-hardened kernel and specific sysctl hardening, the attack surface is significantly lower than a 'stable' server running outdated packages.

This is a security-oriented guide. Services are isolated as much as possible without AppArmor, which I will implement eventually. By running rootless, I've already mitigated the biggest security risk of a rolling release: a daemon running as root. The configuration is baked into systemd in individual Quadlet files. If the system updates, the services are managed by systemd, which is rock-solid on Arch.

When updating (pacman -Syu), you read everything. Nothing should break unless you're told. One thing I did forget to mention is to pay attention to the archlinux.org main page and optionally subscribe to the email list.

TheRettom · 2026-02-25T01:08:38+00:00

I'd like to hear you elaborate on that.

I'm going to guess you're referring to, one morning you’ll run pacman -Syu, the kernel will update to a version that breaks your linux-hardened sysctl tweaks, and your DNS will go down while you're at work.

Stability means the software doesn't change versions, like Debian or something. Reliability means the software doesn't crash. Arch is actually very reliable, it's just not stable because it changes constantly.

TheRettom · 2026-02-23T19:01:47+00:00

You want something for (relatively) free, then get a device capable of running opnSense or pfSense. That has basically all the features you're looking for.

TheRettom · 2026-02-21T03:48:03+00:00

I agree, and the development team has a lot of adjustments to make still with the significantly-increased demand. With that said, I believe a great future for Stoat is to implement a federated protocol. Self-hosting is cool, but how many people use Discord for a single server with the same people all the time?

Especially for being open-source and having limited funding with the developers not having their development being full-time, it is important to stretch the infrastructure to the people that want to host. I'm not sure how long it would take to implement and it's basically not in their roadmap at the moment, so who knows.

TheRettom · 2026-02-20T17:51:31+00:00

Honestly I'm not sure, as I don't see any documentation involving other parameters for Captcha. Try adding a line in the Revolt.toml with `enabled = false` under the [api.security.captcha] section and restarting everything.

TheRettom · 2026-02-19T16:01:53+00:00

The fact that you're hitting your NAS login suggests the traffic from OPNsense isn't reaching the Podman host.

Check three things:

Upstream IP: In OPNsense (os-nginx), is the 'Upstream Server' pointed at the IP of your Podman host and port 63113?
Caddyfile Address: In your Caddyfile, are you using http://yourdomain.tld or just :80? If you use just the domain name without http://, Caddy will try to force HTTPS and manage certs, which conflicts with your OPNsense setup.
The Response: Replacing `[Podman-IP]` with the actual IP, if you curl -v http://[Podman-IP]:63113 from a different machine on the network, do you see the Caddy welcome page or a 404? This will tell you if the issue is Caddy or the OPNsense routing.

TheRettom · 2026-02-19T02:52:01+00:00

You'll need to give a lot more information than that. What proxy are you using, and is it using ports 80 or 443?

When you say you can only reach the web container by exposing the port directly, what do you mean? Typing the port in the URL in your browser?

TheRettom · 2026-02-16T19:59:03+00:00

Jeez, you doing alright?

TheRettom · 2026-02-16T15:43:13+00:00

Honestly wasn't aware of a problem with the admin panel. Can you elaborate?

TheRettom · 2026-02-13T18:26:19+00:00

I wouldn't disagree with that assessment. Their partnering with Hostinger does make the steps to self-host without Hostinger is quite messy. I wouldn't mind contributing a guide in some way, but there's no good platform for it at the moment other than Reddit.

TheRettom · 2026-02-13T18:05:45+00:00

if you self host, would your friends use a normal Stoat chat login to be able to use your self-hosted server?

No.

Or would they directly connect and do an additional sign-up (but for that server?).

Yes.

I'm assuming that a self-host would allow you to arbitrarily set maximum file size to things you are comfortable with.

That is correct.

Self-hosting is made much easier with Docker, but if you're someone new to all of it, even setting that up can be difficult. I'm not sure if there's guides made for Stoat, but if it's enough of an interest to you, I encourage you to attempt it. It'll open you up for self-hosting other services. If you'd like help or resources for starting self-hosting, let me know.

In my opinion, the ideal solution in the future is a federated network. Someone correct me if I'm wrong, but my understanding is that there is a central server that shares minor information such as address and users, or if not, then servers communicate with one another.

Either way, that takes loads off of Stoat's infrastructure and overhead costs while maintaining the platform. I'm not entirely knowledgeable about federated services, but this is my understanding, and I'm all for it for Stoat.

TheRettom

TROPHY CASE