Docs

Build Strategies

Two ways to turn source code into container images. Pick the one that fits how you work.

Pick your path

Dockerfile

Build from your own Dockerfile or Dockerfile.ancla. Full control over every layer. Multi-stage builds, custom system packages, whatever you need.

Default

Buildpack

Automatic detection via Cloud Native Buildpacks. No Dockerfile needed. Push code, get an image. Good for standard apps that don't need custom build steps.

Zero-config

Dockerfile

The default strategy. Ancla looks for Dockerfile.ancla first, then falls back to Dockerfile. Builds run via BuildKit with layer caching.

For Python projects, the CLI can scaffold a Dockerfile automatically during deploy. It detects your framework (Litestar, FastAPI, Flask, Django) and package manager (uv or pip).

scaffold
❯ ancla deploy
No Dockerfile.ancla found.
Detected: litestar (pyproject.toml, uv)
Generate Dockerfile.ancla? [Y/n]

Buildpack

Cloud Native Buildpacks auto-detect your language and produce an image without a Dockerfile. Registry-based caching is used automatically. Build-time variables are passed as --env flags.

Process types are auto-detected from the built image. For CNB builds, Ancla reads process metadata embedded by the buildpack. For Dockerfile builds, it falls back to the image's CMD / ENTRYPOINT. You can also set process types manually on the service.

Switching strategies

Change it any time. No migration, no downtime.

  1. 1 Go to the service's Settings tab
  2. 2 Select Dockerfile or Buildpack
  3. 3 Save and trigger a new deploy

Or pick the strategy during initial deploy:

strategy
❯ ancla deploy
Build strategy:
  1. Dockerfile
  2. Buildpack

When to use each

Use Dockerfile if you need fine-grained control. Use Buildpack if you just want it to work.

Scenario Recommendation
Custom system packages, multi-stage builds Dockerfile
Standard Python / Node / Go app Either — Buildpack for simplicity
Getting started quickly Buildpack
Fine-grained image optimization Dockerfile