Deployments

A deployment is a single attempt to build and run a specific commit of your project. Each push to your default branch creates a new deployment, and you can also trigger one manually. See Redeploys.

# Lifecycle

Each deployment moves through three phases:

1. Initializing: Atlasflow prepares the deployment and clones your repository at the commit.
2. Building: it builds a container image from your Dockerfile or an auto-detected build plan, then pushes the image to the registry. Follow along in the build logs.
3. Deploying: it starts a microVM running your container and runs health checks until your app responds on GET /.

Once health checks pass, traffic is routed to the deployment and it becomes the active version behind your project's default hostname.

# Statuses

# Health checks and timeouts

After a successful build, Atlasflow probes your container with GET / on port 3000 every 15 seconds (5-second timeout). Three consecutive failures mark the deployment unhealthy. A deployment that doesn't become healthy within the deployment window is marked FAILED.

See Container requirements for the exact probe behavior.

# Deployment metadata

Each deployment records the branch, commit SHA, commit message, and author, along with build duration and per-phase timing. You can inspect all of this, plus build and runtime logs, in the deployment detail view.

# Preview and default hostnames

• Every deployment gets a unique preview URL so you can test it in isolation.
• Your project's default hostname always points at the latest successful deployment.

See Deploy your first project for the hostname formats.

# Next steps

• Builds: how the image is produced.
• Redeploys: trigger deployments manually.
• Build logs: watch a deployment build in real time.