bug: fqdn field not sent correctly to Coolify API (should be domains)

[terry90918]

Bug Description

When creating or updating applications with a custom domain using the fqdn field, the domain setting is silently ignored by the Coolify API.

Root Cause

The Coolify API expects the field to be named domains, not fqdn. The following methods pass fqdn directly in the request body without mapping it:

• createApplicationPublic
• createApplicationPrivateGH
• createApplicationPrivateKey
• updateApplication

Steps to Reproduce

await client.createApplicationPublic({
  project_uuid: 'proj-uuid',
  server_uuid: 'server-uuid',
  git_repository: 'https://github.com/user/repo',
  git_branch: 'main',
  build_pack: 'nixpacks',
  ports_exposes: '3000',
  fqdn: 'https://app.example.com', // ← this is never applied
});

Expected Behavior

The application is created with https://app.example.com as its domain.

Actual Behavior

The domain is not set because the Coolify API receives fqdn instead of domains and ignores it.

Fix

Map fqdn → domains before sending the request to the API. A mapFqdnToDomains helper should be applied in all 4 affected methods to transparently convert the field while preserving backward compatibility for callers.

[StuMason]

#110 (comment)

Good we’ve hit this issue again, I’ll take a look at your PR thanks for that, worried about backwards compatibility and how we handle that with this whole MCP, think it needs a big long thinking about

[terry90918]

Hi @StuMason — I traced through the Coolify source code history to address the backward compatibility concern directly.

TL;DR

domains was always the correct API request field — including ≤460. No try/fallback or version detection needed.

Source Code Evidence

bootstrap/helpers/api.php at 7c0cb2f (commit immediately before beta.461) — domains was already a validated field:

function sharedDataApplications()
{
    return [
        'domains' => 'string',   // ← always a valid API field
    ];
}

function removeUnnecessaryFieldsFromRequest(Request $request)
{
    $request->offsetUnset('domains');  // explicitly consumed as part of normal flow
}

ApplicationsController.php at the same commit — every handler read domains from the request:

$fqdn = $request->domains;   // reads 'domains' from request body
$application->fqdn = $fqdn;  // 'fqdn' is the DB column name, not the API field

Why fqdn accidentally worked in ≤460

The controller called $application->fill($request->all()) without strict field filtering. Since fqdn is the model's DB column name, sending it in the request body would directly set the attribute as a side effect — never by design.

beta.461 (ce3cae3f) added strict validation that rejects unknown fields, which is why fqdn started failing.

Revised compatibility picture

	domains	fqdn
POST/PATCH ≤460	✅ Always correct	⚠️ Accidental side effect
POST/PATCH ≥461	✅ Correct	❌ Rejected

The PR is safe for all versions. Full write-up also posted on the PR itself.

[terry90918]

Additional historical evidence — deeper git archaeology

Following up on the previous comment, I've traced the full git history of both fields to give a more complete picture.

Precise timeline

Date	Commit	Event
2024-06-21	cd8509411	Applications.php created — GET endpoints only, no fqdn or domains
2024-06-28	30b7e831	domains introduced as the API input field in sharedDataApplications(). $fqdn is only an internal PHP variable ($fqdn = $request->domains) that writes to the DB column
2024-07-01	da6f2da3	File renamed to ApplicationsController.php. extraFields strict validation introduced — passing fqdn in the request body triggers 422 "This field is not allowed"
2025-12-09	32e047e5	Bug fix: POST response was returning null for domains (reading non-existent model attribute) — fixed to data_get($application, 'fqdn')
2026-01-12	ce3cae3f	beta.461 — additional restrictions (dockercompose apps cannot use domains; nullable support)

Key findings

1. fqdn was never a valid API input field — not even for a single release. sharedDataApplications() has always listed domains, never fqdn.

2. The accidental window was 3 days (June 28 → July 1, 2024). During those 3 days, fill($request->all()) without strict filtering meant fqdn accidentally wrote to the model's DB column. The extraFields check that makes this explicit was introduced 3 days later — not in beta.461.

3. domains has been the correct field for ~1.5 years (beta.307, June 2024). Any Coolify instance anyone is actually running will be far newer than that.

So try/fallback or version detection are not needed — sending domains is safe across all real-world versions.