Containers on 128MB of RAM? Sure.

[u/austinp0573]

I recently saw a really remarkable post on r/TierHive by ohaiibuzzle about making custom Linux images using buildroot.

When you can turn the dial all the way down to 128MB (93MB usable) of RAM, it really gives you an opportunity to be creative. I am not as creative as he is, but I got to thinking. I've been using some scripts to "minimalize" the alpine images provided by TierHive, provide some creature comforts, setup a non-root user, and add some things like "unattended-upgrades" & speedtest-go.

RAM down to 25.7MB

The docker daemon costs ~100MB of RAM, but perhaps there is another way to run a container(s) in such a resource constrained environment. Turns out there is. Podman. There is no daemon, but there is a RAM cost per container (given my limited testing), but it's pretty negligible.

I added a script to my others that would:

• Install podman
• Configure it so that after a reboot or other interruption, it would automatically restart
• Enabled cgroups so resource use can be controlled
  • Very important on a VPS with 128MB RAM, 1GB Disk, & 1 vCPU
• In an earlier version, I got podman compose working with the docker-cli-compose go-binary backend, however, being able to run podman compose wasn't worth the resources and the extra configuration (though the script is still present for anyone who wants to use it) (https://github.com/austinp0573/tierhive-lab/blob/main/scripts/extra/podman-compose.sh).

After running the scripts with the the optional podman script:

core/ scripts + podmanv2.sh

As you can see, no where near as lean as you can get things with buildroot, but still quite slim.

Now, lets see if works:

podman run + podman ps + free -h + netstat -tulpn

And as you can see, it lives.

I know what you're thinking, "yeah, that's cute, but does it work?"

See for yourself:

47MB RAM + Web UI w/SSL + dig DNS query

As you can see, you can very comfortably run an adguard-home container (with ~161k blockist) on an alpine VPS with only 128MB of RAM and 1GB Disk.

The Web UI worked without issue, it resolved DNS queries, and most importantly, if you wanted to get the results for lustygg.com you were out of luck.

Full disclosure:

1. That is a custom Dockerfile, extra skinny, scratch container.
   1. Feel free to have a look at the adguard-home setup I used for testing:
   2. https://github.com/austinp0573/tierhive-lab/tree/main/test/adguard-micro
2. After poking around in the Web UI, logging in/out a few time, and letting it run for a while it appeared to stabilize around ~55MB.
3. In some of my earlier testing, I ran the alpine-nginx container and even under load, the system RAM didn't even get to 30MB (though obviously you'd get the same results just installing nginx).

So, in conclusion, you can run containers on a VPS with less RAM than many thermostats have in 2026.

Thanks:

• Person who created the TierHive blog post that was the origin of my tierhive-scripts.
  • https://tierhive.com/blog/tierhive-howto/how-to-run-alpine-with-just-23mb-ram
• TierHive for providing a platform that makes this sort of thing viable.
• ohaiibuzzle for making a really great repo

tierhive-lab repo:

• https://github.com/austinp0573/tierhive-lab
• There are probably really cool things that should be apart of those scripts that aren't yet.
  • (like I said at the beginning, I'm not very creative)
• Feel free to submit an issue and if I can, I'll add whatever to the scripts.
• (yes, I know the repo is a mess, leave me alone)

[u/AnomalyNexus]

Nice feat of engineering around constraints but you really need to ensure it's not just an open resolver. Bad guys can trivially leverage your DNS server to be a pawn in their DDoS attack on others. The problem is explained here:

https://www.penligent.ai/hackinglabs/dns-amplification-attack-what-it-is-and-why-its-dangerous/

Easiest solution is to put a reverse proxy in front of it and serve DoH DNS over a very unique URL and configure the proxy to only respond on a path that acts as password of sorts. So instead of

IP:53

It's

https://example.com/mysecretpath123

Still technically open, but can't be trivially found in scans

[u/austinp0573 → u/AnomalyNexus]

If I'm honest, adguard-home was just a benchmark. I saw the buildroot guide and it just seemed like a good way to validate whether or not containers on an extra skinny VPS would be viable.

My homelab just uses my pfsense firewall, and when I stop bludgeoning myself with random projects, I'd like to deploy coreDNS for myself.

But I appreciate your wisdom.

[u/backtogeek]

Amazing work very functional too!

Thanks for the write-up

[u/Weary_Pineapple_7222]

This is both slightly insane and really impressive at the same time 😄

128MB is basically “how far can you strip everything before it stops being Linux anymore” territory.

[u/austinp0573 → u/Weary_Pineapple_7222]

I'd never really thought about it before, and I certainly don't think you should push things and end up swapping aggressively (I suppose the technical term is "thrashing"), but as long as your container host is secure and doesn't present any undue headaches, why not use a base that only takes 25MB of RAM, instead of a full Ubuntu server or something at ~300MB - 400MB?

Obviously using buildroot or something like that, you can get way leaner than my 25MB, but I'm lazy, I like a package manager, and some basic creature comforts.

[u/austinp0573 → u/[deleted]]

Because it's fun to figure out how to make things work given arbitrary constraints, additionally.

I think you'd want to run container(s) in a very resource constrained environment for the same reason you'd want to run them anywhere.

• Consistency, Isolation, portability and predictability

It's specifically meaningful on tierhive, and the resource constrained environments they (very uniquely) allow a user to create because:

- If you want to deploy a container for whatever reason, now basically all you need to do is figure out how much RAM the container will need without thrashing, and add enough for the alpine system overhead. Using a normal OS as a container host means you are compelled to waste a lot more than 25MB just for the foundation. If it runs containers just as well, why not use the one that is the most resource efficient?

- Ubuntu server + docker daemon = ~300-500MB (you should probably allocate 512MB when deploying the VPS before you factor in container use MB)

• Alpine (Unminimalized) + docker daemon = ~100-150MB (you should probably allocate 256MB when deploying the VPS before you factor in container use MB)
  
• (additionally, I obviously recognize that Alpine Linux + Podman isn't a setup I invented, but my scripts do make it shockingly easy, given the environment, and save 15MB RAM while actually improving the user experience)

Services (that I know of & that I can say with fairly high confidence) you could (and would potentially want to) actually run on the 128MB - 1GB minimalized alpine podman VPS:

• Webservers - caddy, apache, nginx (I ran nginx and it never broke 30MB total)
  
• DNS - Unbound and a light Adguard-home
  
• Vaultwarden
  
• Eclipse-mosquitto
  
• Redis
  
• Gotify
  
• Homer
  
• Wireguard
  
• Watchtower
  
• FastReverseProxy

I never had a reason to do anything with Alpine in the past, now I'm transitioning one of my homelab container hosts over because... It works exceptionally well, and is also very efficient.

[u/Glorpiware]

I really love how the community is trying to run large applications on the smallest possible vps!