// The machine
A production server, built from a laptop and first principles.
queenbee-core-srv is a self-hosted Linux server running on repurposed hardware. It serves a personal hub and a containerized Next.js portfolio to the public internet — with zero ports opened on the home router and a monthly hosting bill of ₹0.
It exists as a demonstration: every layer — the hardened OS, the zero-trust network path, the reverse proxy, the containers, the deployment flow, and the failure handling — was configured, debugged, and is operated by one person. This page documents how.
This page itself is hosted on independent infrastructure, so it stays available even while the server restarts or is offline — documentation designed to outlive the outage it explains.
// Request path
How a request reaches the metal.
Public traffic never touches an open port. The server makes an outbound connection to a zero-trust mesh network; a public HTTPS endpoint relays visitor traffic back through that authenticated tunnel. The home IP stays hidden, and carrier-grade NAT is irrelevant.
The layers
A repurposed laptop — its battery doubles as a built-in UPS through power cuts, lid closed, running headless on a shelf.
Hardened Linux: minimal services, automatic security patching, everything administered over key-authenticated SSH.
Zero-trust mesh for private administration; a relayed public HTTPS ingress with automatic TLS certificates for visitors.
A rate-limited reverse proxy delivers the static hub directly from disk and forwards application routes to containers.
A dependency-free static hub, and a Next.js portfolio built as a minimal multi-stage container image.
// Posture
Deny by default, disclose by choice.
The design assumption is that every public artifact is read by an adversary. Access is minimized at each layer, and the public pages deliberately avoid volunteering internal specifics.
Key-only SSH with root login disabled. Password authentication is off entirely — possession of a private key is the only way in.
Default-deny policy: nothing listens publicly except what is explicitly allowed, and administration is reachable only over the private mesh.
Automated brute-force banning and continuous log monitoring; probes are dropped and repeat offenders blocked.
No forwarded router ports. Public reachability exists only through an authenticated, encrypted outbound tunnel.
Deployments write only to a user-owned web root — the publish path never touches root, and no credentials are stored in scripts.
Public pages avoid ports, paths and tool-level detail. The "live" log feed on the hub is client-side fiction — real logs never leave the machine.
// Keeping it boring
Self-healing by design, verified by habit.
The goal state of a server is that nothing needs doing. After a power cut or reboot, the init system brings up every service and restart policies revive the application containers — no human in the loop.
Verification over faith
A single health-check script confirms the whole chain after boot: core services, container state, network connectivity, and — most importantly — end-to-end HTTP checks against every served route. "Process running" and "site working" are different facts; the script tests the second.
Deployment
The hub deploys with a single copy command: static files need no build step and no restart — the proxy serves whatever is on disk. Application updates rebuild a container image and swap it in. Every deploy is verified with a marker check against the live site, not assumed from a successful upload.
Failure handling
If the application layer is down while the proxy is up, visitors get a designed offline page — status, an explanation in plain architecture terms, a link to an independently hosted portfolio, and a way to contact the administrator. If the whole machine is off, this page you are reading now remains available, because it lives on separate infrastructure.