Import a Docker Compose file

Dekka can read a docker-compose.yml and set up the same app as Dekka services. Containers that run your code become services, Postgres, Redis and MinIO containers become managed databases and buckets with connections, and the variables that pointed at those containers are rewritten to use the connections. A report lists what carried over, what changed to fit Dekka and what was left out, and nothing is created until you deploy the plan.

Import in the dashboard

1. On a project's canvas, choose Add, then Template or dekka.yaml, and open the Docker Compose tab.
2. Paste the file or choose Open a file, then choose Translate.
3. Read the report. If any service has a build section, choose the GitHub Repository and Branch to build it from.
4. Fill in any values the file asks for, choose Review changes, check the planned changes and deploy them.

The translation is a dekka.yaml blueprint, so you can also copy it, keep it in your repository and plan it again later.

What the report looks like

This is part of n8n's own Compose file for running with Postgres.

services:
  postgres:
    image: postgres:16
    environment:
      - POSTGRES_USER
      - POSTGRES_PASSWORD
      - POSTGRES_DB
    volumes:
      - db_storage:/var/lib/postgresql/data

  n8n:
    image: docker.n8n.io/n8nio/n8n
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_USER=${POSTGRES_NON_ROOT_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_NON_ROOT_PASSWORD}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY:?set an encryption key}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE:-Africa/Accra}
    ports:
      - 5678:5678
    volumes:
      - n8n_storage:/home/node/.n8n
    depends_on:
      - postgres

The report groups each note under Carried over as written, Changed to fit Dekka or Left out.

The n8n service ends up with DB_POSTGRESDB_HOST set to ${{n8n.PGHOST}}, so it reads the managed database's host from its connection, and N8N_ENCRYPTION_KEY becomes a required value you enter before planning.

How Compose maps to Dekka

Variables that point at databases

Inside Compose, services find each other by container name, such as postgres:5432. On Dekka a connection gives the service its own credentials as variables, so the translation rewrites values that named a database container.

• A URL such as DATABASE_URL=postgres://user:pass@db:5432/app or REDIS_URL=redis://cache:6379 is dropped, because the connection sets that variable itself.
• A variable whose value is the container's name, port, user, password or database, such as DB_HOST=db or DB_PASSWORD=${POSTGRES_PASSWORD}, reads the matching connection variable instead, such as ${{web.PGHOST}} or ${{web.PGPASSWORD}}.
• A URL or host variable that names another service, such as API_URL=http://api:8000, uses that service's private domain, ${{api.DEKKA_PRIVATE_DOMAIN}}.
• A secret whose value is a placeholder, such as APP_SECRET=replace-me-with-a-random-string, gets a random value that Dekka generates once.
• Variables Dekka sets itself, such as PORT, keep Dekka's value.

Values from your shell

Compose fills ${VAR} from your shell or a .env file, which Dekka can't see, so the translation turns them into values you enter when you plan.

Names that look like secrets, such as ones containing PASSWORD, TOKEN or KEY, are entered as secrets. Commands and build arguments can't read these values, so a command or build argument that uses one without a default is left out and the report says so.

Services that build from source

A service with a build section is built from a GitHub repository you choose, with the Dekka GitHub App connected. Every such service in the file uses the same repository and branch, and its context becomes its root directory. Planning without a repository answers 422 repository_required with the services that need one. A remote build context, such as a Git URL, isn't fetched, and dockerfile_inline isn't read, so commit the Dockerfile to the repository instead.

What's left out

Settings that make no difference on Dekka, such as container_name, labels, logging and stop_signal, are ignored without a note.

Import with the API

POST /v1/compose/translate returns the blueprint, the report, the resources it would create, the values it needs and whether it needs a repository, and changes nothing.

curl https://api.dekka.cloud/v1/compose/translate \
  -H "Authorization: Bearer $DEKKA_API_KEY" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile content docker-compose.yml '{content: $content}')"

POST /v1/environments/{id}/compose/plan translates the file again and plans it into an environment, returning a changeset. Pass the values it asks for in inputs, and the repository for any build services.

curl https://api.dekka.cloud/v1/environments/$ENV_ID/compose/plan \
  -H "Authorization: Bearer $DEKKA_API_KEY" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile content docker-compose.yml '{
        content: $content,
        inputs: {N8N_ENCRYPTION_KEY: "your-32-character-key"},
        repository: {full_name: "acme/shop", branch: "main"}
      }')"

Deploy the changeset with its id once you've read the changes.

curl -X POST https://api.dekka.cloud/v1/changesets/$CHANGESET_ID/deploy \
  -H "Authorization: Bearer $DEKKA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"confirm": true}'

A file that isn't valid YAML, has no services or is larger than 200 KB answers 422 invalid_compose. A required value left out answers 422 missing_input with the missing keys, and going over your plan's limits answers 403 entitlement_exceeded.