Back to blog
Engineering1 min read

How Deplo builds your app without a Dockerfile

Framework detection, cached layers and why the build runs on a different server from the one that serves your app.

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.

Dockerfile
# 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 build

Building 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.

Ten minutes from now,
it's live.

Answer three questions and pick a host, or install Deplo on a server you already have. It's free, and leaving is as easy as arriving. What you do with the money you save is your business.

How Deplo builds your app without a Dockerfile - Deplo