> ## Documentation Index
> Fetch the complete documentation index at: https://antideploy.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# How Antideploy Analyzes Your Code and Deploys It
> What happens between handing Antideploy your project and getting a live URL: analysis, provisioning, build, and release.
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.
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.
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.
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.
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.
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.
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.
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.
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.