Streamline Docker image creation when using workspaces

[JonasHiltl]

For me the biggest painpoint of monorepos and especially yarn/npm workspaces is the creation of Docker images. It would be super helpful if Turbo would be able to create Docker images, or generate Dockerfiles of the individual applications in the monorepo and automatically copy only the shared packages that the individual application relies on.
I know that this idea might be a bit off topic from Turbos actual goal, but I think that a lot of people are in need for this type of solution and maybe it can be intergrated through a plugin for Turbo.

[anthonyshew]

This is out of scope for Turbo today as this would put an undue burden on our team. Our --prune and --docker flags are likely as far as we'll venture into these waters.

Definitely sounds awesome to have, though. Maybe someday!

[kazukinakai]

I ran into exactly this pain point — manually wiring up turbo prune --docker multi-stage Dockerfiles for every service, keeping compose.yml volumes in sync, and repeating the same boilerplate across apps.

I ended up building a Rust CLI called airis that works alongside Turborepo (not a replacement). You define your workspace in a single manifest.toml:

[workspace]
name = "my-app"
package_manager = "pnpm@10.23.0"
image = "node:24-alpine"

[service.api]
# ...

[[app]]
name = "api"
path = "apps/api"
framework = "node"

[app.deploy]
enabled = true
variant = "nextjs"
port = 3000

Then airis gen generates:

• Dev Dockerfile — COPY . . → pnpm install --frozen-lockfile, with tini, non-root user
• compose.yml — bind mount for source + named volumes isolating node_modules, .pnpm, pnpm store (nothing leaks to host)
• Per-service production Dockerfile — 3-stage turbo prune → build → minimal runtime, with healthchecks
• CI/CD workflows — GitHub Actions for lint/typecheck/test + deploy

The key design decisions:

1. Docker-first filesystem boundary — dependencies live exclusively in named volumes, never on the host
2. Uses turbo prune internally for production Dockerfiles, so you still get Turborepo's dependency graph benefits
3. manifest.toml is the single source of truth — change it, re-run airis gen, done

It's open source (Rust, MIT): https://github.com/agiletec-inc/airis-monorepo

Would be curious if others have taken a similar approach or have different needs — happy to discuss.