5 ms·

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 c

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.

ironhaven 5mo ago
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.
spijdar 5mo ago
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.
- indigodaddy 5mo ago
  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
  - Antirust3743 5mo ago
    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.
    - indigodaddy 5mo ago
      The VPS is running socat only and just doing tcp forwarding. There is a shared haproxy also run by their same host, sitting in front of the VPS and is handling the TLS. I encourage you to read the article fully. They probably should have said "VPS provider" instead of VPS for the TLS bit.
      - deleted 5mo ago
        [deleted]
    - indigodaddy 5mo ago
      But it's plain text like you said in another comment after the haproxy, so two more plain text paths (with at least one going through the internet (vps->pi), not sure if haproxy->VPS is internal to the provider network (maybe)), so not ideal in my book
  - SahAssar 5mo ago
    Not disagreeing with you, but that makes it even worse.
    - indigodaddy 5mo ago
      Agreed
- jorvi 5mo ago
  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.
wang_li 5mo ago
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.
- joe_mamba 5mo ago
  >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.
  - huijzer 5mo ago
    You can host such sites perfectly well nowadays. I’ve often served hand-written HTML pages of only few lines
    - lq9AJ8yrfs 5mo ago
      LLMs, including open ones, are really good at this it turns out. It stands to reason, there is tons of training material out there no doubt they have consumed and are ready to regurgitate. 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.
allthetime 5mo ago
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.
- Antirust3743 5mo ago
  Is sending plaintext traffic over the open Internet "the way most people do TLS in 2026"? Am I missing something from the post?
  - tracker1 5mo ago
    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.
    - SahAssar 5mo ago
      It's vastly different to do TLS termination within your own network and to do it on a rando VPS and then send normal TCP over the internet. It's not an argument of it being on the same server.
      - traderj0e 5mo ago
        The VPS is your security in this case. It's not sending plaintext over the internet, is it? 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.
        SahAssar 5mo ago
walrus01 5mo ago
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.
- nottorp 5mo ago
  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.
ClikeX 5mo ago
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.
cachius 5mo ago
Why even serve TLS here?
- dijit 5mo ago
  because we collectively seem to have decided that plaintext http is worse than.. the computational cost to the planet.
  - deleted 5mo ago
    [deleted]

ironhaven 5mo ago

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.

spijdar 5mo ago

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.

indigodaddy 5mo ago
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
- Antirust3743 5mo ago
  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.
  - indigodaddy 5mo ago
    The VPS is running socat only and just doing tcp forwarding. There is a shared haproxy also run by their same host, sitting in front of the VPS and is handling the TLS. I encourage you to read the article fully. They probably should have said "VPS provider" instead of VPS for the TLS bit.
    - deleted 5mo ago
      [deleted]
  - indigodaddy 5mo ago
    But it's plain text like you said in another comment after the haproxy, so two more plain text paths (with at least one going through the internet (vps->pi), not sure if haproxy->VPS is internal to the provider network (maybe)), so not ideal in my book
- SahAssar 5mo ago
  Not disagreeing with you, but that makes it even worse.
  - indigodaddy 5mo ago
    Agreed
jorvi 5mo ago
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.

wang_li 5mo ago

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.

joe_mamba 5mo ago
>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.
- huijzer 5mo ago
  You can host such sites perfectly well nowadays. I’ve often served hand-written HTML pages of only few lines
  - lq9AJ8yrfs 5mo ago
    LLMs, including open ones, are really good at this it turns out. It stands to reason, there is tons of training material out there no doubt they have consumed and are ready to regurgitate. 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.

allthetime 5mo ago

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.

Antirust3743 5mo ago
Is sending plaintext traffic over the open Internet "the way most people do TLS in 2026"? Am I missing something from the post?
- tracker1 5mo ago
  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.
  - SahAssar 5mo ago
    It's vastly different to do TLS termination within your own network and to do it on a rando VPS and then send normal TCP over the internet. It's not an argument of it being on the same server.
    - traderj0e 5mo ago
      The VPS is your security in this case. It's not sending plaintext over the internet, is it? 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.
      - SahAssar 5mo ago

walrus01 5mo ago

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.

nottorp 5mo ago
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.

ClikeX 5mo ago

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.

cachius 5mo ago

Why even serve TLS here?

dijit 5mo ago
because we collectively seem to have decided that plaintext http is worse than.. the computational cost to the planet.
- deleted 5mo ago
  [deleted]