Resource

Cloud & Infrastructure Database Developer Tools

v0.1.4

Last updated Nov 6, 2026

An n8n community node for managing Coolify applications, deployments, databases, services, and infrastructure through workflows.

390 Weekly Downloads

1,033 Monthly Downloads

View on NPM GitHub Repository

Included Nodes

Resource

Description

n8n-nodes-coolify

A community-built Coolify integration for n8n.

Automate Coolify workflows, from application management to preview deployments.

n8n is a fair-code licensed workflow automation platform.

@sinehypernova-0718/n8n-nodes-coolify brings Coolify API operations into n8n workflows, letting you work with Coolify resources through the workflow editor instead of manually constructing API requests.

✨ Features

Coolify API v1 integration — interact with the Coolify REST API directly from n8n workflows.
API token authentication — authorize API requests with a Coolify API token sent as a bearer token.
Native n8n interface — select resources, operations, and parameters through the workflow editor.
Application management — 42 operations on the Application resource, including creation, lifecycle, environment variables, storages, backups, destinations, and tags.
Audit events — list the team audit events on the Audit Event resource, paginated and filterable.
Cloud init scripts — create, read, update, and delete the reusable cloud init scripts of the team on the Cloud Init Script resource.
Cloud tokens — list, inspect, create, rename, delete, and validate the cloud provider tokens of the team on the Cloud Token resource.
Preview deployments — open, list, inspect, and delete preview deployments for pull requests.
Rate-limit aware transport — one shared transport that honours the server’s rate-limit headers and retries only requests that are safe to repeat.

📁 Repository Structure

n8n-nodes-coolify/
├── credentials/
│   └── CoolifyApi.credentials.ts
├── nodes/
│   └── Coolify/
│       ├── Coolify.node.ts
│       ├── Coolify.node.json
│       ├── descriptions/
│       │   ├── Application/
│       │   │   ├── ApplicationDescription.ts
│       │   │   ├── applicationCreateFields.ts
│       │   │   ├── applicationFieldProperties.ts
│       │   │   ├── applicationUpdateFields.ts
│       │   │   ├── storageBackupScheduleFields.ts
│       │   │   └── index.ts
│       │   ├── AuditEvent/
│       │   ├── CloudInitScript/
│       │   ├── CloudToken/
│       │   ├── Database/
│       │   └── index.ts
│       ├── requests/
│       │   ├── application/
│       │   │   ├── .ts
│       │   │   └── index.ts
│       │   ├── auditEvent/
│       │   ├── cloudInitScript/
│       │   ├── cloudToken/
│       │   ├── database/
│       │   ├── types.ts
│       │   └── index.ts
│       └── shared/
│           ├── apiRequest.ts
│           └── rateLimit.ts
├── icons/
│   └── coolify.svg
├── package.json
├── README.md
├── CHANGELOG.md
└── LICENSE.md

Architecture

credentials/ — defines the Coolify API credential used to authenticate requests.
descriptions/ — contains the resource and operation definitions displayed in the n8n editor. Its index.ts explicitly exports the descriptions consumed by the main node.
requests// — contains the request builders of a resource; the node implements the application, auditEvent, cloudInitScript, cloudToken and database resources.
requests//.ts — keeps individual API request builders in separate operation-specific modules, such as list.ts, get.ts, createPublic.ts, and update.ts.
Resource index.ts files — explicitly export the request builders belonging to each resource.
requests/index.ts — re-exports the resource-level barrels, providing a single import entry point for request modules.
shared/apiRequest.ts — the single authenticated transport. It shapes the request, attaches the bearer token, applies the retry policy, and converts failures into n8n errors.
shared/rateLimit.ts — the rate-limit and retry policy, kept free of n8n-workflow imports so it can be unit-tested in isolation.
Coolify.node.ts — defines the n8n node and coordinates operation execution, authenticated HTTP requests, retries, and error handling.

The architecture separates editor-facing configuration from API request construction and execution. Resource descriptions define the available operations and parameters, while request modules build operation-specific requests. The main node remains responsible for invoking authenticated HTTP requests through n8n’s credential-aware helpers and handling execution results.

Explicit exports keep imports predictable and avoid unnecessary wildcard exports. The resource-specific modules remain independent, while the barrel files provide convenient entry points without introducing another execution layer.

Additional resources can follow the same structure, with their own descriptions and operation-specific request modules. This allows the integration to expand without requiring a redesign of the existing architecture.

📦 Installation

Install the package through your n8n instance using the community node installation interface.

1. Open your n8n instance.
2. Navigate to Settings → Community Nodes.
3. Select Install.
4. Enter the package name @sinehypernova-0718/n8n-nodes-coolify.
5. Review and accept the installation confirmation.
6. Once installation completes, open a workflow and search for the Coolify node.

For detailed instructions, see the n8n community nodes installation guide.

> Note: The package name entered during installation must match the name under which this project is published to npm (@sinehypernova-0718/n8n-nodes-coolify). Community node installation availability also depends on your n8n deployment configuration and administrator policies.

⚙️ Operations

The Coolify node exposes the supported Coolify API operations through n8n’s resource and operation selectors. The available operations and parameters depend on the installed package version.

Application

The node exposes five resources — Application, with 42 operations, Audit Event, with the List operation, Cloud Init Script, with 5 operations, Cloud Token, with 6 operations, and Database, with 17 operations. The other Coolify resources (services, servers, projects, deployments) are not exposed yet.

Every operation is sent through the shared transport, so the rate limit and retry policy described below applies to all of them: reads are retried when the server reports a transient failure, writes are never repeated automatically.

#### Reading applications

#### Environment variables

> Note: Update Env and Update Envs (Bulk) send the flags ispreview, isliteral, ismultiline and isshown_once with the values the API applies by default, so a flag that is not part of the request is reset. Send every flag that the variable should keep.

#### Storages

#### Backups

> Note: Delete Storage Backup Schedule removes the backup archives that already exist with the schedule, locally as well as in S3.

#### Destinations

#### Preview deployments

> Note: Update Preview Domains replaces the domains instead of merging them: a domain that is not part of the request is removed, and a Docker Compose service that is not listed loses its domain. Removing every domain is a separate, explicit switch.

#### Logs

> Note: both log operations need a token with the read:sensitive or the root ability.

#### Tags

#### Creating applications

> Note: the creation operations can queue a deployment right away. That needs a token with the deploy ability, and the server needs a destination it can host the application on.

#### Lifecycle

> Note: Migrate stops the application and only transfers the volume data when both servers are managed by Coolify, so the application has to be deployed again after it completes. Rollback needs a token with the deploy ability. Delete removes the configuration and the volumes of the application as well, the switches of the operation control that.

Audit Event

#### Reading audit events

> Note: Return All follows the Coolify paginator and returns every matching event as an individual item, up to a safety limit of 100,000 events; Limit returns at most the requested number. Each page is validated before it is appended, and malformed or inconsistent pagination metadata fails the request instead of returning a partial result. Only team admins and owners can view audit events, a token without that access is expected to receive HTTP 403. Actor e-mail, token, metadata, changes, IP address and user agent are returned only for tokens with the read:sensitive or the root ability.

Cloud Init Script

#### Managing cloud init scripts

> Note: the list endpoint is not paginated, it returns every script of the team. Only team admins and owners can use the resource, a token without that access is expected to receive HTTP 403. The content of a script is returned only for a token with the read:sensitive or the root ability that also satisfies the team authorization policy of Coolify, in practice the caller has to be an admin or owner of the team; a token ability on its own does not make the content visible. Update changes only the fields that are filled in, an emptied field keeps the value the script has, the API has no way to clear a field and rejects a blank value with HTTP 422. The API stores the content of a script without its leading and trailing whitespace. Delete removes the script permanently.

Cloud Token

#### Managing cloud provider tokens

> Note: only team admins and owners can use the resource, a token without that access is expected to receive HTTP 403. The Coolify API accepts the cloud providers hetzner, digitalocean, vultr and hostinger. The token value is a secret: it is validated against the provider before it is stored, and the API does not return it afterwards. Update changes only the name, the token value itself cannot be changed. A token that is used by a server cannot be deleted.

Database

The Database resource exposes the standalone databases of a Coolify team through 17 operations. Service databases — the databases nested inside a service — are a different resource and are not part of this one.

#### Reading databases

> Note: List returns every database of the team in one array; the endpoint is not paginated. Passwords, connection URLs and init scripts are returned only for a token with the read:sensitive or the root ability, and only when the team authorization policy allows it. Get Logs needs the same ability and is answered with HTTP 400 while the database has no running container.

#### Creating databases

> Note: every creation operation needs the project UUID and the server UUID, and at least one of the environment name and the environment UUID. The destination UUID is required when the server has more than one destination. The API generates the credentials a request leaves out, but the creation endpoint returns the UUID of the new database; the generated passwords are returned by Get, and only for a token with the read:sensitive or the root ability. Instant Deploy needs a token with the deploy ability. Create (SQLite) requires Coolify v4.4.0 or later and publishes no public access fields, so its operation does not offer them. The MongoDB creation schema does not publish the root password or the initial database, so set them with Update after the database exists.

> Note: the six configuration fields (postgresconf, mysqlconf, mariadbconf, mongoconf, redisconf and keydbconf) are entered as plain text. The node Base64-encodes the exact UTF-8 content of the field before it sends the request, because the API expects it that way, so the configuration keeps its line breaks and whitespace.

> Note: a database is made public by switching Public on and supplying a Public Port between 1024 and 65535. The node rejects a public database without a valid port before the request is sent, because Coolify silently keeps the database private when the port is missing.

#### Lifecycle

> Note: Start, Stop and Restart queue the operation on the server: the API accepts the request and returns a message, it does not wait for the database to reach the new state. Starting a running database and stopping a stopped database are answered with HTTP 400, a concurrent start, restart or import with HTTP 409, and a missing prerequisite with HTTP 422. The three operations are never retried automatically.

> Note: Update sends only the settings the user changed. A boolean is a three-state control (Unchanged, Enabled, Disabled) and a number is sent only when a value is entered, so an untouched setting keeps its current value. Enabling Public requires a public port in the same request, the same rule as creation. The operation renders one settings collection per engine, because the request does not carry the type of the database; a field that belongs to another engine is answered with HTTP 422. An empty description field keeps the current description, the node has no way to clear it. Three fields of the published update schema (redactallenvvaluesinlogs, includecoolifydefaultvariables and islogdrain_enabled) are rejected by the API with HTTP 422 and are not offered.

> Note: Delete queues the deletion and removes the database from the API immediately. The four switches mirror the query flags of the endpoint and all default to true; they decide whether the configurations, the volumes, the connected networks and the Docker cleanup are removed. Deleting the volumes destroys the stored data, and the deletion cannot be undone.

Operation parameters, filters, and available fields vary by endpoint. Refer to the operation descriptions in the n8n editor and the Coolify API documentation for endpoint-specific requirements.

This list describes the resources currently implemented in the integration. Additional resources and operations can be introduced in future releases.

⏱️ Rate limits and retries

All Coolify API calls go through one shared transport (nodes/Coolify/shared/apiRequest.ts) that applies the retry policy of nodes/Coolify/shared/rateLimit.ts. The policy follows the Coolify rate-limit documentation.

The limit is never hardcoded. The documented default is 200 requests per minute, but a self-hosted instance can change it with the APIRATELIMIT environment variable, so the server’s response headers are the only source of truth.
Only requests that are safe to repeat are retried. Reads (GET, HEAD, OPTIONS) are retried on 408, 429, transient 5xx responses and transport failures. Writes are never retried automatically: a 429 alone is no proof that a write can be repeated, because Coolify also answers 429 when a deployment queue or an upstream provider is busy. A write is only retried when the operation explicitly declares that a repeat is harmless.
The wait comes from the server. Retry-After (seconds) is honoured exactly, X-RateLimit-Reset (unix timestamp) is the fallback, and an exponential backoff with random jitter is used when the response carries neither. A server-mandated wait longer than the internal maximum wait of 60 seconds fails the request instead of retrying early.
At most three retries per request, and never in parallel.
Permanent failures (400, 401, 403, 404, 409, 422) are surfaced immediately, with the Coolify message, the status code and the response body preserved.

The retry limits and timeouts are internal constants. There are no node-level options for them.

🔐 Credentials

The Coolify node authenticates against the Coolify REST API with an API token, sent as a Bearer token in the Authorization header.

Prerequisites

Before configuring the credential, you need:

A Coolify instance — either Coolify Cloud or your own self-hosted installation (see the Compatibility section for the supported Coolify version).
An API token created in Coolify under Keys & Tokens → API Tokens, scoped to the team you want to work with. The token carries the permissions selected at creation time (read, write, root), so create the least privileged token that covers your workflow. The token needs the read permission — a deploy-only token cannot be tested, because the credential test reads the team bound to the token.
On self-hosted instances, API access must be enabled by an administrator, and the caller must match the IP allowlist when one is configured.

Configure the credential

Create a Coolify API credential in n8n and supply the values required by the credential configuration.

| Setting | Value |
| ———— | ———————————————————————————————————————————————————————————————————————————————————————- |
| Base URL | Base URL of the Coolify API, including the /api/v1 path. Use https://app.coolify.io/api/v1 for Coolify Cloud, or the URL of your own instance (for example https://coolify.example.com/api/v1). A trailing slash is tolerated; the /api/v1 suffix is required. |
| Access Token | The API token created in Coolify. It is sent as Authorization: Bearer . |

The credential test calls GET /team against the configured base URL — the endpoint that returns the team bound to the token — so it verifies the token against the same instance your workflows will use. The test is read-only, and it reports whether a failure was caused by the token (401), by permissions, API access or the IP allowlist (403), or by a base URL that does not point at the API (404).

Permissions and access

The configured token covers the read and write permissions used by the current implementation. Individual operations may still require a specific ability, team access, or an additional API permission.

Deployment, rollback, preview deployment and database lifecycle operations need a token with the deploy ability: that covers application deployments, database start, stop, restart and delete, and a database creation or update that is asked to start or restart the database or to change its public access. The log operations, including Get Logs of a database, need the read:sensitive or the root ability.

Keep your token private. Never commit credentials to the repository or include tokens in issue reports, screenshots, or logs.

🧩 Compatibility

This package is designed for n8n’s community node ecosystem and uses the n8n node API.

Integration type: n8n community node.
Implementation language: TypeScript.
API: Coolify API v1.
Coolify version: Depends on the target Coolify instance’s API version. The credential test uses GET /team, the canonical endpoint for “the team bound to the token” in the Coolify OpenAPI specification; the credential documents this endpoint as available from Coolify 4.3.0. The request contracts of the operations were aligned against the Coolify OpenAPI specification of a recent Coolify 4.x release, and some operations send fields that only recent releases publish, so on an older instance those fields may be rejected. Whether a given endpoint or field is accepted therefore depends on the version of Coolify you run; consult the Coolify API documentation for your instance and do not assume every field is supported by every stable release. The database creation contract and the database update exclusions were verified against the Coolify v4.5.1 OpenAPI specification and controller; Create (SQLite), which is absent from v4.3.0, requires Coolify v4.4.0 or later. The exact minimum Coolify version supported by every other operation is not verified in this repository and needs review.
Authentication: Coolify API token (Bearer), with the read permission.
Package distribution: npm — end users install the published package with the n8n community nodes interface, and npm remains the registry the package is published to.
Development package manager: pnpm — the repository is developed, built, and published with pnpm, pinned through the packageManager field in package.json and pnpm-lock.yaml.

The package declares its n8n node metadata and entry points in package.json. Compatibility depends on the n8n version, the available n8n-workflow APIs, and the package’s dependencies.

The 0.1.x releases are pre-1.0 releases. Operation coverage and compatibility may evolve as the integration develops.

🚀 Usage

After installing the node and configuring the API credential, you can incorporate Coolify API operations into your n8n workflows.

Basic workflow setup

1. Create a workflow in n8n.
2. Add the Coolify node.
3. Select your Coolify API credential.
4. Choose the resource you want to work with, such as Application.
5. Select the required operation.
6. Configure its parameters, identifiers, and other required fields.
7. Connect the node to the other nodes in your workflow.
8. Execute the workflow and inspect the returned data.

Troubleshooting

If an operation fails:

Verify that the Coolify credential is configured with the right base URL and a valid token.
Confirm that the token has the permission the operation needs (read, write, deploy, read:sensitive, or root).
Check that the supplied application, database and other resource UUIDs exist and are accessible to the team bound to the token.
On self-hosted instances, verify that API access is enabled and that the caller matches the IP allowlist.
Verify required fields and supported parameter values.
Review the error returned by n8n and consult the relevant Coolify API documentation.

For general workflow guidance, see the n8n Try it out documentation.

🛠️ Development

Requirements

Node.js (v22 or higher) and pnpm

– Linux/Mac/WSL: Install via nvm
– Windows: Follow Microsoft’s NodeJS guide

git
Corepack (optional) — pnpm 12.4.2 is pinned in package.json via the packageManager field

corepack enable   # optional, if you do not have pnpm installed globally
pnpm install

> [!NOTE]
> The @n8n/node-cli is included as a dev dependency and is installed automatically when you run pnpm install. The CLI includes n8n for local development, so you do not need to install n8n globally.

Available scripts

| Script | Description |
| ———————— | ————————————————————————————————————————————— |
| pnpm run dev | Start n8n with your node and watch for changes (runs n8n-node dev) |
| pnpm run build | Compile TypeScript to JavaScript for production (runs n8n-node build) |
| pnpm run build:watch | Build in watch mode (auto-rebuild on changes) |
| pnpm run lint | Check your code for errors and style issues (runs n8n-node lint) |
| pnpm run lint:fix | Automatically fix linting issues when possible (runs n8n-node lint --fix) |
| pnpm run release:local | Create a release locally: bump the version, update the changelog, commit, tag (vX.Y.Z), and push — this triggers the publish workflow |
| pnpm run release | The publish entry point used by the GitHub Actions publish workflow: lints, builds, and publishes to npm with provenance |

> Note: pnpm run release is what CI runs. Locally, use pnpm run release:local to create the tag, because @n8n/node-cli pins release-it’s branch check to main while this repository develops on master. The repository configuration in .release-it.json handles the master branch, the vX.Y.Z tag format, and the changelog generation.

Release process

Releases are published by GitHub Actions, never from a local machine, so that every published version carries an npm provenance attestation (required by n8n for verified community nodes).

1. Make sure master is up to date and the working tree is clean.
2. Run pnpm run release:local. It lints, builds, prompts for a version bump, updates CHANGELOG.md, commits, creates a vX.Y.Z tag, and pushes it.
3. The push of the tag triggers .github/workflows/publish.yml, which checks out the tag, verifies that the tag matches package.json, checks that the version is not already on npm, and publishes it to npm with provenance.

> Note: the release creates a GitHub release as well, which needs a GITHUBTOKEN with repo scope in your environment (for example export GITHUBTOKEN=$(gh auth token)).
> Without it, release-it falls back to opening the GitHub release page in the browser.

Required repository configuration

A repository secret named NPM_TOKEN holding an npm granular access token with read and write publish permission for @sinehypernova-0718/n8n-nodes-coolify.

Alternatively, configure npm Trusted Publishing for this repository and the publish.yml workflow, and leave NPM_TOKEN unset.

The default branch must be master; CI and the publish workflow are configured for it.
On self-hosted Coolify instances, an administrator must enable API access for the token’s team.

🔗 Resources

Coolify API documentation — API endpoints, request parameters, and responses.
Coolify API authorization — how the API authenticates a request.
Coolify API tokens — creating and scoping API tokens.
Coolify rate limits — the documented request budget and the response headers it is sent with.
Coolify API — Authenticated Team (GET /team) — the endpoint the credential test uses.
n8n community nodes documentation — community node discovery and installation.
n8n community nodes installation guide — installation instructions.
n8n documentation — workflow creation and node configuration.
GitHub repository — source code, issues, and contributions.

📝 Version history

v0.1.4

Adds resource locators for selecting Coolify entities in the node editor and automatically paginates Audit Event results, returning each event as an individual item. The release also improves parameter handling for n8n v2 and groups the audit event list filters.

v0.1.3

Adds the Database resource, introducing 17 operations for managing standalone Coolify databases:

List — Retrieve the standalone databases of the team.
Get — Retrieve a single database by UUID.
Get Logs — Retrieve the container logs of a database.
Create (PostgreSQL/MySQL/MariaDB/MongoDB/Redis/Clickhouse/DragonFly/KeyDB/SQLite) — Create a database on a server of the project.
Update — Update the settings of a database by UUID.
Start, Stop, Restart — Queue a lifecycle operation on a database.
Delete — Delete a database and its volumes, configurations, networks and Docker images.

The release also repairs the Coolify node metadata alias list and updates the engineering playbook to reflect the repository’s test-free policy.

v0.1.2

Adds the Cloud Token resource, introducing six operations for managing Coolify cloud provider tokens:

List — Retrieve cloud tokens.
Get — Retrieve a specific cloud token.
Create — Register a new cloud token.
Update — Update an existing cloud token.
Delete — Remove a cloud token.
Validate — Check whether a cloud token can authenticate with its configured cloud provider.

v0.1.1

Initial pre-1.0 release of the Coolify integration for n8n.

Introduces Application, Audit Event, and Cloud Init Script resources.
Adds Coolify API token authentication for API requests.
Includes application creation, lifecycle, environment variables, storages, backups, destinations, tags, preview deployments, and logs operations.
Includes audit event listing with pagination.
Includes the cloud init script operations.
Includes rate-limit aware transport and operation-specific request handling where implemented.
This release establishes the initial integration structure, with further Coolify resources and operations available for future development.

📄 License

This project is licensed under the MIT License.

—

This is an independent community project and is not an official Coolify or n8n product.

Included Nodes

Description

n8n-nodes-coolify

✨ Features

📁 Repository Structure

Architecture

📦 Installation

⚙️ Operations

Application

Audit Event

Cloud Init Script

Cloud Token

Database

⏱️ Rate limits and retries

🔐 Credentials

Prerequisites

Configure the credential

Permissions and access

🧩 Compatibility

🚀 Usage

Basic workflow setup

Troubleshooting

🛠️ Development

Requirements

Available scripts

Release process

Required repository configuration

🔗 Resources

📝 Version history

v0.1.4

v0.1.3

v0.1.2

v0.1.1

📄 License

More in Cloud & Infrastructure

Apify

Hostinger API

Labels

AWS SQS Trigger

Helipod

Vertex AI

MinIo

AncoreMate