Deploy your app

Three ways a value reaches a running process, and how to pick the one your host allows.

Change it once. It lands everywhere your code runs. This page is the three ways that last part happens, so you can pick the one your host allows.

The three ways

penv run wraps your process. A machine credential sits in PENV_TOKEN, penv validates the environment against .env.schema, and the values go into the child process and nowhere else. This is the default, and it is the only one of the three where a rotated value reaches a restart without a redeploy.

penv pull writes a file in a build step. For a platform that has to read a file, penv pull writes a plain .env beside the schema, at mode 0600 on Linux and macOS. Use it where the tool cannot take a variable.

An export sync pushes values into the platform's own store. The console writes your values into Vercel's environment, a Lambda function's variables, a Cloud Run revision or a Worker's secret bindings, and penv is absent at runtime. Use it where nothing of yours runs before your code does.

There is no fetch SDK. penv does not offer a library your app calls at boot to read a value, because that would put a network round trip in front of every cold start. The three ways above are the three ways.

How to choose

Way	Pick it when	At boot
`penv run`	You control the command that starts your process.	penv asks the server, or reads its encrypted local copy.
`penv pull`	The tool reads a file and nothing else.	Nothing. The file is already there.
Export sync	Your code is the first thing that runs, as in a function.	Nothing. The platform serves its own variable.

The trade is where the record lands. A penv run or a penv pull read is an entry in your audit log naming the credential that made it. Once a value sits in the platform's own store, reads there are the platform's business and penv sees none of them.

What a server or a container does differently

A laptop keeps an encrypted copy of an environment under a key in the operating system keychain. Most servers and every container have no keychain, so penv keeps no copy there and asks the server on every run. Build that network dependency into your health checks. See local mode and cloud mode.

Offline behavior follows from the same thing. There is no copy to fall back on, so an unreachable server means the run stops with exit code 5 rather than starting your program on yesterday's values.

One runtime read that does exist

Kubernetes has a fourth path, because External Secrets Operator already fetches from a URL. Its webhook provider calls GET /api/v1/bulk-read-secrets with a pck_ machine credential and gets the whole environment back in one response. penv ships no Kubernetes sync adapter of its own for exactly that reason. See External Secrets Operator.

Pick your host

Host	Page
Vercel	Deploy to Vercel
A container, anywhere	Docker
Kubernetes, EKS, GKE, AKS	Kubernetes
Lambda, Cloud Run, Workers, Deno Deploy	Serverless
A cluster already running External Secrets Operator	External Secrets Operator

Next: deploy to Vercel.