Build configuration

Appentic auto-detects most popular frameworks and runtimes, so for the common case there's nothing to configure. When auto-detection isn't enough (because you use a non-standard start command, need system packages, or want a custom base image) you can override it from the service's Settings → Build tab.

Build command

The build command is whatever you'd run on a fresh checkout to get a deployable artifact. It runs once per deploy, with the repo cloned at the pushed commit and the chosen environment variables injected. Typical examples:

# Node.js
npm ci && npm run build

# Python with uv
uv sync && uv run python manage.py collectstatic --noinput

# Go
go build -o app ./cmd/server

# Rust with cargo
cargo build --release

If your build command exits with a non-zero status, the deploy is marked failed and the previous revision keeps serving traffic. The failing command's output is visible in the build log.

Start command

The start command is the process that boots your service and keeps running. For a web service, this is the process that must bind to 0.0.0.0:$PORT.

# Node.js
node dist/server.js

# Python with gunicorn
gunicorn -b 0.0.0.0:$PORT app:wsgi

# Go
./app

# Rust
./target/release/app

Appentic runs the start command as PID 1 inside the container. If it exits, the container is restarted.

Dockerfile

If your build needs system packages, a specific base image, or multi-stage caching that the defaults don't cover, commit a Dockerfile at the root of your repo. Appentic detects it automatically and uses it instead of the auto-detected build pipeline, which gives you full control while still plugging into the same deploy, logging, and metrics pipeline.

This is also the cleanest escape hatch when you want reproducible builds identical to local: the same docker build you run locally is what Appentic runs.

Caching

Appentic caches build layers between deploys, so repeat builds are fast. For most stacks this means dependency installation is skipped on deploys that don't change package-lock.json, uv.lock, go.sum, Cargo.lock, or equivalent.

If you need to force a clean build (for example, after a dependency change the cache didn't invalidate correctly) use Deploy → Clear cache and rebuild from the dashboard. This is a one-off operation: the cache starts fresh but subsequent deploys will populate it again.