Short-lived values
Some values are never stored at all, so penv asks the upstream system to mint one when you need it, and it expires on its own.
Most keys hold a value someone typed once. A few hold nothing at all, and the credential is made the moment a job asks for it, with an expiry attached.
What is stored, and what is not
A key marked as short-lived has no stored value and never has had one. When a job asks for it, penv calls the upstream system and hands back what came out, and it records who asked and when the credential expires. The credential itself is handed over once and kept nowhere.
One engine ships today: AWS STS with an assumed role, aws-sts-assume-role. A job gets temporary AWS credentials for the role you connected, and nothing durable exists to leak.
Marking one in the schema
# @type=string @dynamicFrom=aws-sts-assume-role
AWS_SESSION_TOKEN=@dynamicFrom is a marker penv reads and the console renders. It configures nothing. The engine it calls and the lifetime it grants are both set in the console, under Integrations then Dynamic Engines.
Reads skip it and writes are refused
| What you do | What happens |
|---|---|
penv run | The key is skipped, and penv says how many were skipped |
penv pull | The key is left out of the .env it writes |
penv push or penv set | Refused with dynamic, exit code 3 |
penv: that key is minted by an engine; edit it in the console.
Change the engine it comes from in the console, or push a static key under another name.The server lists these keys under skipped in its answer rather than dropping them silently, so a tool that reads the environment knows the key exists and knows why it has no value.
A key with no value here is not a key that is missing. The server answers 409 dynamic instead of a 404 for exactly that reason. Treating it as absent would lead a caller to write over a credential that exists.
penv pull never mints one
pull writes a file, and a file is the wrong place for a credential with a lease on it. A leased credential baked into a build would expire partway through the deploy, which is the failure penv exists to prevent. So pull leaves the key out and your job asks for a fresh one at the moment it runs.
What you are taking on
A stored value needs no network once it reaches your process. A short-lived one needs your machine to reach penv, and penv to reach AWS, every time it is needed.
The lease route is off by default and is turned on per environment in the console. It fails closed, so an environment nobody enabled it for answers no leases at all. Generating a credential from the console works either way, which means turning the route off is never a lockout.
Use a short-lived value where a credential that dies on its own is worth that dependency. Leave everything else stored.
Taking one back
Every engine declares what revocation it supports. AWS STS supports none per lease: temporary credentials from AssumeRole cannot be cancelled one at a time.
So the console shows no per-lease revoke button for that engine. It shows the expiry, and it offers you a deny policy keyed on aws:TokenIssueTime that kills every session on the role at once. penv writes that policy out for you and does not apply it, because applying it would need permission to edit your own IAM roles. The leases are marked revoked once you confirm you applied it.
Deleting a connection or an engine that still has live leases is refused. The engines are disabled straight away either way, so nothing keeps minting while you decide.
Next: the record of who did what.