Antideploy

The relay's log for this application, newest first: when, how many addresses, whether it was handed to Resend or turned away, and what Resend reported afterwards (delivered, bounced, complained, delayed, failed, suppressed) with a reason. Use it to answer "did my email go out" and "why did that one not arrive". It never has a subject, a body or an address, because none is kept. `outcome` is null until Resend has reported, and always while `reporting` is false. Page with `before` set to the `next` of the last answer.

Let this application send email now, while the project is still being written, so a welcome or a password reset is built and tested against the real thing instead of being left out or sending the user to open a Resend account and verify a domain. There is nothing to sign up for. Safe to call twice. Only for a project that sends mail: skip it otherwise, and skip it when the project already sets a RESEND_API_KEY of its own (409 own_email). A 503 email_unavailable means email is not set up on this server: carry on without it and tell the user. If the call is refused or blocked, do not look for an…

The last 7 days of this application's mail: delivered, bounced and reported as spam, whether it is healthy or one to watch, the recent problems with the reason Resend gave, and the rules the platform uses to stop an application's email by itself (at least three addresses bouncing that are a fifth of a day's mail, or two spam reports in a week). While `reporting` is false the counts are zero because Resend's reports are not connected: that means unknown, not healthy.

The platform's sending domain, this application's own address under it, and the From value. Sending from the user's own domain is not offered, so never send the user to add DNS records for email.

Write RESEND_API_KEY, RESEND_BASE_URL, RESEND_API_URL and EMAIL_FROM into a .env file in the project directory, and return only the names of what was written. RESEND_API_KEY here is a token for the platform's relay, not a Resend key, and it goes into the file and never into this conversation, so do not read the file back out to the user. These are the same variables the deployed app receives, so do not copy them into `set_env`. Variables already in the file are replaced, everything else is kept, and the file is added to .gitignore. Email has to be set up first: `email_create` does it. Needs th…

Every application on the account and where its email stands (state, who paused it, what it sent in the last day against its allowance, how its mail is landing), and which have none. Uses the account token when this machine has one; with only a project key it shows this application alone.

Stop this application's email at once, for a leaked token or a loop in the code. Its token is refused (403 suspended_api_key) until `email_resume`. The application itself keeps running. Needs the account token that `login` (or https://antideploy.com/agent.md) saves: a project key cannot do it. Tell the user it is paused.

Take email away from this application. Its token is refused from then on, and the running app keeps the variables it was given, so its mail fails until `email_create` sets it up again. Only when the user asked for it. Refused with 409 while the platform has it paused. Needs the account token.

Start this application's email again after `email_pause`. A pause the platform made because the mail was bouncing or reported as spam answers 409 paused_for_deliverability and is not lifted from here: tell the user, who replies to the notice they were emailed. Do not remove email and set it up again to get round it. Needs the account token.

Whether this application can send email, from which address, its allowance and what it has sent in the last 24 hours, who stopped it if it is stopped (pausedBy, pausedReason), the last 14 days, when it last sent and how its mail is landing (`health`). Read it before telling the user whether email works. Never returns the token.

Send one real message to the address of the account that owns this application, through the relay exactly as the application's code would, so the user can see that email works. The recipient is always the account's own address. It counts as one address against the day. Needs the account token.

Last observed state (healthy, degraded, down or unknown) and when it was checked. A sweep every five minutes, not a probe taken now: compare `checkedAt` with your deploy.

Record an application the user already has in .antideploy.json for this folder, so deploys and the other tools act on it. Take the id from `list_applications`. Only when the user said which one; never guess, because deploying a project over another application replaces what is live there.

Every application on the account (or the one this server's key belongs to), with its id, name and address, and which account this is. Use it to pick an id for `link_application`.

Names only. The platform never returns values, by design.

The application's scheduled jobs, each with its next and last run, last status and error, plus the rules: UTC, a few jobs per application, runs at least five minutes apart.

Connect this machine to the user's Antideploy account. First call: returns a link and a short code; show both to the user, who opens the link, checks the code matches and clicks Approve (that is the only thing they do; if they have no account the same link creates one). Then call `login` again: it waits for the approval, saves the login in ~/.antideploy and tells you which account was connected, which you must tell the user. Later calls just confirm the connection. The login can be revoked any time at https://antideploy.com/tokens. If the user declines, stop and do not start another unless the…

Delete the account token saved on this machine, only when the user asked to sign out. It does not revoke the token on the server; for that the user opens https://antideploy.com/tokens. A project key in ANTIDEPLOY_API_KEY is not affected.

What the running container has printed, newest last.

Requests, server errors and their rate, p50 and p95 response times, and requests per day. Check it when the user says the site is slow or failing: logs show what happened, this shows how often. Requests include bots and every asset on a page, so they are not visitors.

Build and release the application again without uploading it. By default that is the version last sent, with the current environment variables: this is how a changed variable or a new AI key reaches the running app. For an application built from GitHub, `latest` deploys the newest commit on its default branch instead. Returns a taskId to poll with `deployment_status`.

Remove one variable. The running app keeps it until the next deploy; `redeploy` applies it. A removed value cannot be shown again, only set again.

To change a job's schedule or path, remove it and add it again.

For a value that is not in the project, such as a Stripe secret key, a bot token or an AI provider's key: get a link where the user pastes it on an Antideploy page, so it goes straight into the application's encrypted variables and never passes through this conversation. Show the user the `url`, say where they find the value in that provider's dashboard, then poll `list_env` until every name appears, and `redeploy`. Never ask the user to paste a key into the chat. Do not ask for what the platform fills in itself (the database, storage, sign-in and email variables, the application's own address…

Put back the last version that went live before the one serving now, or a specific deployment from `deployment_history`. It is built again from its source, so it takes as long as a deploy; poll `deployment_status` with the returned taskId.

Start a scan of the running application: keys shipped to the browser, endpoints open without a login, SQL injection, downloadable config files, open CORS and missing headers. Takes seconds. Poll `security_scan_status` with the returned scanId.

Status and findings, each with a severity, a plain explanation and a `recommendation`. Poll until completed or failed. Fix each finding at its root, then scan again.

Store or replace environment variables for this application. Write-only. Do not pass DATABASE_URL, PG*, storage, sign-in or email variables: the platform sets those itself. To take values from a local .env without them passing through this conversation, use `set_env_from_file`.

Read the named variables out of a .env file in the project directory and store them for the application, so the values go from the file to Antideploy and never through this conversation. Only the names you list are sent. Names the platform fills in itself (the database, storage, sign-in and email variables, the application's own address and generated signing secrets) are refused with the reason, and so are empty values and template placeholders like your-key-here. The result names what was stored and what was skipped, never a value. Redeploy afterwards for the running app to pick them up.

Resuming also resets the job's failure count, which pauses it after ten in a row.

Create a private S3 bucket for this application now, while the project is still being written, so uploads are built and tested against real storage instead of the container's disk, which is wiped on every deploy. A later deploy gives the running app the same bucket. Safe to call twice. Only for a project that stores uploads or generated files: skip it otherwise, and skip it when the project already has a storage key of its own (an AWS_ACCESS_KEY_ID in .env that is not ours, or a service the user named, such as Cloudinary or UploadThing): the answer is a 409 own_storage. It counts against the p…

Write the bucket's name, endpoint, region and access key (AWS_S3_BUCKET, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_ENDPOINT_URL_S3, AWS_REGION and the spellings other S3 libraries read) into a .env file in the project directory, and return only the names of what was written. The key goes into the file and never into this conversation, so do not read the file back out to the user. These are the same variables the deployed app receives, so do not copy them into `set_env`. Variables already in the file are replaced, everything else is kept, and the file is added to .gitignore. The bucket has …

Change any of: the address (`subdomain`, which stops the old one working at once; ask the user first and show them the full URL), whether a push to a GitHub repository deploys by itself (`deployOnPush`), and which directory holds the application inside the project (`rootDirectory`, null for the whole project). Changing the directory analyzes the project again and reports what it found; the running app changes on the next deploy.