This page covers what Eden does with your secrets, what is public once you deploy, what Eden can touch in your Cloudflare account, and where the sandbox stops protecting you. For the overall design see How Eden works.

Runtime values such as model keys and auth secrets go in an env file you pass with --env-file. Keep it outside the project and outside source control, readable only by you:

chmod 600 ~/.config/my-agent/preview.env

How Eden handles it:

• Validated before anything else. The file must be a regular file (no symbolic links), UTF-8 KEY=VALUE records, and must not set names Eden reserves for the host, such as HOST, PORT, NITRO_*, NODE_ENV, NODE_EXTRA_CA_CERTS, or Eden's own identity variables. Eden checks that the file does not change while the deploy runs. See the reference for the exact rules.
• Never in the image. Eden copies your project into the builder without your env file, without any .env* file, and without credential files (.npmrc, .pnpmrc, .pypirc, .yarnrc, .yarnrc.yml, .bunfig.toml, credentials.json, service-account.json, *.pem, *.key). If the install or eve build output still contains one of those files, or a symbolic link that points outside the project, the deploy stops with SECRET_EXCLUSION_FAILED.
• Not from your shell. Eden runs Docker with a minimal environment (PATH, HOME, TMPDIR, locale, and Docker settings) and starts the local boot check with a private environment, so unrelated credentials in your terminal do not reach the build.
• Uploaded as Worker secrets. Each value is uploaded with wrangler secret put, passing the value on standard input rather than as a command argument. Values are not written to command arguments, image layers, generated artifacts, or normal logs.
• Given to the container at start. When the Durable Object starts the container, it reads those secrets and passes them in as environment variables. Only the names from the current deploy's env file are passed, so use the same --env-file on every deploy.
• destroy takes no env file. Cleanup never needs your secrets.

Your agent gets a public https://<name>.<subdomain>.workers.dev URL. Anyone who finds it can send requests, so your Eve authenticator is what protects the agent. The authenticators that eve init generates for Vercel and localhost do not grant access on Cloudflare; replace the placeholder in agent/channels/eve.ts with a real Eve authenticator before you deploy.

What the Worker does for you:

• Returns 404 for Eve's internal workflow queue routes (/.well-known/workflow/v1/flow and /step) and for /__eden/world/*. Eve's own queue deliveries reach the container through an internal path instead, so the public routes are never needed.
• Still forwards token-bearing webhook/<token> routes and manifest.json, which Eve protects itself.
• Removes headers a client could spoof: forwarded, x-real-ip, true-client-ip, x-original-host, x-proxy-host and similar, plus every incoming x-forwarded-*, x-eden-*, and cf-* header. It then sets its own host, forwarded, and x-forwarded-host/-port/-proto, so Eve sees the real public origin.
• Adds x-eden-eve-* response headers with the Worker name, public origin, deployment and generation IDs, and container instance name. They identify the deployment; they contain no secrets.

Eden agents use Eve's just-bash sandbox: a simulated shell that runs inside Eve's own process, not a separate Linux VM like Vercel Sandbox. Treat it as a convenience for file and text work, not as an isolation boundary between the agent's commands and the rest of the container.

• The sandbox and the container have unrestricted outbound internet access. Eve offers no setting to restrict just-bash networking (eve#2927).
• Be careful with tools and skills that let untrusted users steer the agent's shell or network calls.

Eden acts through your Wrangler login (npx wrangler@4.147.0 whoami) and never switches accounts silently. For each target it creates one Worker, one Container application, its Durable Objects, registry images, and, only when your project has schedules, one Cron Trigger. The exact names are listed in the reference.

• Exact ownership. Eden writes a deployment record under .eden/eve-deploy/ in your project. A deploy only updates a target that record proves Eden created; anything else fails with VAL-CLI-007-TARGET-CONFLICT instead of being overwritten.
• Exact cleanup. destroy checks the live Worker and Container application against that record, deletes only those and the registry images the records prove Eden pushed, then verifies they are gone. It never deletes by name prefix or by searching your account. If Eden cannot prove a result, it reports it as indeterminate and keeps its evidence rather than guessing.
• Production is explicit. --env production and destroy always require --name.

Nothing in your project. Inside the throwaway build container only, Eden applies a small temporary fix to Eve's just-bash binding for eve#4440, and only when the file matches a checksum Eden recognizes. On any other Eve version the file is left alone and the deploy prints an EVE_SANDBOX_RESUME_PATCH warning.

@moinulmoin/eden and its companion packages are published to npm from GitHub Actions with npm provenance, so you can check that a release was built from this repository:

npm view @moinulmoin/eden dist.attestations

Open an issue at https://github.com/moinulmoin/eden/issues. Never paste env-file values, tokens, or full --json output that might contain them.

Return to the documentation index.