How I built this website on a Raspberry Pi
In this technical retrospective (2025), @mirawelner shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Post-ZIRP & AI (2023–2026)
COMMUNITY SCORE 115 points
TOTAL DISCUSSIONS 90 comments
I had set one (Pi 3B+)up to do both a website as well as a public service announcement slideshow display for a local Community TV. Used PHP/CMSimple for the site and wrote a custom slider.
Things I learned:
- set the pi to reboot on poweroff
- Given this was TV used the AV output on the PI displaying in NTSC 4:3 (to support customers with older TVs), so had to be aware of overscan margins
- Added a startup script to start chromium in kiosk mode and open the slider page for the show side. worked 95% of the time, if not just power off then on.
- part of the troubleshooting was just unplug and replug - but SD cards will choke on too many power cycles, so instead of SD use a USB->SATA cable and a regular spinning rust HDD - slower but VERY reliable, the journaling file system can recover after power-outage.
- Get the right USB->SATA cable, USB-3 models seem to be more responsive and the PI can boot from them, there are some are too slow and the Pi will fail to boot.
- Slider had it's own login page (outside of CMSimple) to remotely manage the slideshow.
- Also changed the SSH Port to something uncommon to thwart bad guys.
Great article—thanks for sharing! I did something similar nine years ago with a Raspberry Pi 3 Model B. It stayed online for nearly a decade until it went offline at the end of 2024, following Google's decision to sunset my OnHub router.
Initially, I used it as a CUPS server to turn a non-networked Brother printer (HL-2240) into a wireless printer after Google discontinued Google Cloud Print.
The printing project was a lot of fun and inspired me to dive into another challenge: self-hosting. Along the way, I learned a great deal about Apache, SSL certificates, security, and just how fragile SD cards can be!
The print server still works well, though I’ve since downsized to a Raspberry Pi Zero W.
If you’re using Apache2 you might also want to look at mod_md, not just certbot: https://httpd.apache.org/docs/2.4/mod/mod_md.html ↗
Also, if you want to minimize the amount of JS, then just drop jQuery and use fetch, it’s reasonably pleasant too: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API ↗
Lovely article!
This is a wonderful project and an even more wonderful write-up, I wish I came across more in this tone! I'll just add to anyone following in these footsteps: be careful what type of website you host on your Pi. Self-hosting is great, but if you expose services on your home network to the internet, expect people to try to hack you. What type of site you host will either make this very hard or very easy. The difference between compromising a VPS and compromising your home web server is now they have access to your actual LAN. Cloudflare has a pretty good WAF on the free tier, look at it as another learning opportunity.
I like how the author didn’t try to be overly clever with it. They could’ve used Docker to install and isolate dependencies, Caddy or Traefik to serve the site and manage SSL automatically, maybe even k3s to run a mini cluster for HA, Tailscale to avoid manual port forwarding, Terraform for future auto-provisioning without hassle, or Ansible to prepare the machine and all that jazz.
Instead, they took the simplest possible route that works: installing the web server on bare metal, serving plain HTML and CSS, and using direct port forwarding via the router. This was a delightful read.