Builds

During a deployment, Atlasflow builds a container image from your code. There are two build paths, chosen automatically based on whether your project has a Dockerfile.

# Dockerfile builds

If a Dockerfile exists at your project's configured Dockerfile path (relative to the root directory), Atlasflow builds it directly. This gives you full control over the runtime, system packages, and build steps.

A Dockerfile build must produce an image that:

• listens on port 3000, bound to 0.0.0.0
• responds to GET / with a 2xx status

See Container requirements for a complete example.

# Automatic builds

If no Dockerfile is found, Atlasflow auto-detects your stack and generates a build plan using Railpack, an open-source build tool. You don't need to write any build configuration: Atlasflow analyzes your repository, installs dependencies, and produces a runnable image.

See Supported frameworks for the ecosystems this covers.

# Build environment

Builds run on a dedicated build machine, isolated from your running application. You can control how much CPU and memory each build gets with build machine tiers.

Build environment variables are available during this step (for example, a private package registry token). They're separate from runtime variables. See Environment variables.

# Build caching

Builds reuse layer caching where possible to speed up repeat builds of the same project. Structuring your Dockerfile so that dependency installation happens before copying application source helps caching work effectively.

# After the build

The built image is pushed to Atlasflow's container registry and then started on a microVM. Watch the whole process in the build logs.

# Next steps

• Supported frameworks: what auto-detection handles.
• Build machines: CPU and memory for builds.
• Container requirements: what your image must do.