Environment Variables

Jetpacked gives you a secure place to store environment variables that are injected into your container at startup. This covers both secrets you provide manually and credentials that Jetpacked generates automatically for provisioned services.

Adding variables

Go to your project's Environment tab and add key-value pairs. Variables are encrypted at rest and redacted in deployment logs — they are never shown in plain text after saving.

You can also add variables in bulk by pasting a .env file format:

DATABASE_URL=postgres://...
NEXTAUTH_SECRET=your-secret-here
STRIPE_SECRET_KEY=sk_live_...

Auto-injected variables

When Jetpacked provisions a service for your app, it generates the connection credentials and injects them automatically. You do not need to add these yourself.

Service	Auto-injected variable
PostgreSQL	`DATABASE_URL`
MySQL	`DATABASE_URL`
MongoDB	`MONGODB_URI`
Redis	`REDIS_URL`

The injected values are real connection strings pointing to the provisioned instance. They are available from the first deploy onward.

Note: If you add a DATABASE_URL manually, it takes precedence over the auto-injected value. This is useful if you want to use an external database instead of the provisioned one.

Variable precedence

Variables are applied in this order (later entries win):

Auto-injected service credentials
Auto-injected app URL bindings
Variables you set in the Environment tab

Sensitive variable handling

Variables are stored encrypted using AES-256-GCM
They are decrypted only at deploy time, inside the build environment
They appear as [REDACTED] in all log outputs
They are never included in diagnostic reports or error messages

Using .env.example

If your repository contains a .env.example file, Jetpacked reads it during detection and uses the listed keys as hints for which variables your app expects. It does not use the values — only the key names.

This helps Jetpacked flag missing required variables before a deploy attempt rather than after a startup failure.