Introduction
What Acropolis is, why we built it, and what it supports.
Acropolis turns an app’s source code into an OCI image with no Dockerfile and no daemon. It is a single Rust binary, acropolis, licensed Apache-2.0 or MIT, and it is the builder behind Olimpia.
Status
Why
On a PaaS every build starts on an empty machine, and the tools available there were slow, heavy, or produced huge images:
- Cold builds are slow. In our benchmark Railpack takes 54 to 170 s because it first downloads its builder image, and BuildKit does not retry a download that hangs: we saw a 68 MB layer download at 200 KB/s for 10 minutes. Docker is faster, but only if someone wrote a multi-stage Dockerfile by hand.
- Images are bloated. Railpack leaves devDependencies, the cache and its toolchain manager in the image: a sample Next app weighs 345 MB against 105 MB with a well-made Dockerfile.
- A lot of memory for little work. Railpack uses more than 2.9 GB of RAM to build an Express server with 7.5 MB of dependencies.
- Rebuilds reuse nothing. With Docker, changing one line of a Go app recompiles everything (41 s).
- No cache survives on an ephemeral builder.
What came out of it is in Benchmarks, and how it gets there in How it works.
What it supports
| ecosystem | image runtime |
|---|---|
| Node: npm, pnpm, yarn 1, yarn berry, bun; Next, Nuxt, Astro, SvelteKit, Remix, React Router, TanStack Start, Angular, Vite, Nx, Turborepo | distroless with a minimal shell when possible; otherwise node:<version>-bookworm-slim. Next standalone, Nitro, SPA on Caddy |
| Bun | distroless/cc + bun, or Debian slim |
| Go | distroless/static |
| Rust | distroless/cc |
| Python: uv, poetry, pdm, pipenv, pip | python:<version>-slim |
| Ruby, PHP/Laravel, Java, .NET, Elixir, Gleam, Deno, C/C++ | the official slim image of each one |
| Static sites and scripts | Caddy, Debian slim |
It honors railpack.json and acropolis.json: see Configuration. Apps with a Dockerfile are out of scope: keep building those with BuildKit.