Build Pipeline

ACT features a smart build pipeline that can automatically detect and build your application from source, even without a Dockerfile.

Build Logic

When you deploy a service, ACT follows this logic to determine how to build your image:

1. Manual Override: If you provided specific dockerfile_content via API, use it.
2. User Dockerfile: Check if a Dockerfile exists in the repo root (or context_path).
3. Nixpacks Auto-Detection: If no Dockerfile is found, ACT uses Nixpacks to analyze your code and generate a build plan.

[Start Deployment]
       │
       ▼
Has 'dockerfile' content in API? ─── Yes ──► [Build Custom Dockerfile]
       │
       No
       │
       ▼
Has Dockerfile in Repo? ──────────── Yes ──► [Build User Dockerfile]
       │
       No
       │
       ▼
[Run Nixpacks Analysis] ────────────► [Generate Plan] ──► [Build Image]

Nixpacks Auto-Detection

ACT uses Nixpacks (v1.29.1) to automatically build the following project types:

• Node.js: Detects package.json
• Python: Detects requirements.txt, poetry.lock, or Pipfile
• Go: Detects go.mod
• Rust: Detects Cargo.toml
• Java/Kotlin/Scala: Detects pom.xml or build.gradle
• PHP: Detects composer.json
• Static Sites: HTML/CSS/JS

Customizing Auto-Builds

You can customize the Nixpacks build by setting environment variables in your Service configuration:

• NIXPACKS_BUILD_CMD: Override the build command (e.g., npm run build:prod)
• NIXPACKS_START_CMD: Override the start command (e.g., node dist/main.js)
• NIXPACKS_PKGS: Install additional system packages (e.g., ffmpeg, imagemagick)

Docker-in-Docker (DinD) Support

ACT’s builder is optimized to run on remote servers. It handles the complexities of “Docker-in-Docker” builds automatically:

Requirements

When running ACT itself inside Docker (e.g., on Kubernetes or Docker Swarm), you must:

• Mount the Docker socket: -v /var/run/docker.sock:/var/run/docker.sock
• Ensure the container has sufficient permissions to access the Docker API

Build Fallback Mechanism

ACT implements a robust fallback strategy for DinD environments:

1. Primary Strategy: Attempts to use volume mounts for build context and cache
2. Fallback Strategy: If volume mounts fail (common in standard DinD limitations), ACT switches to:
   • docker create to prepare the build container
   • docker cp to transfer build context and cache files
   • Automatic cleanup after build completion

This fallback ensures builds succeed even in restrictive containerized environments.

Performance Features

• Local Cache: Uses /var/lib/act/build-cache on the server to speed up repeated builds.
• Registry Cache: Pushes build cache layers to your container registry for multi-server performance.
• Multi-Arch: Supports building amd64 and arm64 images using QEMU emulation if needed.