# 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](/mcp/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](https://github.com/StuMason/coolify-mcp/issues/164) · 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](https://github.com/StuMason/coolify-mcp/issues/314) · 2026-07-29 · closed · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/StuMason/coolify-mcp/issues).