Skip to main content
You never fill in a form describing your application. Antideploy reads the code and works out what it is, what it depends on, and how to run it. This page is what happens at each stage.
1

Ingest

Your source arrives as a GitHub repository, a folder upload, or an archive pushed to the API. Dependency and build directories (node_modules, .git, dist, .next, build) are excluded; you don’t need to clean the project first.
2

Analysis

Antideploy reads your manifests and source to determine:
  • Runtime: Node, Python, Go, Ruby, Java, or a Dockerfile
  • Framework: Next.js, Vite, Express, Flask, Django, Rails, or a static site
  • Build and start commands: inferred from your scripts and conventions
  • Port: what your app will listen on
  • Database: whether your code uses Postgres, and through which ORM
Every conclusion comes with the evidence for it, so you can see why it decided something before you deploy.
Antideploy reads the names of environment variables your code expects, so it can tell you what to supply. It never reads their values.
3

Provisioning

If your code uses Postgres, a database is created and its connection string is injected as DATABASE_URL.This is the only infrastructure Antideploy provisions. If your project also needs object storage, Redis, a queue or a scheduler, analysis will say so, as a warning or a hazard, and you supply it yourself.
4

Build

Your project is built into a container image.Most projects go through buildpacks, which detect the runtime and produce an image without a Dockerfile. If there is a Dockerfile at the root of what is being built, that is used instead.
The root, specifically. A Dockerfile at services/api/Dockerfile is not used: the build runs at the root, where that file is not. If yours lives in a subdirectory, either set that directory as the one to build, or move the Dockerfile up.
Static sites skip the buildpack lifecycle entirely: there is nothing to compile, so the files are layered onto a minimal server image. This takes a static site from roughly three minutes to about seventy seconds.Build logs are captured and shown in the dashboard, including on failure.
5

Release

The image is deployed and your environment variables are injected. The previous version keeps serving until the new one passes its health check.Your app is then reachable over HTTPS at a generated URL.
6

Running

Apps scale to zero when idle, so an app nobody is using costs nothing. The first request after an idle period pays a cold start.Antideploy checks each app’s health every few minutes and emails you when an app changes state: goes down, or recovers.

​
Warnings and hazards

Analysis produces two kinds of finding, and the difference matters.

Warnings

Things that will work but may not be what you meant. A missing lockfile, a page referencing files that weren’t uploaded, two deployable projects in one repository.

Hazards

Things that will not work once deployed. Files written to local disk and lost on restart. Background workers and scheduled jobs that will never run.
Both are returned as structured data through the API, not just rendered in the dashboard, so a script or agent can read and relay them.
A deploy can succeed and still not do what its author expects. Hazards are how you find that out before your users do.