How Atlasflow Works

Atlasflow is a platform for deploying containerized applications from GitHub. You connect a repository, and every push to your default branch produces a new running version of your app.

# The deployment pipeline

1. Push: you push a commit to your project's default branch. GitHub notifies Atlasflow through the GitHub App webhook.
2. Clone: Atlasflow clones your repository at the exact commit SHA.
3. Build: it builds a container image from your Dockerfile, or auto-detects your stack when no Dockerfile is present. See Builds.
4. Push image: the built image is pushed to Atlasflow's container registry.
5. Run: Atlasflow starts a microVM running your container with your project's runtime environment variables.
6. Health check: it probes GET / on port 3000 until your app responds with a 2xx status.
7. Route: once healthy, the edge proxy routes traffic to your container.

# Where your code runs

Atlasflow runs each container inside a lightweight virtual machine (a microVM) on its own bare-metal infrastructure. MicroVMs give you stronger isolation than shared containers while still starting quickly. Your container is the only workload inside its VM.

Because every workload is isolated, you don't share a runtime with other tenants, and there are no cold starts from a shared pool.

# Routing and the edge

Atlasflow's edge proxy terminates TLS and forwards incoming HTTP and HTTPS traffic to port 3000 on your container. It maps each hostname (preview URLs, your project's default hostname, and any custom domains) to the correct deployment.

This is why your application must listen on port 3000 and bind to 0.0.0.0.

# What you manage vs what Atlasflow manages

# Next steps

• Projects: how a repository becomes a deployable project.
• Deployments: the lifecycle of a single deploy.
• Deploy your first project: try it end to end.