Frontend: Usually built into static files (HTML, JS, CSS) or a Node server that serves the app (e.g. Next.js in server mode). Static assets can be served from a CDN or static host (Vercel, Netlify, S3 + CloudFront). A Node app needs a runtime (VM, container, or serverless) that runs the process.

Backend: A running process (Node, Python, Go, etc.) that listens on a port. It needs a host (VM, container, serverless) and often a database and secrets (env or vault). The frontend must know the API base URL (e.g. `https://api.myapp.com`) so it can send requests; that is usually an env var at build time or runtime.

Single platform (e.g. Vercel, Railway): You deploy one repo; the platform builds the frontend and runs the API (e.g. Next.js API routes or a separate server). One URL or two (app + api subdomain) but one pipeline and one place to configure env. Easiest for full stack frameworks like Next.js.

Separate front and back: Frontend deploys to Vercel/Netlify/S3; backend deploys to Railway/Fly/Render/AWS. You configure two pipelines and two env sets. The frontend build gets `NEXT_PUBLIC_API_URL=https://api.myapp.com` (or similar); the backend gets `DATABASE_URL`, secrets, etc. More flexible (scale or change one side independently) but more to manage.

Frontend: Only public env (e.g. `NEXT_PUBLIC_*` in Next.js) is safe; it is baked into the bundle and visible to users. Use it for API base URL, feature flags, public keys. Never put secrets (API keys, DB URLs) in frontend env.

Backend: All secrets (DB URL, API keys, JWT secret) go in server env or a secrets manager. The backend reads them at startup. In production, set these in the host (Vercel, Railway, etc.) or inject them at deploy time; never commit them.

The backend needs a database that is reachable from where it runs (same VPC or allowed IP). Run migrations as part of deploy (or in a separate step) so the schema is up to date. Use a managed DB (PlanetScale, Neon, RDS) so you do not manage the server; connect with the URL from env.

The platform or load balancer should health check your backend (e.g. GET /health returns 200 when the app and DB are reachable). If health fails, the platform stops sending traffic and can restart the process. Rollback: Keep the previous version deployable (e.g. by tag or commit); if the new deploy is broken, redeploy the previous version or switch traffic back (blue/green). Have a one-command or one-click rollback so you are not debugging in production at 2 a.m.