Every deploy tool has to answer the same question first: given a repo, how does it turn into a running container? There are three real answers, and DeployOS supports all three deliberately, defaulting to the one that needs the least from you.
Dockerfile — full control, full responsibility
You write a Dockerfile, the tool builds it. Total control over the base image, build steps, and runtime — and total responsibility for keeping it correct, secure, and fast. This is the right choice when your app has unusual build requirements a generic builder can't guess.
Classic buildpacks — the Heroku approach
Buildpacks (Heroku's, or Cloud Native Buildpacks) detect your language/framework and assemble an image without a Dockerfile. They work, but they're old infrastructure — slow builds, large images, and a detection/build model that hasn't changed much in over a decade.
Railpack — the modern answer
Railpack is a newer, from-scratch buildpack implementation built for speed: faster builds, smaller images, better caching, and detection logic that covers modern frameworks (Next.js, Bun, Deno, and the usual Node/Python/Go/PHP/Ruby lineup) without configuration. No Dockerfile, no buildpack config file — point it at a repo and it produces a production image.
Why DeployOS defaults to Railpack
Most apps don't need a hand-tuned Dockerfile — they need "clone this repo, detect the framework, build something that runs." That's exactly Railpack's job, and defaulting to it means a DeployOS user can deploy a fresh Next.js or Python app with zero Docker knowledge. DeployOS's build pipeline runs Railpack through a dedicated BuildKit container on your server, so builds are isolated and repeatable regardless of what else is running.
When to reach for the other options
If your app has a genuinely unusual build (multi-stage native compilation, an unusual base image requirement, a monorepo build graph Railpack's detection doesn't handle well), DeployOS also supports Dockerfile builds directly, and raw Compose for anything even more custom. The point isn't "Railpack always" — it's "Railpack by default, so the common case needs zero configuration, with an escape hatch for the uncommon case."
This is also why the "no Dockerfile needed" claim on DeployOS's homepage is literal, not marketing shorthand — it's Railpack doing real detection and build work, the same category of tool Heroku popularized, just faster and newer.