Builds
How Appentic builds a web service from your repository.
Every deploy builds your web service from a commit on its branch. Appentic uses the repository's own Dockerfile if it has one, and otherwise builds for the runtime you chose.
Your own Dockerfile
If the repository has a file named Dockerfile at its root, Appentic builds with it as it is, whatever the runtime setting. The create form shows Dockerfile detected and sets the runtime to Docker.
The image starts with your Dockerfile's own CMD or ENTRYPOINT. The Build command and Start command settings aren't used.
Use a Dockerfile when you need:
- a language or version the built-in runtimes don't cover
- operating system packages installed with
apt,apkor similar - build steps of your own
Built-in runtimes
Without a Dockerfile, Appentic builds from the Runtime setting. When you pick a repository, Appentic suggests a runtime from the repository's main language on GitHub. You can change it on the create form, or later in Settings → Build & Deploy.
| Runtime | Base | What the build does | Start command filled in |
|---|---|---|---|
| Python | Python 3.12 | Installs gunicorn and your requirements.txt | gunicorn --bind 0.0.0.0:8080 app:app |
| Node.js | Node.js 22 | Runs npm ci, then npm run build | npm start |
| Bun | Bun 1 | Runs bun install --frozen-lockfile, then bun run build | bun start |
| Go | Go 1.23 | Runs go build -o server . | ./server |
| Ruby | Ruby 3.3 | Runs bundle install without the development and test groups | bundle exec rails server -b 0.0.0.0 -p 8080 |
| Rust | Rust 1.82 | Runs cargo build --release | ./server |
Each runtime's build steps are fixed, and the Build command field doesn't change them, with one exception: for Python, set it to pip install . to install from pyproject.toml instead of requirements.txt. To run build steps of your own, add a Dockerfile.
- Node.js needs a
package-lock.json, becausenpm ciuses it. A project that uses Yarn or pnpm needs a Dockerfile. - Bun needs a lockfile,
bun.lockorbun.lockb. - For both, the
buildscript runs ifpackage.jsonhas one. If it fails, the build stops and its output shows why. - Rust starts the program your crate builds. If it isn't called
server, set the start command to./and its name, for example./my-api.
JavaScript and TypeScript repositories are suggested as Node.js; to use Bun, choose it yourself. For any other language, add a Dockerfile: without one, the runtime shows Docker and the build fails with a message saying so.
Your app's port
Appentic sends your service's traffic to the port in the PORT environment variable, which is always 8080.
- Python and Ruby: the start commands Appentic fills in already use it.
- Node.js, Bun, Go, Rust and your own Dockerfile: your app picks its port, so have it listen on
PORT. Many frameworks do this already. If yours uses a fixed port such as3000, change it to readPORT.
Listen on 0.0.0.0, not localhost or 127.0.0.1. An app listening only on localhost can't be reached, and its deploy never goes live.
Start command
The Start command is what runs when the service starts. A change to it takes effect on the next deploy. It must start your app on its port.
The start command runs directly, not through a shell, so shell features such as &&, pipes and $VARIABLE expansion don't work on their own. If you need them, wrap the command:
sh -c "python manage.py migrate && gunicorn --bind 0.0.0.0:8080 app.wsgi"For database migrations, a release command is a better fit than the start command, because it runs once per deploy and stops a deploy that fails.
Build cache
Builds reuse cached layers from earlier builds, so a deploy where only your code changed is faster than the first one. To build from scratch, open the service's Settings, open the menu next to Save only under Build & Deploy, and choose Clear build cache & deploy.
Where builds run
Builds run on the web service's machine. A build reserves only a little memory and borrows what the machine has idle, along with its free CPU. A build can run for up to 25 minutes.
If the machine has too little free memory, the build can't start and the deploy fails with a message saying so. See Memory and sizing.
Build output
The service's Logs page shows the build's output while it runs, then switches to your app's output once the new version starts.
When a build fails, the Events page shows Deploy failed with the reason, and the version that was already live keeps running.
Change build settings
Changes to Runtime, Branch, Build command, Start command and Guaranteed memory take effect on the next deploy. Under Build & Deploy, click Save only to save them, or open the menu next to it and choose Save & Deploy.