F ForkDeploy

Platform

Secrets & env vars

ForkDeploy treats plain configuration and sensitive values differently on purpose. Here's the distinction, and how each one reaches your running services.

Two kinds of values

Environment variables

Plain configuration for a service, things like a feature flag or a public API URL. Stored as-is, scoped to one service. Not encrypted, because it was never sensitive to begin with.

Secrets

Anything sensitive: passwords, API keys, database URLs, tokens. Encrypted at rest (AES-256-GCM) the moment you save it, and only decrypted server-side when it's injected into the services you chose. Never returned in plain text by the API or shown in logs.

In practice, everything you type into the dashboard's "Secrets" step is saved as an encrypted secret. That's the safe default, and there's no separate form for plain env vars today. Env vars still exist under the hood (for example, generated database connection details), you just won't hand-enter one as "not a secret" in the current dashboard.

Sharing a secret across services

A secret can be project-wide (every service in the project gets it) or scoped to just the services that need it. Only share a secret with the services that actually need it, smaller blast radius if something ever goes wrong downstream.

How values reach your service

  • ✓ At deploy time, your secrets are decrypted and merged with plain env vars. If a secret and an env var share a key, the secret wins.
  • ✓ Changes take effect on the next deploy, not instantly. Redeploy after updating a value.
  • ✓ If a value is needed while your image is being built (like a NEXT_PUBLIC_* key), declare it as an ARG in a custom Dockerfile; generated Dockerfiles do this automatically.
  • ✓ In production, values are delivered to your containers as Kubernetes secrets, never baked into the image itself.

For who inside ForkDeploy can see these values, see Permissions.