set_env

sh.fline/fline · Verify this server

Set one environment variable for the project. `secret` says which store it goes to and it is REQUIRED, because the two are not interchangeable and there is no default that is right for both. secret=false writes a PLAINTEXT value: it is stored as written, returned by list_env_names, shown in the console, and rendered into every service's environment — a model name, a log level, a public URL, a feature flag. Choose it only for a value you would paste into a public repository. secret=true writes to the secret store, which no tool and no screen can read back, ever, this one included. Use it for a value you already hold: one you generated yourself, such as a random session key, or one the person already pasted into the chat, in which case suggest they replace it with a fresh key through get_secrets_link. For a password or key the person has not given you, use get_secrets_link; never ask them to paste it into the chat. secret=true replaces a secret that is already set. secret=false has four refusals, each with a way on. A name whose final underscore-separated segment is KEY, TOKEN, SECRET, PASSWORD, PASS, PWD, CREDENTIAL, CREDENTIALS or DSN is refused: rename the variable, or send the same value with secret=true. An empty value is refused: an empty variable is indistinguishable from an absent one and the deploy fails on it later, so declare the name and leave the value to a person instead. A name that already holds a secret is refused: call delete_env_name first, then set it. And a name the plan binds to a managed database or an addon is refused, because the platform provisions that and writes the connection string itself. Do not set such a name with secret=true either: the platform skips wiring a variable that already holds a value, so the database is never connected. A plaintext value survives the next analysis; a secret still does not. Either takes effect on the next deploy or restart.