Configuration

Configure a build with acropolis.json or railpack.json and with ACROPOLIS_ or RAILPACK_ variables.

Most apps need no configuration: Acropolis detects the provider from the repo, with the same precedence as Railpack (Go, Rust, Python, Java and others win over a package.json). When detection needs help, there are two ways to steer it.

Config file

Acropolis reads acropolis.json, or railpack.json if there is none, from the app directory. --config (or the CONFIG_FILE variable) picks another file, which must stay inside the app directory. The file is JSON (JSON5 is accepted) and follows Railpack’s schema:

{
  "provider": "node",
  "buildAptPackages": ["libvips-dev"],
  "steps": {
    "build": { "commands": ["npm run build:prod"] }
  },
  "deploy": {
    "startCommand": "node dist/server.js",
    "aptPackages": ["ffmpeg"],
    "paths": ["dist"]
  }
}

Supported keys: provider, packages, buildAptPackages, steps (with commands, variables, inputs, caches, secrets, deployOutputs), deploy (startCommand, aptPackages, inputs, paths, variables, base), exclude, secrets and caches. Unknown keys fail the build, so a typo doesn’t go unnoticed.

Variables

App variables are passed with -e KEY=VALUE. Each setting is read with an ACROPOLIS_ prefix first and a RAILPACK_ prefix second, so a Railpack setup keeps working:

Variables reach build steps, but the plan and info.json only carry {env:NAME} references, never the values, and the image config doesn’t get them: set runtime variables on the container that runs the image.

Operator settings

These (with the ACROPOLIS_ or RAILPACK_ prefix) are read only from the environment of the acropolis process. If they come through -e or the config file they are ignored, so an app cannot change them: