Every env create against the Coolify API writes two identical rows — reproduced on the raw REST API (curl → POST /api/v1/applications/{uuid}/envs, Coolify 4.1.2), so it's upstream Coolify, not this MCP. It has now bitten five times on one estate (Umami envs, edator DB cutover envs, ASR_THREADS, ASR_URL, LIBRARY_EMBED_*), and update can't fix it (matches by key → only ever reaches the first row; last-wins semantics mean the dupe silently controls nothing until it diverges — the Umami incident).
Since the MCP wraps create anyway, it can absorb the bug: after create, list envs for the resource, and if the key appears twice delete the row whose uuid != the one create returned. That turns a recurring production foot-gun into a non-event. Worth reporting upstream to coollabsio/coolify too.
Every env
createagainst the Coolify API writes two identical rows — reproduced on the raw REST API (curl → POST /api/v1/applications/{uuid}/envs, Coolify 4.1.2), so it's upstream Coolify, not this MCP. It has now bitten five times on one estate (Umami envs, edator DB cutover envs, ASR_THREADS, ASR_URL, LIBRARY_EMBED_*), andupdatecan't fix it (matches by key → only ever reaches the first row; last-wins semantics mean the dupe silently controls nothing until it diverges — the Umami incident).Since the MCP wraps create anyway, it can absorb the bug: after create, list envs for the resource, and if the key appears twice delete the row whose uuid != the one create returned. That turns a recurring production foot-gun into a non-event. Worth reporting upstream to coollabsio/coolify too.