Product

Environment variables and secrets

Stackap stores each environment variable encrypted and bound to its project and name, never shows the value back, and hands it to your app through a private file at start.

What it does

You set a variable with stackap env set <slug> KEY --stdin, and the value comes from standard input, so it never appears in a command line, a shell history or an agent's transcript. Setting the same key again replaces it. Removing one is env rm.

Each value is encrypted with AES-256-GCM under the platform's master key, and the project and the variable name are bound into the encryption, so a stored value cannot be copied from one project or key to another and still decrypt. Listing variables returns the names and a mask, never the values.

A few variables are managed by Stackap itself, such as the one carrying the database connection string. Those are flagged as system variables, and an attempt to change or delete one is refused with a clear message.

How it works

When a container starts, the values are written to a private file readable only by the process that launches it and passed to the container from there. They are not placed on a command line, where any process listing could read them. The audit log records that a variable was set or removed, with the key and never the value.

Because values are read when a container starts, a changed value reaches the app on its next start or deploy. During a build the rule is different and deliberate: names beginning with NEXT_PUBLIC_ are passed through, because they are public by design, and every other value is replaced by a placeholder, so no secret is baked into an image layer.

In practice

$ stackap env ls my-app
$ stackap env set my-app API_KEY --stdin
$ stackap env rm my-app OLD_KEY

Early-access scope

• You cannot read a value back. If you lose a secret, set a new one; there is no reveal button.
• No per-environment or per-branch variables. A project has one set, and only the production branch builds.
• Non-public values are placeholders at build time, so code that needs a real secret during a build does not work.
• There is no history of past values and no scheduled rotation.
• The master key is a single point of failure for recovery.

Questions

Last updated 2026-10-03.