Supported Frameworks

Supported Frameworks

View as Markdown

How Atlasflow builds your app, with or without a Dockerfile.

Atlasflow can deploy almost any web application. There are two ways your code becomes a runnable image, and the right one is chosen automatically.

Dockerfile (any language)

If your repository has a Dockerfile at the configured Dockerfile path, Atlasflow builds it directly. This works for any language or framework that can run in a container, and gives you full control over the build.

Your image must listen on port 3000 and respond to GET /.

Automatic builds (no Dockerfile)

If no Dockerfile is present, Atlasflow auto-detects your stack and builds it using Railpack, an open-source build tool. You don't write any build configuration: Railpack inspects your repository, installs dependencies, and produces an image.

Railpack detects common ecosystems from the files in your repository, for example:

EcosystemDetected from
Node.js (including Next.js and Nuxt)package.json
PHP (including Laravel)composer.json
Pythonrequirements.txt, pyproject.toml
Gogo.mod
RubyGemfile

Auto-detected apps should still listen on port 3000 and respond on /. Most framework defaults work out of the box; set PORT=3000 and bind to 0.0.0.0 if your framework defaults to a different port.

When you need precise control over the runtime, system packages, or the start command, add a Dockerfile. Atlasflow always prefers a Dockerfile over automatic detection.

Choosing between them

Use a Dockerfile whenUse automatic builds when
You need specific system packagesYou want the fastest path to a deploy
You have a custom start commandYour app uses a conventional stack
You want full reproducibilityYou'd rather not maintain build config

Next steps