Environment variables and secrets

Where to add variables

Open your app and go to App → Settings → Environment variables. Add each variable as a NAME and VALUE pair.

DATABASE_URL=postgres://...
REDIS_URL=redis://...
JWT_SECRET=change-me
NODE_ENV=production

Values are configured for the production app. Keep local-only values in your local .env file, and keep production values in Shiprr.

What happens when you save

Saving environment variables updates the app configuration immediately. If the app is running, Shiprr starts a deploy so new values apply to live replicas after rollout.

• Running apps are redeployed after env var changes.
• Stopped apps receive the new values on the next start or deploy.
• Build and runtime logs can show failures caused by missing variables.

Masked and revealed values

Env var values are masked in the dashboard until an authorized user reveals them. If a value is still masked, reveal it or replace it before saving changes to that row.

Masking protects values in the dashboard, but it cannot protect secrets printed by your own build scripts or application code.

Paste .env blocks

The dashboard can parse a pasted multi-line .env block into separate variable rows.

PUBLIC_API_BASE_URL=https://api.example.com
PUBLIC_SITE_URL=https://example.com
FEATURE_SIGNUP_V2=true
STRIPE_SECRET_KEY=sk_live_...

• Blank lines and lines starting with # are skipped.
• Lines may start with export.
• Each parsed line must use NAME=value.
• Values may contain additional = characters.
• Matching quotes around the value are removed.

Public vs private variables

Backend-only secrets should stay private and should not be exposed to browser code. Frontend frameworks often use naming conventions for variables that are allowed in client bundles.

# Private backend values
DATABASE_URL=postgres://...
JWT_SECRET=change-me

# Public frontend values
PUBLIC_API_BASE_URL=https://api.example.com
VITE_PUBLIC_SITE_URL=https://example.com
NEXT_PUBLIC_SITE_URL=https://example.com

Treat any variable embedded into frontend code as public. Never store database passwords, private API keys, or signing secrets in public frontend variables.

Framework examples

• Node APIs: DATABASE_URL, REDIS_URL, JWT_SECRET, NODE_ENV=production.
• SvelteKit: private server vars plus public vars prefixed for your app, such as PUBLIC_API_BASE_URL.
• Next.js: private server vars plus public vars prefixed with NEXT_PUBLIC_.
• Laravel: APP_KEY, APP_ENV=production, APP_DEBUG=false, APP_URL, database vars.
• Python: DATABASE_URL, SECRET_KEY, PYTHONUNBUFFERED=1.

Safe practices

• Keep production secrets out of Git.
• Do not print secret values from build scripts or app code.
• Rotate secrets if they were committed, pasted into chat, or exposed in logs.
• Validate required config on startup so missing values fail clearly.
• Use clear variable names that your team can understand during incidents.

Debug env var problems

• Use build logs if install or build steps need a variable and fail.
• Use runtime logs if the app starts and then crashes from missing config.
• Check spelling, casing, and framework-specific public variable prefixes.
• Redeploy after changing variables if the app is not already redeploying.