Comment by c0nsumer
20 hours ago
This feels a little weird because while they are running the website itself (HTTP) off the Pi, they are handing off all TLS to a cloud provider.
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.
Yeah, I've seen this in more than a few places. There was a blog "running on a Wii" that, IIRC, was doing the same thing.
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.
The TLS termination isn't actually on the VPS. The article details that Tierhive has an haproxy edge service (handling the TLS), that then has the vps as the backend, but that vps is just doing tcp proxying with socat to the ddns exposed home server fqdn. Feels like a lot of unnecessary loops. Kinda fun I guess but, just, why
Not disagreeing with you, but that makes it even worse.
1 reply →
Yes it is, "we plan to use our external VPS for handling the TLS termination". Edit: Ah I see you are just pointing out termination is on haproxy service not VPS. Thought you were implying it was terminating on pi, my apologies.
3 replies →
This reminds me of the recent "running Doom on DNS" post which in actuality was "running Doom from DNS [as a storage device] on my PC" which is multitudes less impressive.
It reminds me of the footage of Doom running on a pregnancy test. And then it turned out it was another computer just displaying to the build in AMOLED display.
What was supposed to be a cool achievement is rendered pointless when one of the key elements is offloaded elsewhere.
Sometimes these demos enable caching on the reverse proxy. So then for these tiny demo html pages you request, you may not even reach the fun tiny computer it is supposed to demonstrate.
I wouldn’t consider “the way most people do TLS in 2026” weird. That said this isn’t all that impressive or interesting, a computer… serving a website.
Is sending plaintext traffic over the open Internet "the way most people do TLS in 2026"? Am I missing something from the post?
Many (most?) are hosting web applications and/or content in separate applications and sometimes servers from where TLS (HTTPS) termination happens. HAProxy, Traefik, Caddy and Nginx as reverse proxy and TLS termination servers are pretty common, even more so if you're containerizing your applications themselves. It dramatically simplifies the application stack.
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.
5 replies →
Considering that a 'base' raspbian type install can be something like 160MB of RAM used with openssh running and a lot of other launched-from-systemd daemons in the background, that leaves plenty of RAM available for a stock apache2 or nginx setup with TLS. No it won't be able to serve a ton of simultaneous requests, but I'm in agreement with the other comments here that doing purely port 80/http and putting it behind a secondary TLS proxy is not really "serving the website" from the raspberry pi.
Hmm is linux on arm so frugal still?
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.
It is more than a little weird. A pi zero is more than capable of handling HTTP/1.2 and TLS 1.3 for a handful of connections per second. This machine is 10x what we were running web servers on in the '90s.
Also, all web pages are served from RAM. It's automatic that modern OSes will cache this stuff on first access.
I was initially thinking does the pi zero even have floating point? But then I remembered that encryption only uses integer operations, not even very large ones.
Yeah, I ran a phpbb forum (alongside my normal static site) on a 486 in 2003 or so. It worked. It was slow, but it worked just fine for my friends and I! I remember it took multiple minutes to generate the SSH server key after the initial install lol
A 486 in 2003? Pentiums were shipping by the mid-90s, did you just have super old hardware lying around?
I retired my 486 in ‘95 or thereabouts…
1 reply →
Anyone remember 32 bit/33 MHz PCI slot SSL accelerator cards? As I recall openbsd had kernel driver support for several
Yes. I still have one. I used it in a Soekris 486-class machine running OpenBSD for many, many years. I stopped using the Soekris when they dropped driver support for the accelerator. I think i386 support might be gone now too. Cool little card; I think I might still have it in a drawer somewhere.
In unrelated news: I think the Magic-1 is still online. ( https://www.magic-1.org be gentle with it)
>This machine is 10x what we were running web servers on in the '90s.
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.
You can host such sites perfectly well nowadays. I’ve often served hand-written HTML pages of only few lines
1 reply →
The contents of webpages are largely the same.
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?
2 replies →
Why even serve TLS here?
because we collectively seem to have decided that plaintext http is worse than.. the computational cost to the planet.