[Bug]: force_domain_override is ignored for docker_compose_domains when creating an application via the API

[praetoros]

Description and Error Message

Creating a Docker Compose application through POST /api/v1/applications/{public,private-github-app,private-deploy-key} returns 409 when docker_compose_domains names a domain another resource already uses. This happens even when the request sets force_domain_override: true:

{"message":"Domain conflicts detected. Use force_domain_override=true to proceed.","conflicts":[...]}

In create_application(), removeUnnecessaryFieldsFromRequest($request) removes force_domain_override from the request before the docker_compose_domains checks run. Those checks then read $request->boolean('force_domain_override'), which is always false by that point. At v4.3.23 that's L1385, followed by the checks at L1418 and L1439, with the same pattern in the private-GitHub-app and deploy-key branches.

Two checks are affected:

• the conflict check against other resources, which returns 409;
• the duplicate check within the request, which returns 422 when two services share a URL.

domains isn't affected, because validateDataApplications() checks it before the field is removed. Neither is update_by_uuid, which removes the field only after all its checks.

Expected Behavior

With force_domain_override: true, the application is created with the conflicting docker_compose_domains, the same as for domains on create and for docker_compose_domains on PATCH /applications/{uuid}.

Steps to Reproduce

1. Have an application that already uses https://shared.example.com.
2. Call:

   POST /api/v1/applications/public
   {
     "project_uuid": "...", "environment_uuid": "...", "server_uuid": "...",
     "git_repository": "https://github.com/<any public repo with a compose file>",
     "git_branch": "main",
     "build_pack": "dockercompose",
     "docker_compose_domains": [{"name": "web", "domain": "https://shared.example.com"}],
     "force_domain_override": true
   }
   

3. The response is 409, returned before the repository is read.

This Pest test reproduces it on main (a8117f9) without a server. It needs a sibling application with that fqdn, and uses Queue::fake() so LoadComposeFile doesn't clone the repository:

it('creates the application when force_domain_override is true', function () {
    $this->withToken($this->bearerToken)->postJson('/api/v1/applications/public', [
        'project_uuid' => $this->project->uuid,
        'environment_uuid' => $this->environment->uuid,
        'server_uuid' => $this->server->uuid,
        'git_repository' => 'https://gitlab.com/coollabsio/coolify-examples',
        'git_branch' => 'v4.x',
        'build_pack' => 'dockercompose',
        'docker_compose_domains' => [['name' => 'web', 'domain' => 'https://shared.example.com']],
        'force_domain_override' => true,
    ])->assertCreated(); // fails: received 409
});

A fix: read the flag once at the top of create_application(), before anything strips it, as UpdateServiceApplicationFromApi already does. Then use that variable in the six compose checks. With that change the test passes, and ApplicationDomainValidationApiTest and ApplicationDomainsTest give the same results as without it. I can open a PR against main if that's welcome.

Example Repository URL

Any public repository with a compose file. The request fails before the repository is read.

Coolify Version

Coolify Cloud, 2026-09-26. The code is the same at v4.3.23, v4.0.0 and main (a8117f9).

Are you using Coolify Cloud?

Yes

Operating System and Version (self-hosted)

N/A (Coolify Cloud)

Additional Information

Found while fixing the same flag in the Terraform provider, which didn't send it on create: coolify-terraform/terraform-provider-coolify#907. The provider only sends docker_compose_domains in its follow-up PATCH, so it isn't affected by this bug. Clients that create compose applications in one request are.

Claude Code was used to trace the code paths, write the Pest test and run it in a container. The findings were reviewed before filing.