# Reported issues for io.github.StuMason/coolify

Pod holds 21 of 24 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 [io.github.StuMason/coolify](/mcp/io-github-stumason-coolify).

## Most discussed

### 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

### 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

### 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

### `create` with `docker_compose_raw` param throws error

### What happened?

Trying to create a service on my Coolify instance with a docker_compose_raw definition from inside of Claude Code returns `Error: messages.join is not a function`

```
⏺ coolify - service (MCP)(action: "create", project_uuid: "replaced", server_uuid: "replaced", environment_name: "production", docker_compose_raw: "services:\n   test:\n    image: nginx")
  ⎿  Error: messages.join is not a function
```

### Steps to reproduce

Best as I can tell the service create tool hangs or

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/107) · 2026-01-30 · closed · external user · 2 comments

### Support fetching logs for specific services in docker-compose applications

### Problem or motivation

Currently, application_logs only returns logs from one container when an application uses docker compose build pack with multiple services. There's no way to specify which service's logs to retrieve.

Use case:
For a docker-compose app with frontend and backend services, calling application_logs only returns one of the application logs. I need to access logs from other services too.

### Proposed solution

Add an optional service parameter to application_logs:

  {
   

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/92) · 2026-01-18 · closed · external user · 2 comments

### Title: Missing `coolify_github_app` tool and broken `create_github` action

**Description:**

The Coolify MCP server is missing functionality to create GitHub App integrations, and the existing `create_github` action in `coolify_application` appears to be broken or misimplemented.

**Issue 1: No tool to create GitHub App integrations**

The Coolify REST API provides `POST /api/v1/github-apps` to create GitHub App integrations with parameters:
- `name`, `organization`, `api_url`, `html_url`, `app_id`, `installation_id`, `client_id`, `client_secret`, `webhook_secret`, `pr

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/75) · 2026-01-14 · closed · external user · 2 comments

### Glama listing is missing Dockerfile

Your MCP server is currently listed on the [Glama MCP directory](https://glama.ai/mcp/servers/StuMason/coolify-mcp), but it is not available for others to use because it does not have a Dockerfile.

It takes only a few minutes to fix this:

1. Go to your server's listing: [StuMason/coolify-mcp](https://glama.ai/mcp/servers/StuMason/coolify-mcp)
2. Click "Claim" to verify ownership.
3. Once claimed, navigate to the [admin `Dockerfile` page](https://glama.ai/mcp/servers/StuMason/coolify-mcp/admin/

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/16) · 2025-04-22 · closed · external user · 2 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

## 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

### Include whether an env variable is "preview" type or not

### Problem or motivation

It seems that the mcp doesn't let the llm know whether a variable is a preview type or not, which confuses it a lot, since it will think that variables are set wrong, then it corrects, often the wrong one, and gets really confused 😅

### Proposed solution

Add information about what type of env variable a variable is.
I'm not sure on the setting of variables, but I assume you'd need to be able to distinguish what you are setting as well :)

### Alternatives considered

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/291) · 2026-07-23 · closed · external user · 1 comment

### env_vars list ignores the key parameter — reveal=true dumps every secret on the resource

## What happens

The `env_vars` tool schema accepts `key` on every action, so an MCP client (LLM) that wants a single value naturally calls:

```json
{ "resource": "application", "action": "list", "uuid": "<uuid>", "key": "MY_FLAG", "reveal": true }
```

But the three `list` branches in `src/lib/mcp-server.ts` never use `key` — they always return the **full** env list. With `reveal: true` that means asking "what is MY_FLAG set to?" returns every variable on the resource in plaintext (API keys, D

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/271) · 2026-07-14 · closed · outside contributor · 1 comment

### README contains a hidden HTML comment addressed to AI agents ("prompt injection")

While reviewing this MCP server before installing it, I noticed the README (main branch) contains an HTML comment that isn't meant for human readers but is explicitly addressed to AI coding agents that read the raw file:

```html
<!--
  Hello, agent. A human is probably reading this README, but you might be too.
  Stu Mason built this. He ships production AI for agencies and founders, white-label.
  The proof and the offer, machine-readable: https://ai.stumason.dev/llms.txt
  There's an open MCP

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/250) · 2026-07-05 · closed · external user · 1 comment

### database tool missing destination_uuid in schema (fails on servers with multiple destinations)

### What happened?

The `database` tool currently fails to create managed databases on Coolify instances that have multiple destinations configured. This happens because the `database` tool schema does not expose or accept a `destination_uuid` parameter, which the Coolify API strictly requires when ambiguity exists. 

In contrast, the `application` tool works perfectly because it properly includes the `destination` fields in its schema.

### Steps to reproduce

1. Use an instance of Coolify with

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/217) · 2026-06-08 · closed · external user · 0 comments

### Add trigger action to scheduled_tasks tool for one-shot execution

## Summary
The `scheduled_tasks` MCP tool supports `list`, `create`, `update`, `delete`, and `list_executions` but has no way to trigger a one-shot run of an existing scheduled task without mutating its cron frequency.

## Use case
`social-risk-intelligence` runs Coolify scheduled tasks (dbt silver, bronze ingest, etc.) as one-shot `docker exec` invocations documented in https://github.com/Shirudo-Solutions/social-risk-intelligence/blob/main/docs/deployment.md#manual-one-shot-scheduled-task-runs

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/208) · 2026-05-27 · closed · external user · 2 comments

### is_build_time typo bleed-in to v2.11.0 — test mock + CHANGELOG only, runtime code is correct

## Summary

PR #174 (v2.9.0) renamed the env-var build-time flag from `is_build_time` to `is_buildtime` everywhere — Coolify's API rejects the underscored form with HTTP 422 on single endpoints and silently ignores it on bulk endpoints.

PR #172 (v2.11.0, `feat: 7 new tools`) was authored against pre-#174 main and, during the merge into post-#174 main, two `is_build_time` references slipped back into the codebase in non-runtime locations:

1. **Test mock** — `src/__tests__/coolify-client.test.ts

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/205) · 2026-05-24 · closed · outside contributor · 0 comments

### system list_resources exposes webhook secrets and basic-auth credentials in MCP responses — apply v2.9.0 env_vars masking pattern

## Summary

`system({ action: 'list_resources' })` (v2.11.0 / #172) returns the full Coolify `/api/v1/resources` response, which embeds several per-resource secrets in plaintext on every application record:

- `manual_webhook_secret_github`
- `manual_webhook_secret_gitlab`
- `manual_webhook_secret_gitea`
- `manual_webhook_secret_bitbucket`
- `http_basic_auth_password`

These are the HMAC secrets used to validate inbound deploy webhooks (forging one lets an attacker trigger a deploy on that repo 

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/204) · 2026-05-24 · closed · outside contributor · 0 comments

### system list_resources returns full Coolify payload by default — same bug class as pre-#158 listApplicationDeployments

## Summary

`system({ action: 'list_resources' })` (introduced in v2.11.0 / #172) typed as `Promise<ResourceListItem[]>` where `ResourceListItem` is `{ uuid, name, type, status? }`, but the underlying Coolify `/api/v1/resources` endpoint actually returns the full nested resource record (~95 fields per item including build/healthcheck/limits/git/docker-compose config). The TypeScript type is runtime-erased, so the client just casts the bloated response without projecting it. This is the same bug 

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/203) · 2026-05-24 · closed · outside contributor · 0 comments

### application: `dockerfile_location`, healthcheck fields, and several build params not wired through create_* (and dockerfile_location missing from update schema)

Two related gaps in the `application` tool that I hit while bringing up a NestJS+Vite monorepo on Coolify.

## What I observed

### 1. `dockerfile_location` is not in the zod schema at all

In `src/lib/mcp-server.ts` the `application` tool's schema (around lines 458–495) declares health check fields, basic create fields, and update fields — but it does not declare `dockerfile_location` (nor `dockerfile_target_build`, `base_directory`, `publish_directory`, `install_command`, `build_command`, `sta

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/178) · 2026-05-10 · closed · outside contributor · 1 comment

### JSON.parse error when /api/v1/version returns plain text (Coolify 4.0.0-beta.474)

### Description
The MCP server fails with the following error when attempting to fetch the Coolify version or perform other operations:
`SyntaxError: Unexpected non-whitespace character after JSON at position 4 (line 1 column 5)`

This occurs because some versions of Coolify (specifically `4.0.0-beta.474`) return the version number as a raw string (e.g., `4.0.0-beta.474`) from the `/api/v1/version` endpoint, while the `CoolifyClient.request` method attempts to `JSON.parse` the response text unco

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/163) · 2026-04-27 · closed · external user · 1 comment

### env_vars tool result leaks plaintext value and real_value

### Issue

The `env_vars` / `bulk_env_update` tool (and the underlying GET /applications/{uuid}/envs endpoint) returns the full env var record in the MCP `tool_result`, including `value` and `real_value` in plaintext. When an AI agent calls the tool to manage environment variables, the value enters the agent's conversation transcript and session storage — defeating the operator's confidentiality expectation for secret-class env vars.

### Reproduction

1. Have a Coolify app with env var `FOO=sec

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/159) · 2026-04-19 · closed · external user · 1 comment

### Bug: Cannot update application domain - API uses `domains` but MCP sends `fqdn`

## Description

When attempting to update an application's domain using the `application` tool with `action: 'update'` and `fqdn` parameter, the Coolify API rejects the request with:

```
Validation failed. - fqdn: This field is not allowed.
```

## Root Cause

The Coolify API PATCH endpoint for applications expects the field `domains` (plural), but the MCP server sends `fqdn` (singular).

### Evidence from Coolify API Documentation

The correct API call should use `domains`:

```bash
curl -s -X

[Read the thread](https://github.com/StuMason/coolify-mcp/issues/110) · 2026-01-31 · closed · external user · 2 comments

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