Skip to content

Expose docker_compose_domains on app create / app update for compose-pack applications #73

Description

@srvo

Feature request — expose docker_compose_domains on app create and app update

The Coolify v4 application API for --build-pack dockercompose exposes a docker_compose_domains field on POST /applications/{type} and PATCH /applications/{uuid}. It's the only way to set Traefik routing for a specific service inside a compose-built application:

"docker_compose_domains": [
  { "name": "litellm", "domain": "https://litellm.example.com" }
]

The CLI currently has no flag for this. Two side-effects:

  1. coolify app create public/github/deploy-key --build-pack dockercompose --domains https://... returns 422 The domains field cannot be used for dockercompose applications. Use docker_compose_domains instead to set domains for individual services. — but there's no CLI path to set it.
  2. After creating a compose Application via the CLI, the container starts with no Traefik labels (traefik.http.routers...), so Traefik returns 503 on the configured FQDN. The user has to fall back to a raw curl PATCH against the API to set domains, then trigger another deploy.

Suggested shape

Repeatable flag, format <service>=<url> (URL can contain commas for multi-domain):

coolify app create github \
    --build-pack dockercompose \
    --git-repository org/monocloud \
    --git-branch main \
    --base-directory /services/litellm/coolify \
    --ports-exposes 4000 \
    --compose-domain litellm=https://litellm.example.com \
    --compose-domain admin=https://admin.example.com,https://admin2.example.com

coolify app update <uuid> --compose-domain ... should accept the same flag for post-create reconfiguration.

Why this matters for AI agents / automation

The llms-full.txt advertises the CLI as the canonical interface for scripted deploys. Agents that follow the docs will create a compose Application, sync env, restart — and end up with a 503 from Traefik with no obvious next step. The workaround (raw API PATCH) is documented nowhere in the CLI surface, so it has to be reverse-engineered from the OpenAPI spec.

Happy to send a PR if the shape above is roughly what you'd want. Repro / context for what we hit while standing this up: monocloud LiteLLM migration via the CLI on Coolify v4.0.0, May 2026.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions