Documentation

Environment Variables

Configure your containers with environment variables and secrets.

Variable Types

Build Variables

Available during Docker build (e.g., for private npm packages).

Frontend builds: public-prefixed variables (VITE_*, NEXT_PUBLIC_*, REACT_APP_*, NUXT_PUBLIC_*, PUBLIC_*, EXPO_PUBLIC_*) are compiled into the bundle at build time — SnapDeploy forwards them into the build automatically from your container's env vars. Set or change one, then redeploy for it to take effect. Public-prefixed names that look like secrets (containing SERVICE_ROLE, SECRET or PRIVATE) fail the build on purpose: they would be visible to every visitor.

Runtime Variables

Available when your container runs (database URLs, API keys)

Secrets

Sensitive values such as passwords and API keys. Variables with secret-like names (containing PASSWORD, TOKEN, SECRET, _KEY, etc.) are masked in the dashboard and revealed only when you click the eye icon.

Which value wins: a container has one set of variables; public-prefixed names are additionally forwarded into the build. When the same name is defined in more than one place, the order is:

  1. PORT and HOST, managed by SnapDeploy (plus SERVER_ADDRESS and ASPNETCORE_URLS when you have not set them)
  2. Connection variables injected by an attached add-on
  3. Values you set on the container (deploy form, Container Settings, mobile app or MCP)
  4. Everything else comes from the image itself: your Dockerfile's ENV lines or the base image

Adding Variables During Deployment

When you deploy from GitHub, SnapDeploy scans your repository and shows an Environment Variables Detected screen so you can set values before the first launch.

  1. 1 Click + Deploy in the top bar, choose GitHub repository on the method chooser and select your repository and branch.
  2. 2 On the Environment Variables Detected screen, SnapDeploy lists variables it found in your Dockerfile, .env.example, and framework config, each marked with where it was found. A value that only comes from your Dockerfile is shown read-only ("Set in your Dockerfile") with an Override button; it stays in the image and follows the repository on every push unless you override it. Ones your app needs are tagged Required; likely secrets show a Secret badge and are masked as you type.
  3. 3 Enter a value for each variable. To add one we did not detect, click + Add Variable and provide the key and value.
  4. 4 Click Deploy. The values you entered are saved on the container and injected on every start; variables that only came from your Dockerfile stay in the image.

Editing Variables After Deployment

You can add, change, or delete environment variables on a live container at any time — no need to delete and redeploy. Build-time (public-prefixed) variables need a redeploy to reach the compiled bundle.

  1. 1 On the Containers page, click the gear icon on your container to open Container Settings.
  2. 2 Scroll to the Environment Variables section. Your current variables are listed; secret-named ones are masked with an reveal toggle, and PORT is managed by SnapDeploy and locked. PATH, HOME, USER, SHELL, LANG, TERM, PWD and HOSTNAME are owned by the image and are never injected. Values that come only from your Dockerfile appear in a separate From your Dockerfile list with an Override button; they are not saved on the container until you override them.
  3. 3 Make your changes: click + Add for a new variable, edit a value inline, or click the icon to delete one.
  4. 4 Click Save Environment Variables.

How your changes apply

Environment variables are read when your app starts, so a restart is required for new values to take effect — SnapDeploy handles this for you automatically:

  • If your container is running, SnapDeploy performs a zero-downtime rolling restart (about 2–3 minutes). A progress bar appears on the container card, and the new values take effect once it completes.
  • If your container is sleeping or stopped, the changes are saved and applied automatically the next time it wakes or starts.

Variables provided by an attached add-on (for example DATABASE_URL from a database) are managed by SnapDeploy and take precedence over a value you set by hand. The full order is: the platform-managed PORT and HOST, then add-on values, then values you set, then values in your image.

Common Variables

NODE_ENV=production
DATABASE_URL=postgres://user:pass@host:5432/db
REDIS_URL=redis://host:6379
API_KEY=your-secret-api-key
PORT=3000 # Auto-set by SnapDeploy

Security Best Practices

  • Never commit secrets to Git
  • Use secrets for sensitive values (passwords, API keys)
  • Rotate secrets regularly
  • Use different values for staging and production

Related reading

GitHub Integration Custom Domains