So while the content is in RAM on the Pi, a lot of the heavier lifting (TLS termination) is done elsewhere, which saves a ton of CPU load on the Pi.
On the one hand I get it, TLS is pretty heavy, and it makes sense to take advantage of a VPS or Cloudflare or however you want to do it.
But once you are spinning up a VPS, the question is ... why the Pi? The VPS in the article has less RAM, but more storage. If you're already doing TLS termination on the VPS (the most RAM intensive part), you might as well just do the whole shebang there.
I know this is all for fun, I'm just wondering -- is the Pi Zero really too slow to handle TLS, especially with an optimized TLS library? In this setup, the Pi is already being directly exposed to the Internet anyway, there's no VPN being used. That ARM11 isn't "fast", but surely a 1 GHz ARM11 can handle an optimized TLS library serving some subset of TLS1.2.
I found a fun bug with it a couple years ago: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
It is still able to build software faster than it is released. It takes roughly a month to recompile the entire system :D
for the ones that say that the pi can't handle tls that's just stupid. that's trivial as well.
for the ones saying that you need a vps how cloud native are you people? you can just expose a port on your router (if you're brave enough) and have any dynamic dns service point to the correct ip address.
A Pi with Ethernet can truly boot diskless via TFTP. And later Pi4 and Pi5 can even boot directly from the internet by getting their initial "boot.img" FAT partition via HTTP from anywhere. That would be diskless.
I run my micro-homelab on a Pi Zero from 2018. It’s behind Cloudflare tunnels. It runs the apps i need on a DietPi OS within 180MB and it’s uptime is ~8 months.
For whatever reason, the speed seems far faster than Python for me.
A Raspberry Pi Zero can just run apache.
I don't mean to shit on this, exploration is nice and putting perfectly fitting hardware to use instead of throwing abundant unnecessary hardware on every simple problem — just to bring it to crawl with loads of shitty bloates software — is good, but it's not particularly impressive.
What was supposed to be a cool achievement is rendered pointless when one of the key elements is offloaded elsewhere.
For the radio stuff I can just take the Pi, frontend, and a battery pack outside to test.
When I finally move to a place with proper fiber internet I'm going to be hosting several side projects on a handful of Pis.
- R-Pi Zero W
- Sixfab UPS hat
- Sixfab Cellular IoT App Shield
- R-Pi model 1B
With all this I should be able to make a multiply redundant always-on bastion host. It's awesome that alpine supports the armhf stuff, many OSes have dropped 32bit support entirely.
Also, all web pages are served from RAM. It's automatic that modern OSes will cache this stuff on first access.
Running a mainstream website on a RPi Pico W is more advanced, but still not really challenging as long as the content is static
a better way would be to boot via nvme SSD, ethernet boot has a dependency of network, what if you need to debug when network is down or debug the errors/bugs network itself ?
The point of failure for all of these machines has been the SD card. They seem to last 4 years almost to the day. I suppose if I set up a RAMdisk they might last longer, but honestly, for the price of an SD card it’s not really worth my time.
- Victron Monocrystalline Panel 90W 12V
- Victron Gel Battery 12V 60Ah
- Victron MPPT Charge Controller 75V 15A
- Raspberry Pi Zero W
- Witty Pi 5
- Sixfab 4G/LTE Base HAT
- Quectel EC25 Mini PCle 4G/LTE Module
Almost 100% uptime except for a few days after a bad winter storm, pretty neat!
Don't have a Pi plugged in now to check, but I have a fresh x86_64 linux and it's using like 600 Mb of ram - server install, I only got around to installing and configuring openssh and samba so far.
Oh and it's Devuan, so not even systemd to blame. I think it was close to 1 G with a systemd distro.
I've since got a lot more interested in the microcontroller community - so many Pi projects should really be microcontroller projects - the esp32 especially scratches the itch for cheap things to hack on, and you can get them for like 6-7 bucks each with wifi.
Kind of irrelevant since operating systems and web pages in the 90's were significantly smaller in footprints, as the web was mostly plain text back then. Windows XP with its GUI would run Max Payne on 128MB of RAM. You could do a lot more back then that You can't do modern stuff like that today with 128MB of RAM.
OTOH, I corrupted a card by turning off the Pi in middle of writing.
Today, you can run mailcow/mailu with all the options on a relatively modest vps. I'm on a cable provider that locks down residential customers and charges over 2x as much for business, so it's cheaper to use VPSes.
On RPi, I've mostly opted to use SSD + USB Adapters as they've been significantly more reliable that SD. There's lots of cases that make this configuration a breeze. That said, I've mostly been running Mini PCs since COVID when the RPi got to be more expensive all-in and slower.
I’m scared of self hosting a mailbox.
There are "Industrial" SD cards which should last considerably longer, you can look up a few people have done their own testing. They can be slower but that shouldn't be a blocker for an email server on a pi.
While I may make the argument that most are probably hosting and doing php on the same server, it's not the typical approach for any custom software at this point.
I retired my 486 in ‘95 or thereabouts…
HTML code, CSS, Javascript, Images.
In this case, they are static elements, which can even be cached locally to share more easily.
If someone wants a massive build system to render a static HTML page, that's on them, and their personal interpretation. Increasingly, and maybe more often than not, there is more than one way to get the same outcome.
The fact that there's hundreds of downloads for a single web page is up to the constructor of that page. Still, these things can be reasonably cached. For example, host it on the Pi, then put a cloudflare in front of it or something.
The Pi Zero might not be for you, or easy to try to undermine. Which criticisms would go away if it was on a regular pi?
I don't send a lot of emails from it, but the ones I do are delivered.
There are a few open-source one-command mail server deployment solutions that do all of the heavy lifting for you. Some of them might even be pretty good. The problem with those is that if you don't understand how your mail server is put together, you're completely stuck if it breaks.
It had a second life doing stuff like delivering mail, handling IRC, serving web pages, and whatever else a few of us wanted from it. The performance was fine.
(The Pentium-ish machines stayed on desktop duty where GUIs devoured resources.)
Maybe you misunderstood. Which criticism did I make of the pi zero? I criticized present day SW.
Yesterday I one-shotted several interactive pages, that Qwen built out of straight HTML and Javascript. I handed it my API (source code, not even a swagger, via an MCP that Qwen wrote for me), asked for a frontend, and it delivered. One page at a time to keep context down, and mightve gotten lucky on the first draw but after the first one I told it to make the next ones like the first.
Can't say I've had that experience with backend languages & frameworks, incl writing that same API, but perhaps I'm off the beaten path with those, or perhaps there's greater breadth of things to do vs a narrower set of acceptance criteria? IDK.
Here I was sweating that I'd have to research and learn a current-day frontend framework. It felt like a magic wand using consumer-grade AI. HTML and plain old Javascript was plenty.
Tangent but apropos of other contemporary threads on HN, it puts a spin on supply chain threats. There's no NPM or anything, except perhaps whatever mysteries are baked into the model.
Edit: No, the article mentions listening on port 80 at home. I thought they'd be SSH tunneling or something. That is unusual, but I guess for a static website it doesn't really matter.
It sorta does matter. Either the actual raspi does nothing of value or the traffic has value that should be protected.
Sure, I heard the argument that public HTTP traffic does not need encryption but if it is of any value then both parties have a interest in it unmanipulated, uncenscored, validated or all of the before. Even if it is just preventing the ISP injecting dumb ads.
2026-05-08
My micro site, zero.btxx.org, is being served to the public internet from a Raspberry Pi Zero v1.3 running Alpine Linux.
The best part? It’s diskless and running entirely from memory!

My Raspberry Pi Zero silently running in my cold-storage room (with two extra Pis for moral support). Serving zero.btxx.org
This is even more impressive considering the Pi Zero only has 512MB of total memory, ~40MB of which is tied up running Alpine Linux. But since RAM is so abundant and cheap these days that we can… Oh, right.
Anyway, what a time to be alive! If you’re interested in running your own website off a Pi Zero, follow along!
Before we start, let’s make a list of all the required hardware items we need.
This will make our image backups much easier (at the end of this post). Since we are limited to a maximum RAM space of 512MB (storage), it makes sense to avoid backing up more than we need.
Additional hardware that will only be needed temporarily for the initial install of Alpine:
Since I plan to avoid handling the heavy TLS termination directly on the Pi Zero, I’m going to funnel secure traffic through a separate, tiny VPS. I’m currently using TierHive (referral) which has been fantastic so far. They’re still in alpha, but that’s fine for this personal experiment.
I’ve selected TierHive based on their low pricing and pre-built HAProxy configuration options.
But don’t worry about this right now. We’ll get into those details shortly! Feel free to use a different provider or a free service like Cloudflare1 if that’s your jam.
The following was performed on macOS. Using a different operating systems will require different steps. Note that we will be extracting the tar content directly on to our microSD card, so make sure you download the Alpine image ending with tar.gz.
Plug in SD card and find the disk with diskutil list. For our example the SD card will be located at /dev/disk4.
Wipe and re-partition the card as FAT32:
diskutil eraseDisk FAT32 ALPINE MBRFormat /dev/disk4
Extract the Alpine tarball onto the card:
tar xzf alpine-rpi-*.tar.gz -C /Volumes/ALPINE
Clean up any macOS junk then eject it:
find /Volumes/ALPINE -name '._*' -delete
rm -rf /Volumes/ALPINE/.Spotlight-V100
rm -rf /Volumes/ALPINE/.fseventsd
rm -rf /Volumes/ALPINE/.Trashes
diskutil eject /dev/disk4
Now pop the microSD card into your Pi Zero. Be sure to have your Pi connected to a monitor and keyboard, then turn it on.
Once the Pi boots into the Alpine Live environment, login with root (no password required). Take note that the SD card should be located at /dev/mmcblk0.
Normally you would run setup-alpine and walk through the installer, but we need to configure lbu first. This will allow us to save our configurations and site files on to our SD card in order to keep persistent changes on reboot.
setup-lbu mmcblk0p1
mkdir -p /media/mmcblk0p1/cache
setup-apkcache /media/mmcblk0p1/cache
lbu commit -d
Pay close attention to lbu commit -d. You will need to run this anytime you install/remove packages or change files on the system. Otherwise they will be lost on future reboots or power outages.
With that complete, we can now continue with the install by running setup-alpine.
This walks you through:
eth08.8.8.8 is fine (or whatever you want)f to select the fastest based on your locationdropbear is MUCH lighter than the others. Highly recommend this!none here. This keeps it diskless.When it asks you about storing configs / APK cache, it should already have your previously configured /media/mmcblk0p1/cache sets as default. Keep those the same.
Now with the install complete you can reboot the system. Once it boots up and you login, you can check that everything is running in memory by running:
df -h /
If the root (/) is mounted as tmpfs or ramfs, it’s running in RAM. Hooray!
darkhttpdSince we only need to serve basic HTTP (VPS handles the TLS, remember?) the best web server option for our limited resources is darkhttpd. Let’s install and setup a boot runtime to persist on reboots:
doas apk add darkhttpd
Then we need to make a runtime file at /etc/init.d/darkhttpd:
#!/sbin/openrc-run
description="darkhttpd static web server"
command="/usr/bin/darkhttpd"
command_args="/var/www/example.com --port <desired-port-number> --maxconn 20"
command_background=true
pidfile="/run/darkhttpd.pid"
depend() {
need net
}
Then get everything running right away:
chmod +x /etc/init.d/darkhttpd
rc-update add darkhttpd default
rc-service darkhttpd start
Here you can see that we place our website files under /var/www. Make sure you let lbu know to include this directory or else you will lose these files on reboot!
lbu include /etc/init.d/darkhttpd
lbu include /var/www
Also notice the maxconn parameter. Feel free to adjust this as you see fit. That’s it!
nginxIf you require a little more flexibility or control of your web server, you can always use nginx instead.
doas apk add nginx
Then create a site-specific configuration file at /etc/nginx/http.d/yourdomain.com.conf:
server {
listen 8080;
server_name yourdomain.com;
root /var/www/yourdomain.com;
index index.html;
try_files $uri $uri/ =404;
error_page 404 /404;
location = /404 { internal; }
}
The same rules used for darkhttpd apply for keeping files persistent on reboots / power cycles:
rc-update add nginx default
rc-service nginx start
lbu include /etc/nginx
lbu include /var/www
rsyncTo sync our changes from our local machine to this Raspberry Pi, we will need rsync:
doas apk add rsync
Feel free to skip this if you prefer to use something like scp or directly port files over with an FTP client. This is just personal preference.
lbuNow that we have everything we want/need on our Pi, include all these configuration and website files you wish to keep persistent on your micro SD card:
lbu commit -d
Our final software stack at a glance:
dropbear (setup during install)darkhttpdlbursyncSince we plan to use our external VPS for handling the TLS termination, we only need to open a single port (80 in this example, but use whatever you want) on our local network. I’m not going to go into super detail here, since home networks vary greatly. Just know that you need to open port 80 and ensure you target the IP of your Raspberry Pi Zero device (which you should also setup a static IP to avoid headaches). Pay close attention to the targeted ports in the instructions below.
Important: If your ISP hands out a dynamic IP for your home network, you will need to configure some form of DDNS. My recommendation would be DuckDNS.
For our needs we really only need the low-end specs for our VPS:
Setup and install the above as you normally would with a standard Alpine configuration. Once complete, login by using the provided ssh target under the VPS settings page.
The only real package we need on this VPS is socat. We will be using socat to direct internet traffic to our local Raspberry Pi Zero. (Since TierHive is a NAT VPS provider)
apk add socat
Then create /etc/local.d/forward.start:
#!/bin/sh
socat TCP-LISTEN:80,fork,reuseaddr TCP:<your-home-ip>:48080 &
Replace <your-home-ip> with your actual home IP or DDNS hostname, and 48080 with whatever external port you forwarded on your router.
Also take note, you will need your router to be forwarding ports properly. So for example:
TCP 48080 -> Pi:<PORT-CONFIGURED>
Now we will tie TierHive’s HAProxy Edge service to our newly setup VPS. Navigate to the “HAProxy” menu in the TierHive admin and select “Add Domain”. Input your custom domain and follow the instructions to add a TXT file to your DNS records. This is used to authenticate your domain.
Once that is confirmed, click the “Configure Backends” button. Then do the following:
80 for our example config)It will take roughly 5 minutes for these changes to propagate. Once complete, you will now have TierHive’s HAProxy running in front of your tiny VPS, which points to your local Pi Zero!
You could stop now and have a working website. The major problem is lack of TLS, which isn’t ideal for websites in 2026. The good news is that TierHive has automatic SSL renewal built-in to their HAProxy service. You just need to click the “Active SSL” within your domain settings under the HAProxy admin page.
Give it a little bit of time to propagate and you’re golden! Now all your TLS handshakes are handled by TierHive, freeing up your Pi to focus on just serving the static content.
Backups are extremely easy with this setup. On the same network you can simply run:
ssh root@YOUR-PI-ZERO-IP "dd if=/dev/mmcblk0 bs=4M" > zero-backup.img
This image is a byte-for-byte clone. Flash it to a new card and it will boot up the exact same as your current micro SD card. Just make sure the new SD card is the same size or larger!
You can also freely remove the micro SD card once the Pi has fully booted, since it runs in memory. Then you can plug the card into a separate device and backup directly, instead of relying on a spotty network connection!
That’s all there is to it. It might seem a little complex at first glance, but I assure you it’s fairly easy once you get started.
Hopefully this inspires others to give self-hosting a shot!