Deployment

This project has a genuinely different shape from almost every other Astro course on this site: it's a static site by default (Chapter 1's own real, deliberate choice), with exactly one route — Chapter 5's own /api/convert — opted into on-demand rendering. Deployment has to account for both halves of that hybrid at once, and this chapter's own real headline finding is that Astro's build tooling already handles the split cleanly, with no extra configuration needed to stitch the two together.

Building for Production: Two Outputs From One Command

Verified directly against Astro's own current documentation for the @astrojs/node adapter: once an adapter is installed and at least one route opts into on-demand rendering, astro build produces two real, separate outputs from a single command — exactly the split this project's own hybrid setup needs:

One Server Handles Both Jobs

A genuinely convenient real detail, confirmed directly against Astro's own documentation: in mode: 'standalone' — already set back in Chapter 5 — "the server handles file serving in addition to the page and API routes." The one built server doesn't just answer /api/convert; it also serves every file sitting in dist/client/ directly, with no separate static file server, CDN, or extra configuration required to wire the two together:

HOST and PORT are read directly by the built server itself — Astro's own documentation is explicit that neither Astro nor the adapter loads environment variables on its own behalf, so anything genuinely secret would need its own loading mechanism; this project has no secrets at all to worry about.

PM2 for Process Management

A single, long-lived process, kept alive and restarted automatically if it ever crashes — there's no shared database, no connection pool, and no multi-writer question anywhere in this project (unlike Premier League Predictor: Astro's own real SQLite-file concurrency question), so there's no real reason to run more than one instance at all:

nginx Reverse Proxy

A standard proxy in front of the one running process — plain proxy_pass, nothing route-specific needed yet, since the same process already correctly serves both static files and the API route on its own:

A Real Rate Limit — Specifically for /api/convert

Every other route on this project's own site is free, in every real sense — a prerendered static file costs the server nothing at all to serve beyond a plain file read. Chapter 5's own real, measured finding changes that story for exactly one route: each real request to /api/convert costs the server roughly 14 milliseconds of genuine processing time, compared to Chapter 4's own client-side box, which costs the server nothing whatsoever. That specific route — and only that one — is genuinely worth protecting from a real flood of requests:

No equivalent limit is placed on the static routes at all — there's no real cost to protect there, and adding one would just be friction with nothing genuine behind it.

A Real, Honest Closing Reflection

This entire chapter exists to keep one specific route reachable and correctly deployed — a route Chapter 5's own real, measured evidence already concluded shouldn't be this app's own default. That's worth stating plainly rather than glossing over: if this project were being deployed purely as a production feature rather than as a working, comparable example for this course, the honest, evidence-based choice would be to drop /api/convert, the Node adapter, and this entire chapter's own PM2/rate-limiting setup altogether — deploying as nothing more than a folder of static files with zero server process required at all. This chapter builds out the fuller deployment anyway, specifically because the server-side comparison route is worth keeping reachable for anyone reading this course to try both approaches for real, not because the finished app actually needs it.

Hands-On Exercises