HeadlinesBriefing favicon HeadlinesBriefing.com

Web Server Deployment: Hobby Scale Pitfalls

Hacker News •
×

Deploying a web app for others to host locks you out of many efficiency tricks. You need TLS handling separate from the app, and a capable reverse proxy to off‑load static file serving. If either component is containerized, admins must open holes to let the proxy read the static files, leading to messy deployments and wasted effort.

In hobby setups, static files often stay bundled with the app, forcing users to re‑enable file serving when they discover a cloud‑native reverse proxy that does nothing but proxying. This back‑and‑forth adds latency and bloat to low‑end hardware. In professional environments, static files are deployed to an S3 bucket and fronted by a CDN, avoiding the issue entirely.

Unauthenticated visits benefit from caching. An hour’s stale time seems reasonable, but built‑in middleware often caches static files unnecessarily, bloating memory. External caching solutions like caddy, nginx, or cloudflare can be misconfigured, corrupting responses or overusing resources.

Authenticated traffic needs a shorter stale period—about a minute—to handle bursts. Adding support for external caches complicates deployment, so many projects drop external middleware and move authentication before caching, which is frustrating when the framework’s cache support is weak.

Finally, choosing a language matters. A server‑side‑rendered SPA in JavaScript is attractive for code reuse, but embedding Node.js into a non‑JavaScript backend is fragile. Separate frontend processes help isolate resources but add complexity.