Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/io-github-stumason-coolify/issues.md or /mcp/io-github-stumason-coolify/issues.json, or Pod over MCP.

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.

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. 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 · 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 · 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:

Steps to Reproduce

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 · 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:

<!--
  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).