tai-distribution, running the
official image.
Boot the bundle
1
Get the bundle
2
Pin the image and set the secrets
POSTGRES_PASSWORD (it has no default — Compose refuses to start until
it is set), and pin the image to a release rather than running latest:TAI_VERSION in .env
3
Create the config directory
config/ bind-mounts at /app, so config/manifest.yml is the
manifest the runtime loads and config/.env is the
app-side environment. Create config/.env even when it is empty — the
config-reload path treats a missing file as an error.4
Start it
db-init runs tai db apply first; serve and backend wait for it
before they start. Only serve publishes a port
(${TAI_SERVE_PORT:-8000}) — Postgres and Redis stay on the Compose network.The persistent mounts
Two directories a real deployment must keep across a container recreation, each located by an env var the server reads:
The bundle bind-mounts
config/ for the first. Give the plugin prefix its own
persistent volume the same way, or a marketplace install
lands in the image’s ephemeral venv and is lost when the container is replaced.
Persist both, or a recreated container boots with the code and its registration
out of sync. The bundled Postgres and Redis keep their own named data volumes.
See Persist runtime installs for the full
picture.
Profiles
The core stack is arq-on-Redis with local storage. Three opt-in profiles add infrastructure for plugins that are not in the minimal image — add the plugin (a derived image or a marketplace install) before enabling its profile:compose/langfuse/ and likewise
needs the tai42-monitoring-langfuse plugin added — see
Monitoring with Langfuse.
Build the image from source (dev only)
For running the stack against uncommitted local changes,compose/docker-compose.local.yml layers a SOURCE=local build onto every app
service, building from sibling checkouts instead of pulling the release:

