How I Use the Coolify MCP Server to Manage Production from Claude Code

I spend most of my day in a terminal. My editor is open, Claude Code is running, and I'm building things. The last thing I want is to context-switch to a browser dashboard every time I need to check on a server, deploy something, or figure out why a service is misbehaving.

That's why I built the Coolify MCP server. It connects Claude Code directly to the Coolify API and gives me over 35 tools for managing production infrastructure without leaving my terminal. I use it every day. My own site — stumason.dev — runs on Coolify, self-hosted, and this MCP server is how I manage it.

What is the Coolify MCP Server

Coolify is an open source, self-hostable platform for deploying applications, databases, and services. Think of it as a self-hosted alternative to Vercel, Heroku, or Railway. You run it on your own servers and get a web dashboard for managing everything.

The Coolify MCP server is an open source npm package that exposes Coolify's API as MCP tools. Once installed, Claude Code can talk directly to your Coolify instance — listing servers, deploying apps, reading logs, managing environment variables, running database backups, and diagnosing issues.

It currently has 35+ tools covering:

• Server management — list servers, check resources, validate connections, view domains
• Application lifecycle — list, view, create, update, deploy, and control applications
• Database operations — list, view, manage, and back up databases
• Service management — list, view, and control services
• Environment variables — read, update, and bulk-update env vars
• Deployment tracking — list deployments, view logs, trigger deploys
• Diagnostics — diagnose apps, diagnose servers, find issues across your infrastructure
• Project organisation — manage projects, environments, and private keys

The package is listed on PulseMCP as a community MCP server and the source is on GitHub at stumason/coolify-mcp.

Setting It Up

Installation takes about thirty seconds. You need your Coolify instance URL and an API token.

First, generate an API token from your Coolify dashboard under Settings > API Tokens. Then add the MCP server to Claude Code:

claude mcp add coolify -e COOLIFY_API_TOKEN=your-token-here -e COOLIFY_BASE_URL=https://coolify.yourdomain.com -- npx -y coolify-mcp

That's it. Restart Claude Code and you'll see the Coolify tools available. You can verify by asking Claude to list your servers — if it comes back with real data, you're connected.

If you prefer project-level configuration, add it to your .mcp.json:

{
  "mcpServers": {
    "coolify": {
      "command": "npx",
      "args": ["-y", "coolify-mcp"],
      "env": {
        "COOLIFY_API_TOKEN": "your-token-here",
        "COOLIFY_BASE_URL": "https://coolify.yourdomain.com"
      }
    }
  }
}

Real Workflows I Use Daily

This isn't a theoretical tool. I use it constantly. Here are the actual workflows that come up most often.

Checking Server Health

The first thing I do most mornings is a quick health check. I'll ask Claude something like:

Check the health of my production server and show me resource usage

Claude calls list_servers to find my servers, then server_resources to pull CPU, memory, and disk usage. I get back a clean summary without opening a single browser tab.

When something feels off — a site is slow, or I've seen high response times — I go deeper:

Diagnose my production server and check for any issues

This triggers the diagnose_server tool, which runs a comprehensive check across the server and reports back on connectivity, Docker status, resource pressure, and any services that look unhealthy.

Deploying Applications

Deployments are where this really shines. Instead of navigating to the Coolify dashboard, finding the right application, and clicking deploy, I just say:

Deploy my stumason-dev application

Claude uses list_applications to find the app, then calls deploy with the right UUID. I get back deployment status and can follow up with:

Show me the deployment logs for that deploy

The list_deployments tool grabs recent deployments and deployment fetches the specific logs. I can see build output, container startup, and any errors — all inline in my terminal.

For more careful deploys, I'll ask Claude to check the current state first:

What version is currently deployed for stumason-dev, and what's the git source?

The get_application tool returns detailed info including the git repository, branch, commit, and current status. I can verify I'm deploying the right thing before triggering it.

Reading Logs When Something Breaks

This is the workflow that saves me the most time. Something goes wrong in production — maybe a user reports an error, or I notice a 500 in my monitoring. Instead of SSHing into a server and tailing Docker logs, I ask:

Show me the last 100 lines of application logs for stumason-dev

The application_logs tool pulls container logs directly. I can scan for errors, exceptions, stack traces — whatever I need. And because I'm in Claude Code, I can immediately follow up:

I see a database connection error in those logs. Check the database status and show me the env vars for the database connection

Claude chains list_databases to find the database, get_database to check its health, and env_vars to pull the connection config. In thirty seconds I've gone from "something broke" to "the DATABASE_URL has a typo in the hostname." That kind of investigation used to mean three browser tabs and a terminal window.

Managing Environment Variables

Env var management is deceptively time-consuming in a dashboard. Find the app, open settings, scroll to environment variables, edit, save, redeploy. With the MCP server:

Show me all environment variables for stumason-dev

The env_vars tool lists them all. When I need to update one:

Update the CACHE_TTL environment variable to 3600 for stumason-dev

For bigger changes — like updating config across multiple apps in a project — I use the bulk update:

Update these env vars for all apps in the stumason project:
- APP_ENV=production
- LOG_LEVEL=warning
- CACHE_STORE=redis

The bulk_env_update tool handles this in one shot, and I can follow up with redeploy_project to roll everything out.

Database Backups

I run backups before any significant deployment or database migration. The workflow is simple:

Create a backup of the production database and show me recent backup history

The database_backups tool handles both listing existing backups and triggering new ones. I can verify a backup completed successfully before running a risky migration, all without leaving my editor.

Diagnosing Issues

The diagnostic tools are some of the most useful in the entire server. When I'm not sure what's wrong, I don't have to guess where to look:

Diagnose the stumason-dev application and tell me if anything looks wrong

The diagnose_app tool checks application health, container status, resource usage, recent deployment state, and configuration. It's like having a checklist that runs itself.

For broader issues:

Find any issues across my entire infrastructure

The find_issues tool scans across servers, applications, databases, and services looking for problems — containers that aren't running, servers with high resource usage, failed deployments, unreachable services. It's the "is everything okay?" button I always wanted.

The Tools That Save Me the Most Time

After months of daily use, a few tools stand out as disproportionately valuable:

diagnose_app — When something's wrong and I don't know where to start, this is always my first call. It checks everything and gives me a starting point. Nine times out of ten, the issue is right there in the diagnostic output.

application_logs — Reading logs without SSH is transformative. The speed difference between "open a terminal, SSH in, find the container, docker logs" versus "show me the logs" is enormous. And having Claude interpret the logs immediately is even better.

env_vars and bulk_env_update — Environment variable management sounds boring until you're doing it across six applications. Bulk update changed this from a fifteen-minute clicking exercise to a ten-second conversation.

find_issues — The infrastructure-wide health check. I run this a few times a week just to make sure nothing's quietly broken. It catches things I wouldn't notice until they became real problems.

deploy — One sentence to deploy. No clicking through dashboards. Combined with list_deployments to verify the deploy succeeded, it's a complete deployment workflow in two messages.

What I'd Build Next

The MCP server already covers the vast majority of what I need day to day, but there are a few things I'd like to add:

• Deployment webhooks and notifications — getting real-time deployment status pushed back rather than polling for it
• Resource trend analysis — historical CPU and memory data to spot patterns, not just current snapshots
• Automated rollback workflows — detecting a failed deployment and automatically rolling back to the previous good state
• Multi-server deployment coordination — deploying across a fleet of servers with proper ordering and health checks between each

The beauty of having this as an MCP server is that adding new capabilities is straightforward. Each tool is a focused function that talks to the Coolify API. The pattern is established, so new tools follow the same structure.

Getting Started

If you're running Coolify and using Claude Code, this is genuinely one of the most useful MCP servers you can add. Here's the quick start:

1. Get the package:

npm install -g coolify-mcp

1. Add to Claude Code:

claude mcp add coolify \
  -e COOLIFY_API_TOKEN=your-token \
  -e COOLIFY_BASE_URL=https://coolify.yourdomain.com \
  -- npx -y coolify-mcp

1. Restart Claude Code and start managing your infrastructure:

List all my servers and show me their current status

The source code is on GitHub at stumason/coolify-mcp. Issues, PRs, and feature requests are welcome. If you're managing Coolify infrastructure and want to do it from your terminal, give it a try — it's changed how I work.