The app is typed and strict — time to ship it. Three parts: the build, environment variables, and the key lesson about keys.

The build. In dev, Vite compiles .ts on the fly. For production you create an optimized, static bundle:

npm run build     # tsc --noEmit && vite build → dist/

The build script first type-checks (tsc --noEmit), and only if that's clean does it bundle (vite build) into a dist/ folder: combined, minified JavaScript, CSS and index.html. You upload that dist/ to any static host (Netlify, GitHub Pages, Railway).

Environment variables. We keep the API key in a .env file, not in code:

const API_KEY = import.meta.env.VITE_NASA_API_KEY;

Vite exposes to the browser only vars with the VITE_ prefix — a guard rail so a server secret doesn't "slip out" by accident.

And the key lesson — the truth about keys. Think about where VITE_NASA_API_KEY ends up after vite build. Vite inlines it straight into the bundle — into dist/assets/*.js. Open that file (or the browser DevTools) and anyone can read your key in plaintext.

That's fine for NASA's key — it's public and rate-limited by design; the worst someone does is spend your ~30 requests/hour. But from it comes a principle:

A secret key can never live in front-end code. If a key must stay secret (payments, a database, a mail API), it belongs on a server that proxies the request — the client calls your server, and the server (holding the hidden key) calls the external API.

And that's the honest answer to "why does a server-side course exist at all?". Exactly for this: the things that can't be in the browser — secrets, trusted validation, data ownership.