Building FXRseen — Part 1: From a bare server to a live site
This is the first post on FXRseen, and fittingly, it’s about building FXRseen itself. On the evening of October 24, 2026, the starting point was about as bare as it gets: a brand-new, small cloud server with nothing on it except a fresh operating system and its system updates.
The goal was simple, and deliberately boring in a good way: a personal blog that loads fast and is hard to hack.
The plan
A traditional database-backed blogging platform was considered, then set aside. Its plugin and update history made a static site the better fit.
Instead, the approach is:
- A static site generator, running on a separate build machine — not on the server that serves the site
- A web server on that server, serving only finished HTML, CSS, and images
- A CDN in front, for DNS, caching, and HTTPS
- A private source repo as backup, so the server can be rebuilt if it ever fails
A static site has no login page and no database to attack, which removes most of the usual blog attack surface. A small server is more than enough for serving static files, especially with a CDN caching in front of it.
Step 1: access and hardening
First, a dedicated deploy account was created on the server, with key-based login only. That account is how new posts get deployed, and it can be revoked by removing that one key.
Then came hardening, in a deliberately safe order:
- Firewalls: allow only the connections the site actually needs before turning the host firewall on, so we couldn’t lock ourselves out. The cloud provider’s firewall is the first layer; the host firewall inside the server is the second.
- Swap space, as insurance for a small amount of memory.
- Login-attempt blocking and automatic security updates, so repeated failed logins get blocked and patches apply themselves.
One thing learned along the way: the deploy account has no password, so it can’t run admin commands remotely. That meant the hardening commands were run by hand in the cloud console session — which turned out to be a good thing, because it made every step visible and easy to learn from.
Step 2: web server, DNS, and HTTPS
Next, a web server was installed, a web root was created and handed to the deploy account, so future deploys need no admin access. A clean placeholder page went up first, in the style this site aims for: a dark header, a simple wordmark, readable text, no clutter.
Then DNS: records for fxrseen.com and www, both proxied through the CDN, pointing at the server. At first, the CDN reported the server as down, because it was set to try HTTPS to a server that only listened on plain HTTP at that point. Switching to a plain-HTTP test mode for testing proved the site worked end to end.
The final HTTPS step used an origin certificate from the CDN provider, installed on the server with its private key locked down, with the web server configured for HTTPS, www redirecting to the root domain, and HTTP redirecting to HTTPS. The CDN was then switched to strict end-to-end HTTPS, so traffic is encrypted all the way: visitor to CDN, and CDN to the server.
The redirect loop, and what it taught us
The one real bug of the evening was a redirect loop: the browser kept saying there were too many redirects.
It was a classic CDN trap. The web server was redirecting all plain HTTP to HTTPS, but if the CDN is in a mode where it still fetches the server over plain HTTP — the server kept saying “go to HTTPS,” the CDN kept passing that back, and the browser kept looping. Switching the CDN to strict end-to-end HTTPS, so it fetches the server over HTTPS too, broke the loop immediately.
Final checks all passed: https://fxrseen.com/ returns the page, http:// redirects to HTTPS, and https://www.fxrseen.com/ redirects to the root domain.
What’s next
The next step is this site itself: replacing the placeholder with a real homepage, topic pages, search, and an RSS feed — built on a separate machine, deployed as static files, and served by the same web server and CDN setup described above.
No database. No login page. Just fast, clean pages about photography, tech, cars, and building things — including this site.