Docker Compose
Import a compose file once. Nodion turns it into an app, processes, and managed services.
This path is experimental. It is not docker compose up. Nodion does not keep running Compose, apply networks, or re-read the file on later deploys.
On Applications → New, connect a Gitrepo. If the scan finds a compose file with at least one app service, a Docker Compose choice appears. It is never preselected. Click it to review the plan, then create.
Which file
The shallowest of these names wins:
docker-compose.yml/docker-compose.yamlcompose.yml/compose.yaml
A file with only databases or caches (no app service) is ignored. A parse error is ignored. A compose file deep in a large repo can be missed if the scan is truncated.
What gets created
One application, not one app per service. Extra services become extra processes on that app. The wizard lets you pick package and replicas (1-16) before create. deploy.replicas in the file is ignored.
| Compose image name contains | Nodion creates |
|---|---|
postgres, postgis | Managed Postgres |
pgvector | Managed pgvector |
mysql, mariadb | Managed MySQL |
redis, valkey | Managed Valkey |
clickhouse | Managed ClickHouse |
minio | A bucket |
Anything else, or a build: | A process on the app |
Image tags such as postgres:16 do not pick the managed engine version. Nodion uses its current default for that engine. Database users and passwords come from Nodion, not from the compose env on the database service.
If an app service env value points at another service as host (postgres://…@db:5432/…, redis://cache:6379), that key becomes an attach binding and is injected on deploy. Otherwise Postgres-style databases bind as DATABASE_URL, Valkey as REDIS_URL, and MinIO as the usual AWS/S3 keys.
Only the primary app service’s remaining environment is copied onto the app. Keys that look like secrets are marked secret in the form.
Volumes
Named volumes become volumes (default 5 GB, editable in the wizard) and mount on the matching processes. Bind mounts (./data:/data) and anonymous volumes are skipped.
How the app builds after that
The app’s strategy is still Dockerfile or Buildpacks, from the same repo scan. Compose build.context and build.dockerfile are not copied into those settings. There is one Git build per app. A second service with its own build: shares that image.
A service that only has image: (and is not a mapped database) keeps that image and runs it as a process. The primary service with build: is renamed web.
First deploy waits until attached databases and buckets are ready. After create, change processes, env, and resources in the dashboard. Editing the compose file in Git does not update the plan.
What is ignored
- Networks, profiles, and Compose healthchecks
depends_onas startup order (a wait-only helper container is skipped)- Bind mounts
- Per-service builds beyond the one app image
If a managed engine or object storage is not available in the region, that resource is skipped and the app is still created.