[Svelte Series 19] Deployment, environment variables, and production checklists

Reliable apps demand repeatable deployments. This chapter shows how to keep environment variables, adapters, and CI/CD in sync.

Key terms

1. Environment variable: values stored outside the codebase—API keys, DB URLs—loaded via .env or the hosting platform.
2. Adapter: the SvelteKit plugin that turns builds into targets for Vercel, Node, Cloudflare, and so on.
3. CI/CD: a pipeline that automatically tests, builds, and deploys when you push.
4. Rollback: the preplanned procedure that returns to a previous version if production misbehaves.

Core ideas

Environment variables reside outside the repo; split .env files per environment, and load server-only values with $env/static/private or $env/dynamic/private. Adapters dictate which runtime the build runs on. Continuous Integration and Delivery ensure every push follows the same validation path.

Hidden rules checklist

• $env/static/* locks values at build time. If something changes later, switch to $env/dynamic/*.
• .env files stay out of Git. Commit .env.example if you need a template.
• Only one adapter can be active. Replace adapter-auto explicitly when moving to adapter-node (or similar).

Code examples

Structure your environment files like this:

.env                # shared local defaults
.env.local          # developer-specific overrides
.env.production     # server-only values

const dbUrl = PRIVATE_DB_URL;
const apiKey = env.API_KEY;

Optional: automate CI/CD and rollbacks

Only add this flow when you have the time. For club projects, manual deploys already go a long way.

name: deploy
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v3
      - run: pnpm install --frozen-lockfile
      - run: pnpm test
      - run: pnpm run build

If you deploy WebSockets or SSE, prefer adapters that keep a Node runtime alive (adapter-node, adapter-vercel, etc.). Pure static hosts (Vercel Edge, Cloudflare Pages) may throttle long-lived connections, so swap adapters only when the feature needs it.

Why it matters

Messy environment variables lead to mismatched values on every deploy. Without CI, it is unclear who shipped which version. Even small club apps benefit from a documented, repeatable flow that new teammates can follow.

Practice

• Try it: split .env per environment and write code that uses both $env/static and $env/dynamic.
• Extend it: base a GitHub Actions workflow on the sample to run tests plus builds.
• Debug it: when deploys fail, inspect the adapter configuration and where environment variables load first.
• Definition of done: document the env list and adapter choice so anyone can perform the same deploy.

Wrap-up

With deployments sorted, your product is ready to show to others. The final chapter bundles every concept into a capstone app.