Build settings
How your source becomes a container image, which builder runs and which port it listens on.
What it is
How your source becomes a container image: which builder runs, what commands it runs, and which port the result listens on. Everything here lives in Settings -> Deployments, and most apps never need to touch it.
How it works
For a source Deplo builds, it re-derives the framework from package.json and the root configuration on every deploy. Detection is never stored, so upgrading your framework changes the build without you editing anything.
Anything you type by hand is stored, and it wins from then on. The fields sit empty and show the detected value as a placeholder, which is how you can always tell "detected" from "set by me". Clearing a field hands it back to detection.
The four build methods
Pick one under Build method.
| Method | Use it when | Fields it adds |
|---|---|---|
| Nixpacks (default) | Normal application code, any common language | none |
| Railpack | The same job, different builder. Try it if Nixpacks mis-detects | Builder version |
| Dockerfile | You already have a Dockerfile and want it used exactly | Dockerfile path, Build context path, Build stage (target) |
| Static | The build produces plain files to serve | Publish directory, Single-page application |
Single-page application makes unmatched paths fall back to index.html, which is what a client-side router needs.
Dockerfile and Static skip framework detection entirely. You have already said what happens.
The fields everyone eventually uses
Prop
Type
Click Save build settings. Saving does not deploy: click Redeploy when you want the change to take effect.
The port is the one people get wrong
Deplo routes traffic to exactly one port per app, and detection sets a sensible default per framework (Vite 4173, Angular 4200, and so on). If the container starts fine and the URL times out, this is nearly always why.
Your process must also listen on 0.0.0.0, not 127.0.0.1. A server bound to localhost inside a container is unreachable from outside it.
A single hostname can override the port for itself, which is how one app can serve an API on one domain and a dashboard on another. That override lives in Domains, not here.
Build cache
Under Advanced settings, Build cache is on by default. The cache lives on the server, one BuildKit cache shared by every app on that host, which is why a first build is slow and later ones are not.
Two controls:
- The switch turns caching off for this app only.
- Clear build cache arms a one-shot clear, applied on the next build.
Pruning the cache on disk is not this switch's job. That is disk cleanup on the server.
Advanced settings you probably do not need
Prop
Type
Limits and gotchas
- Saving is not deploying. Nothing changes on the server until the next build.
- Detection cannot help a Docker image or a Compose source. There is nothing to detect. You name the port yourself.
- A heavy builder that the agent cannot run is a hard failure. There is no fallback to building somewhere else.
- Changing the build method keeps everything else. Domains, variables and volumes are untouched.
If it does not work
command not foundduring build - the detected framework guessed wrong, or the command belongs to a dependency that is not installed. Set Build command explicitly.- The build passes, the site does not answer - wrong Container port, or the process is bound to
127.0.0.1. - The build is slow every single time - the cache is off for this app, or a cleanup sweep is removing it. Check Build cache and the server's cleanup scopes.
More in Deploys and builds.
See also
Did this page help you?