PlatformEnvironment variables

Secrets that stay secret.

Q: Which variables does Antideploy set for me?

DATABASE_URL and the PG* variables when you have a database, the AWS_* variables for a bucket, the sign-in and email variables when you switch those on, your app's own address, and signing secrets such as SESSION_SECRET if your code reads them.

Your app's keys go into an encrypted store and are write-only from then on, even for your coding agent. Antideploy fills in the values it can, such as DATABASE_URL, your app's own address and its signing secrets, so you only supply what is really yours.

Read the docs

An encrypted storeValues are encrypted from the moment they are saved
Write-onlyNever shown again, even to your coding agent
Platform values filled inDATABASE_URL, your app's address and its signing secrets
A history of changesEvery add, change and removal is recorded, names only

01How it works

Write them. Never read them back.

An agent needs to push the values out of your project's .env. It never needs to read them again, so it cannot.

One call to set them. Names back, never values.

Your agent pushes the project's environment in one call, and the answer lists only the names that landed. Values are never returned, so a leaked project key cannot be used to read the credentials it wrote, and a hostile README cannot talk an agent into fetching secrets it could then repeat.

Blank values, placeholders and PORT are ignored
The running app keeps its old values until the next deploy
A redeploy applies a change without sending the code again

See redeploys

Your agent runs

$ API=https://antideploy.com/api/v1

# set or change variables (values are never returned)
$ curl -X PUT "$API/secrets?applicationId=$APP_ID" \
    -H "Authorization: Bearer $TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"env":{"STRIPE_SECRET_KEY":"your-value"}}'

# which names are set, never their values
$ curl "$API/secrets?applicationId=$APP_ID" \
    -H "Authorization: Bearer $TOKEN"

PUT /api/v1/secretsGET /api/v1/secretsDELETE /api/v1/secrets?key=NAME

The ones that are not yours to supply.

On every deploy, Antideploy sets the variables that are your app's own web address, and generates the plain signing secrets your code reads. You do not ask for them and your agent does not push them. A value you set yourself always wins.

Your app's live address, set on every deploy, build included
Signing secrets are different for every app and the same on every deploy
While you build locally, use your own values

Variables for services you switch on

Set for you

APP_URL  SITE_URL  NEXTAUTH_URL
NEXT_PUBLIC_APP_URL  NEXT_PUBLIC_SITE_URL
    your app's own live address, plus the matching VITE_ pair

JWT_SECRET  SESSION_SECRET  SECRET_KEY
AUTH_SECRET  NEXTAUTH_SECRET
    generated if your code reads them

02What you get

Safe by default, convenient anyway.

The point of a secrets store is that nobody, including a tool working for you, can be tricked into handing a value over.

An encrypted store. Your values are encrypted before they are saved. What the console shows is which variables are set, never what is in them.
Write-only, even for your agent. Your agent can set a variable and list the names that exist. It cannot read a value back, so a leaked key cannot be used to read the credentials it wrote.
Your .env, uploaded on purpose. A .env in your project is read when you deploy, so you do not retype keys you already have. The values go into the encrypted store and the file itself is dropped from the build. Move the file first if that is not what you want.
Platform values, filled in. DATABASE_URL, the variables for a bucket, sign-in or email you switched on, your app's own address and its signing secrets are all set for you. See the database, file storage, authentication and email.
Names, never values, when it reads your code. The analysis reads which variables your code expects, never what is in them, and tells you which are not set yet, so a missing key is found before the deploy and not after.
A history of every change. The console records each variable added, changed or removed, and a deploy's what-changed list shows them too. Names only, never values.

03Reference

What the platform sets for you.

Do not copy these into the secrets store. The platform sets them in the running app itself, and a copy could shadow the real ones.

Variables	When you get them
`DATABASE_URL` and `PG*`	When your app has a Postgres database. A value you set yourself wins.
`AWS_`, `BUCKET_NAME`, `S3_`	When your app has a file storage bucket.
`NEON_AUTH_*`, `VITE_NEON_AUTH_URL`	When sign-in is switched on.
`RESEND_API_KEY`, `RESEND_BASE_URL`, `RESEND_API_URL`, `EMAIL_FROM`	When email is switched on.
`OPENROUTER_API_KEY`	When you create an AI key for the app. It is saved into the app's environment for you.
`APP_URL`, `SITE_URL`, `NEXT_PUBLIC_APP_URL`, `NEXT_PUBLIC_SITE_URL`, `NEXTAUTH_URL` and the matching `VITE_` pair	Always. Set to your app's own live address on every deploy, build included.
`JWT_SECRET`, `SESSION_SECRET`, `SECRET_KEY`, `AUTH_SECRET`, `NEXTAUTH_SECRET` and similar	If your code reads them. Generated, different for every app, and the same on every deploy.

04The API

Four calls, all an agent needs.

Call	What it does
`PUT /api/v1/secrets`	Set or change variables with `{"env": {"KEY": "value"}}`. The answer lists names only.
`GET /api/v1/secrets`	List the names that are set. Never values.
`DELETE /api/v1/secrets?key=NAME`	Remove one variable. The running app keeps it until the next deploy.
`POST /api/v1/redeploy`	Apply a change without sending the code again.

05Before you commit

Here's where it stops.

A platform that only tells you what it is good at is one you find the edges of in production. These are the secrets store's.

Values cannot be read back
That is the design. If you lose a value, set it again. Your agent cannot recover it for you.
Changes need a redeploy
The running app keeps its old values until the next deploy. A redeploy applies a change without sending the code again.
Platform variables cannot be removed
The ones Antideploy supplies, such as a provisioned database's, are not stored here. To use your own, set the variable yourself and it wins.
Build-time variables are baked in
A value a front end reads while it builds, such as a NEXT_PUBLIC_ variable, is substituted into the build output. Set it before the build, because setting it afterwards cannot repair one that already ran without it.

06Questions

Variable questions, answered.

Anything else? Write to us and a person answers.

support@antideploy.com

Can I see a value after I save it?

No. Values are write-only. The console shows which variables are set and when they changed, never what is in them. If you lose a value, set it again.

Can my coding agent read my secrets?

No. It can set variables and list their names, and nothing else. It cannot read a value back, so a leaked key cannot be used to read the credentials it wrote.

What happens to my .env file when I deploy?

It is uploaded on purpose, so you do not retype keys you already have. The values go into the encrypted store, the file itself is dropped from the build, and values are write-only after that. Move the file first if that is not what you want.

How do I apply a changed variable?

Redeploy. A redeploy builds the version last sent again with the current variables, without the code being sent again.

Which variables does Antideploy set for me?

DATABASE_URL and the PG* variables when you have a database, the AWS_* variables for a bucket, the sign-in and email variables when you switch those on, your app's own address, and signing secrets such as SESSION_SECRET if your code reads them.

Do I need to set DATABASE_URL myself?

No. If your project needs Postgres, the platform sets it. A DATABASE_URL you set yourself wins, so a project pointed at Supabase or your own Neon project keeps working.

What are NEXT_PUBLIC_ and VITE_ variables?

Public variables that a front end reads at build time. They are substituted into the build output, so they must be set before the build. They are visible to anyone who loads your site, so never put a secret in one.

Can I remove a variable?

Yes, one at a time. The running app keeps it until the next deploy. Variables the platform supplies cannot be removed.

Is there a history of changes?

Yes. The console records each variable added, changed or removed, and a deploy lists the changes since the last version that went live. Names only, never values.

+The rest of the platform

Everything else your app can use.

Every service is created by your coding agent, wired into your app, and included in the plans. See the whole platform.

Facts on this page were checked against the live platform on 5 October 2026.

Keep your keys safe. Start in one sentence.

Paste the sentence into your agent. It moves your keys into the encrypted store and never prints them.

Start from GitHub or a folder

Secrets that stay secret.

One call to set them. Names back, never values.

The ones that are not yours to supply.

Values cannot be read back

Changes need a redeploy

Platform variables cannot be removed

Build-time variables are baked in

Keep your keys safe. Start in one sentence.