Reported issues for coolify
Pod holds 24 of 82 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.
Back to coolify.
Most discussed
Ability to connect with multiple servers
Problem or motivation
Would love a settings screen where we could specify multiple coolify URL's and Api's
Proposed solution
Menu that allows us to CRUD coolify URL's and Keys, then have the LLM auto select the current repo's assigned Coolify server details.
Alternatives considered
The ability to manually select the coolify server we are currently working with
Read the thread · 2026-04-27 · closed · external user · 4 comments
env_vars create/update should support is_buildtime and is_runtime flags
Context
When creating or updating environment variables via the env_vars tool, there's no way to control the is_buildtime and is_runtime flags. All vars default to is_buildtime: true, is_runtime: true.
This causes a hard failure when setting multiline values (like PEM keys for PASSPORT_PRIVATE_KEY) because Coolify injects build-time vars as ARG directives in the Dockerfile, and multiline values break the Dockerfile parser:
Dockerfile:11
--------------------
9 | ARG DB_
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/135) · 2026-02-26 · closed · 3 comments
### bug: fqdn field not sent correctly to Coolify API (should be domains)
## 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
```typescript
await client.crea
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/126) · 2026-02-23 · closed · outside contributor · 3 comments
### Failed to create client
Hi,
I added with my env
`"coolify": {
"command": "npx",
"args": [
"-y", "@masonator/coolify-mcp"
],
"env": {
"COOLIFY_ACCESS_TOKEN": "0|your-secret-token",
"COOLIFY_BASE_URL": "https://your-coolify-instance.com"
}
}`
to .cursor/mcp.json
However, I am not able to connect the server.
https://forum.cursor.com/t/mcp-add-persistent-memory-in-cursor/57497
<img width="571" alt="Image" src="https://github.com/user-attachments/assets/dffb5422-a974-469b-8d9
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/15) · 2025-03-13 · closed · external user · 3 comments
### V3: OAuth 2.1 + Streamable HTTP transport — run as a container inside Coolify
Part of the V3 epic (#259). This is the change that makes V3 a major rather than an internals refresh.
## Goal
Ship one codebase with **two transports**:
1. **stdio** — exactly what exists today. Unchanged behaviour, unchanged config, unchanged npm and MCPB artifacts. Nobody on stdio should notice V3 happened beyond a version number.
2. **Streamable HTTP + OAuth 2.1** — deployable as a container on the user's own Coolify instance, so remote MCP clients (claude.ai in particular) can manage inf
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/303) · 2026-07-29 · open · 2 comments
### Heads up: Coolify v4.2 breaks several client calls (405s + hidden secrets)
# Heads up: Coolify v4.2 breaks several client calls (405s + hidden secrets)
Coolify v4.2 was merged into `v4.x` on Jul 19, 2026 via [coollabsio/coolify#10872](https://github.com/coollabsio/coolify/pull/10872). It is not on the releases index page yet, so it is easy to miss.
I went through `src/lib/coolify-client.ts` at `e8dfb4b` (current `main`, dated Jul 16) and found four areas that will break once users upgrade. Opening this as a heads up rather than a bug report, since nothing is broken t
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/292) · 2026-07-25 · closed · external user · 2 comments
### Database की env vars by default plaintext में return हो रही हैं
## समस्या क्या है
`env_vars` tool की अपनी description में लिखा है कि secret values by default **mask** होकर आती हैं (यानी `***` के रूप में), ताकि वो गलती से MCP client को leak न हो जाएँ — और अगर plaintext value चाहिए तो caller को explicitly `reveal=true` भेजना पड़ता है। ये बात application और service के लिए तो सही है, लेकिन **database के लिए नहीं**।
जब आप किसी database की environment variables list करते हैं, तो values सीधे **plaintext में** आ जाती हैं, बिना कुछ माँगे। और सबसे बड़ी बात — यहाँ `r
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/277) · 2026-07-15 · closed · 2 comments
### env create: Coolify API writes duplicate rows (upstream bug) — auto-dedupe in the MCP
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 inci
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/257) · 2026-07-11 · closed · 2 comments
## Most recent
### Three Coolify API parameters not exposed: destination_uuid on service create, public port on existing databases, connect_to_docker_network
First, thanks for this server. I spent a full day driving a Coolify instance through it and the tool design held up well, `service`, `env_vars`, `deploy` and `scheduled_tasks run_once` in particular. I hit three gaps where the Coolify API supports a parameter that the MCP does not expose, and each one forced me out of the MCP and into the browser or the CLI.
Version tested: **2.19.3**, Coolify **4.3.9** self-hosted.
### 1. `service create` cannot set `destination_uuid`
On a server with more t
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/351) · 2026-08-21 · open · external user · 1 comment
### Return canonical Coolify UI links instead of letting the model construct them
Several mature MCP servers ship a tool whose only job is to mint a correct link back into the product UI, and the stated reason is always the same: models retype identifiers into paths and get them wrong.
PostHog's `generate-app-url` says it outright:
> ALWAYS use this (or an existing `_posthogUrl` field) instead of writing PostHog links by hand: slugs and project/host prefixes are easy to get wrong (a person UUID lives at `/persons/<uuid>`, not `/person/...`) and IDs must never be retyped int
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/342) · 2026-08-06 · open · 0 comments
### Migrate destructive confirmation from elicitation/create to MRTR
The destructive-confirmation guard is built on server-initiated `elicitation/create`. Under `2026-07-28` that pattern no longer exists.
## What replaced it
**Multi Round-Trip Requests** (SEP-2322). The server returns an `InputRequiredResult` (`resultType: "input_required"`) carrying an `inputRequests` map plus an opaque `requestState`; the **client retries the original request** with `inputResponses` and that state. Servers may only initiate a request while actively processing a client request
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/341) · 2026-08-06 · open · 0 comments
### OAuth hardening for HTTP mode: CIMD over DCR, 401 shape, PRM paths, SSRF guards
Auth findings from a review of the current spec and Anthropic's connector docs, relevant to the OAuth AS built in #303.
## 1. DCR is deprecated — advertise CIMD
`2026-07-28` deprecates OAuth Dynamic Client Registration (RFC 7591) in favour of **Client ID Metadata Documents**. Anthropic explicitly recommends CIMD over DCR at directory scale, because DCR registers a brand-new client on every fresh connection — which for us also means unbounded growth in the OAuth state file.
Claude selects CIMD
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/340) · 2026-08-06 · open · 1 comment
### Set the server instructions field — it is what tool-search clients read first
We do not set the server `instructions` field at all. That is now the single highest-leverage string in the server.
## Why it changed
Claude Code enables tool-definition deferral by default (`ENABLE_TOOL_SEARCH`, on for Sonnet/Haiku/Opus 4.5+). At session start it loads **only tool names and the server's `instructions` field**; full definitions are fetched on demand. Claude Code also states it imposes no fixed per-server tool cap.
So on that client the ~6,600-token `tools/list` achievement is
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/339) · 2026-08-06 · open · 0 comments
### Split tools by safety class: reads are currently annotated destructive
## The problem
24 tools in `TOOL_ANNOTATIONS` are annotated `DESTRUCTIVE`, with the comment "every one of these has a delete, stop, or replace": `application`, `database`, `service`, `projects`, `environments`, `env_vars`, `private_keys`, `github_apps`, `cloud_tokens`, `storages`, `tags`, `scheduled_tasks`, `database_backups`, `control`, `deploy`, `deployment`, `system` and the batch tools.
Every one of those also contains `list` and `get` actions. So **listing your applications currently carr
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/338) · 2026-08-06 · open · 0 comments
### Adopt protocol revision 2026-07-28 (stateless core, cacheable lists, server/discover)
Protocol revision **`2026-07-28`** shipped on 28 July 2026. It is the largest breaking change since MCP launched, and since #259 already moves us onto SDK v2 this is the natural release to absorb it.
No client has shipped it yet — Anthropic's connector docs still cap at `2025-11-25` and VS Code at `2025-06-18` — so the target is: **write against SDK v2, serve both eras on the wire** via `createMcpHandler` with the default `legacy: 'stateless'`. This is not a cutover, it is dual-era support.
##
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/337) · 2026-08-06 · open · 0 comments
### Field-test follow-ups: list_databases drops types on id collision, env schema, diagnose_app scope + FQDN matching, find_issues signals
Remaining items from the external field test of the remote server (the masking findings shipped in 2.19.3 / #334).
1. **`list_databases` silently drops whole database types (upstream id collision).** Verified live: an instance with 2 standalone Postgres and 2 standalone Dragonfly returns only the Dragonflys from `GET /databases`. Coolify keeps a per-type id sequence (both pairs are ids 1 and 2), and the list endpoint evidently merges the per-type collections keyed on `id`, so one type overwrite
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/336) · 2026-08-06 · closed · 1 comment
### environments/projects get bypass credential masking (nested payload paths)
Found by an external field test of the remote server: `environments get` returned raw upstream JSON with plaintext database passwords, `internal_db_url` connection strings, the server's `sentinel_token` and the full log-drain configuration — while `get_server` correctly masks those same fields. Root cause exactly as the tester diagnosed: masking was applied per-endpoint (#209, #328, #332), so every endpoint that nests resources — environments embedding database rows, projects embedding environme
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/334) · 2026-08-06 · closed · 0 comments
### get_application raw passthrough leaks webhook secrets and the full server row
Same class as #328, found reading an application's config through the MCP after that fix shipped.
`get_application` (and the `application` tool's update response) passes the upstream payload straight through. On every published version that includes:
- `manual_webhook_secret_github` / `_gitlab` / `_gitea` / `_bitbucket` — the HMAC keys that let anyone forge deploy webhooks for the app
- `http_basic_auth_password`
- the full nested `destination.server` row: settings blob with `sentinel_token`,
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/332) · 2026-08-06 · closed · 0 comments
### get_database / get_service raw passthrough includes plaintext credentials
Found running the read-only tool sweep against a live Coolify 4.1.2.
The masking story ("Secure by default" in the README) covers `env_vars`, `system list_resources` and `deployment get` — but the plain `get_*` tools pass the raw upstream payload through, and on a pre-4.2 instance that includes real secrets:
- `get_database`: the database password in its own field, plus `internal_db_url` with the password embedded.
- `get_database` / `get_service`: both embed the full nested `server` object, w
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/328) · 2026-08-05 · closed · 0 comments
### private_keys returns full key material on pre-4.2 instances
Found running the read-only tool sweep against a live Coolify 4.1.2.
`private_keys` with `action: list` (and `get`) passes the upstream response straight through, and on pre-4.2 instances that response includes the complete PEM `private_key` for every key. One casual list call hands an MCP client every deploy key and the host SSH key in plaintext.
Two things follow:
1. **Mask key material like env var values.** Return `private_key: '***'` by default and require an explicit `reveal: true` to g
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/327) · 2026-08-05 · closed · 0 comments
### Site: tests and type-checking for the contact endpoint
Follow-up to #318, from its review. Non-blocking — the site is not deployed yet.
**1. No tests on `site/src/pages/api/contact.ts`.** It has ~200 lines of validation, sanitisation, origin checking and rate limiting, and the site has no test runner. `clean()`, `EMAIL_RE`, `originAllowed()` and `rateLimited()` are pure or near-pure and the handler takes a synthetic `Request`. The CRLF stripping in `clean()` is the header-injection defence for the SES subject and reply-to — that should not be regre
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/319) · 2026-07-30 · closed · 0 comments
### Destructive operations still unguarded by elicitation confirmation
Follow-up to #313, which wired elicitation confirmation into `stop_all_apps`, `redeploy_project`, `restart_project_apps`, `system disable_api`, the application / database / service / project / environment deletes, and `bulk_env_update` above three apps.
That set came from what #261 happened to list. This issue is to make it a **decision** instead — either guard these too, or write down why they do not need it.
## Unguarded, and destroys data
- **`storages` delete** (`src/lib/mcp-server.ts`, `
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/316) · 2026-07-30 · closed · 1 comment
### Elicitation: decide the boundary for the remaining unguarded destructive tools
Follow-up to #261 / #313, so the covered set is a decision rather than a gap.
#313 wired human confirmation into the operations with the largest blast radius: `stop_all_apps`, `redeploy_project`, `restart_project_apps`, `system disable_api`, the application / database / service / project / environment deletes, and `bulk_env_update` above three apps.
Still unguarded, in descending order of how much it probably matters:
- `private_keys` `delete` — removing the key an application deploys with br
[Read the thread](https://github.com/StuMason/coolify-mcp/issues/315) · 2026-07-29 · closed · 1 comment
### isRunningStatus counts 'exited:unhealthy' as running
Split out of #313 so the boundary is a decision on record rather than a comment nobody has an issue number for.
## What
`isRunningStatus` (`src/lib/coolify-client.ts`) decides which applications `stop_all_apps` targets:
```ts
return value.includes('running') || value.includes('healthy');
'unhealthy' contains 'healthy', so exited:unhealthy is classified as running.
Why it has not mattered
- The only consequence today is a stop issued against an already-stopped application, whic
Read the thread · 2026-07-29 · closed · 1 comment
The remaining reports are on the project's issue tracker.