What happened when I banned root access across my app catalogue
Fabian, Founder of Bitflake July 22, 2026
I locked down the platform: no app runs as root, filesystems are read-only by default, and every app is isolated on its own network segment so a compromised app can't reach anyone else's apps. Then I redeployed the whole catalogue to see what breaks.
The numbers
Fifty-two apps went through the test. Apps already excluded from the catalogue for unrelated reasons weren't part of this pass, since they aren't running anyway.
- 17 apps (33%) ran with no changes.
- 26 apps (50%) needed fixes. Almost all of them were the same kind: a read-only filesystem only allows writes to paths I've explicitly opened up, and most images don't document where they write.
- 9 apps (17%) can't run at all without root, and none of them ship a version that can.
Why so many apps want root
Two patterns cover almost all of it.
The first is PUID/PGID, a convention popularised by LinuxServer.io images: the container starts as root, fixes file ownership for the folders it's about to use, then drops down to the configured user ID. It works well on a home server where you own the whole machine. It doesn't work at all if the platform refuses to let the container start as root in the first place. The ownership fix never gets a chance to run.
The second is port 80. Eight of the nine blocked apps serve their web interface on port 80 inside the container, and only root is allowed to bind a port below 1024 on Linux. Behind a reverse proxy, which is how every one of these apps actually gets reached, that restriction protects nothing. It's a leftover default.
A smaller, stranger pattern: three apps failed at the exact moment they tried to stop being root. Their entrypoints drop privileges with tools like su-exec or gosu, and dropping privileges is itself a root-only operation. Once the container isn't allowed to start as root, that step fails too. Two of the three could be fixed by skipping it and starting directly as the target user. The third had no such shortcut.
What this means if you self-host
None of this makes these apps badly built. Their images are built for a single trusted server, where starting as root to fix a few file permissions is a minor convenience, not a risk. A shared platform running dozens of unrelated apps side by side is a different environment: if one app gets compromised, root access inside its container gives an attacker a much larger attack surface against the kernel, the layer that's supposed to keep it away from everyone else's data.
If you're self-hosting any of these apps yourself, it's worth checking how they start. The quickest tell is in the documentation: if an image talks about PUID and PGID, it starts as root and drops down later. Kubernetes' Pod Security Standards documents the "restricted" profile that rules this out, which is the profile I now run everything against.
Where this leaves the nine
For now, none of the nine run on the Bitflake catalogue. I haven't decided whether that's permanent. The options are an upstream fix, a different image, or a scoped exception to the no-root rule. Each has its own trade-offs, and I'd rather think it through properly than pick one now.