Config & Secrets

Slipway manages runtime configuration for applications deployed on Slipway. It is intentionally not a general-purpose vault: config stays in the existing global, environment, and app variable surfaces and is resolved when Slipway deploys a container.

Secret or plain config

Every variable has a value type:

• Secret for passwords, tokens, signing keys, private URLs, and credentials. Secret is the safe default.
• Plain config for non-sensitive values such as a log level, feature mode, public URL, or region.

All values are encrypted at rest. Marking a value as Secret additionally masks it in the dashboard and CLI and gives it the safer Omit preview default. App-level overrides use the same encrypted storage as environment-level values.

To change a value type, open the variable's ••• menu on its existing configuration page. There is no separate Secrets tab or separate secret store to keep in sync.

Configuration scopes

Slipway resolves variables in this order:

global < environment < app < Slipway-managed runtime values

Later scopes override earlier scopes. Use the narrowest scope that needs a value:

• Global — shared by every application on the Slipway instance.
• Environment — shared by the apps in one production, staging, or other environment.
• App — needed by only one app, such as a worker-specific concurrency value.
• Slipway-managed — generated by Slipway for a service or runtime capability.

For example, a worker app can override a global LOG_LEVEL. It cannot shadow a Slipway-managed DATABASE_URL created by an attached database service.

Managed values

Slipway marks service connection values such as DATABASE_URL and REDIS_URL as managed secrets. They remain visible in the environment configuration so you can understand the effective runtime config, but they cannot be renamed, edited, removed, or overridden at app scope.

Change or remove the service that owns a managed value instead. This prevents the dashboard and the running service from quietly disagreeing.

Preview policy

Each variable declares what happens when an environment is created from another environment:

Policy	Behavior
Omit	Do not copy the value. This is the default for secrets.
Inherit	Copy the existing value. This is the default for plain config.
Generate new value	Create a new cryptographically random value for the new environment.

Open ••• beside a user-managed variable to choose its policy. Generated values are attributed to Slipway. A production secret is never copied merely because it exists.

Change history

Every configuration change records:

• the variable key and scope;
• who changed it and when;
• whether it was created, updated, rotated, or deleted;
• its value type, ownership, and preview policy.

Secret values are never written to the audit event. Owners and operators can review these events in Settings → Audit Log or with:

slipway audit-log

Changing a secret value is recorded as a rotation. Slipway does not currently rotate third-party credentials automatically; rotate the credential at its provider, update the value in Slipway, and redeploy the affected app.

Deployment fingerprints

At deploy time Slipway resolves the effective global, environment, app, and Slipway-managed values. It stores a keyed configuration fingerprint and a value-free manifest on the deployment.

The deployment page shows the short fingerprint and variable count. Matching fingerprints mean the resolved key/value set was identical; a changed fingerprint tells you configuration changed even when the Git commit did not.

The manifest stores keys, scopes, types, ownership, and preview policies—not secret values. The deployment log also includes only the short fingerprint and count.

Editing values

Use the existing dashboard surfaces:

1. Settings → Global Environment for instance-wide values.
2. A project's Environment variables section for environment values.
3. An app's Environment variables section for app-only overrides.

The CLI manages environment-scoped values:

slipway env:set SESSION_SECRET=replace-me
slipway env:set LOG_LEVEL=info --env staging
slipway env:unset OLD_TOKEN
slipway env

The CLI masks variables marked as secrets. Use the dashboard when you need to change type, description, or preview policy.

Configuration changes take effect on the next deployment:

slipway slide

Operational guidance

• Keep .env files and credentials out of source control.
• Prefer app scope when only one process needs a credential.
• Leave production secrets on Omit unless reuse is deliberate and safe.
• Use Generate new value for self-contained signing or session secrets in copied environments.
• Use different third-party credentials for production and non-production systems.
• Never log process.env or individual secret values from your application.

What Slipway does not do

Slipway does not provide dynamic secrets, external vault synchronization, automatic provider rotation, repository scanning, arbitrary-app SDKs, or encrypted secret export/import. Its job is narrower: make the configuration path for applications deployed on Slipway understandable, encrypted, auditable, and reproducible.

What's next?

• Learn the full environment variable cascade
• Configure Global Environment Variables
• Add managed credentials with Database Services