---
title: Supported Frameworks
description: How Atlasflow builds your app, with or without a Dockerfile.
order: 4
---

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](/docs/guides/configuration.md), 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](/docs/guides/container-requirements.md) and respond to `GET /`.

## Automatic builds (no Dockerfile)

If no Dockerfile is present, Atlasflow auto-detects your stack and builds it using [Railpack](https://railpack.com), 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:

| Ecosystem                            | Detected from                        |
| ------------------------------------ | ------------------------------------ |
| Node.js (including Next.js and Nuxt) | `package.json`                       |
| PHP (including Laravel)              | `composer.json`                      |
| Python                               | `requirements.txt`, `pyproject.toml` |
| Go                                   | `go.mod`                             |
| Ruby                                 | `Gemfile`                            |

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.

> **Note:** 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 when             | Use automatic builds when              |
| --------------------------------- | -------------------------------------- |
| You need specific system packages | You want the fastest path to a deploy  |
| You have a custom start command   | Your app uses a conventional stack     |
| You want full reproducibility     | You'd rather not maintain build config |

## Next steps

- [Container requirements](/docs/guides/container-requirements.md): port and health check rules.
- [Builds](/docs/concepts/builds.md): how the build pipeline works.
- [Monorepos](/docs/guides/monorepos.md): build a subdirectory of a larger repo.