Stu Mason

Closes #126

Summary

Coolify API uses the domains field for setting application domain, not fqdn
Added mapFqdnToDomains helper that transparently converts fqdn → domains before sending requests
Applied to createApplicationPublic, createApplicationPrivateGH, createApplicationPrivateKey, and updateApplication
Callers using the fqdn field now work correctly without any breaking changes

Root Cause

When creating or updating applications with a custom domain, passing fqdn: "https://app.example.com" was silently ignored by the Coolify API because it expects the field to be named domains. This meant domain settings were never applied.

Historical Evidence

Git archaeology on coollabsio/coolify shows domains has been the correct API field since the very beginning:

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`	`extraFields` strict validation introduced — passing `fqdn` triggers 422 `"This field is not allowed"`
2025-12-09	`32e047e5`	Bug fix: POST response was returning `null` for `domains` — fixed to `data_get($application, 'fqdn')`
2026-01-12	`ce3cae3f`	beta.461 — additional restrictions for dockercompose; `domains` becomes `nullable`

Key points:

fqdn was never a valid API input field — sharedDataApplications() has always listed domains, never fqdn
The accidental window was 3 days (June 28 → July 1, 2024) — fqdn accidentally worked via fill($request->all()) before strict validation was added
domains has been correct for ~1.5 years (beta.307) — try/fallback or version detection are not needed

Design options

Option A (this PR): Keep fqdn in TypeScript types, map silently → no breaking change for existing callers

Option B: Rename fqdn → domains in CreateApplicationPublicRequest / UpdateApplicationRequest and update mcp-server.ts → types match the API exactly, helper removed. Since fqdn was always silently broken, this could be argued as a non-breaking fix.

Happy to update either way — feedback welcome.

Changes

src/lib/coolify-client.ts — Added mapFqdnToDomains generic helper and applied it in the 4 affected methods
src/__tests__/coolify-client.test.ts — Added 6 tests covering:
- fqdn → domains mapping in all 3 create methods
- fqdn → domains mapping in updateApplication
- Combined fqdn + docker_compose_raw in updateApplication
- No-op when fqdn is not provided
CHANGELOG.md — Added entry under new [2.6.3] version

Test plan

All 235 existing tests pass
6 new tests added and passing
fqdn is correctly renamed to domains in request body
fqdn key is absent from the final request body
Requests without fqdn are unaffected

🤖 Generated with Claude Code

Activity

PR #125 opened: fix: map fqdn to domains for Coolify API compatibility