Most apps never need a Dockerfile. This post walks through what Deplo does instead, and where a Dockerfile still wins.
Detecting the framework
The build starts by reading the repository: the lockfile tells the package manager, the dependencies tell the framework, and the framework tells the build and start commands. A Next.js app, a Vite site and a Go service all take a different path from the same first step.
Layers that survive the next build
Dependencies change far less often than code. Deplo installs them in their own layer, keyed on the lockfile, so a commit that only touches a component skips the install entirely.
# Roughly what the generated build looks like for a Node app
FROM node:22-slim AS deps
COPY package.json bun.lock ./
RUN bun install --frozen-lockfile
FROM deps AS build
COPY . .
RUN bun run buildBuilding away from production
Builds are heavy. When a team adds a build server, Deplo runs every build there and ships only the finished image to the server that serves the app, so a build never slows down the site it is replacing.
When to write your own Dockerfile
- The app needs system packages the detection cannot guess.
- You already have a Dockerfile you trust.
- The build has steps that are not part of any framework.
If a Dockerfile is in the repository, Deplo uses it and skips the detection.


