---
title: Komodo
description: Monitoring of Komodo stacks in Pipedash, with live stack state, update history, stack deploys and in-app update logs.
---

The Komodo plugin (`komodo`) treats each Komodo stack as a pipeline. It shows the live state of the stack, lists its Komodo updates as runs, deploys the stack and shows the logs of each update in the app.

## Requirements

The plugin authenticates with a Komodo API key and its secret. Create them in Komodo under Profile, API Keys. Pipedash sends them in the `X-Api-Key` and `X-Api-Secret` headers. The key needs read access to the stacks, which also covers their update logs, and execute access to deploy them. Validation calls `GetVersion` on Komodo Core.

## Configuration

<Screenshot src="provider-komodo" variant="dialog" alt="Add provider dialog with Komodo selected, showing the Komodo Core URL, API Key and API Secret fields and the Skip TLS Verification switch" caption="Komodo asks for the Core URL and an API key with its secret." />

| Key | Type | Required | Default | Description |
|---|---|---|---|---|
| `server_url` | Text | Yes | None | URL of Komodo Core, for example `https://komodo.example.com`. Must start with `http://` or `https://`. The dialog labels it "Komodo Core URL". |
| `api_key` | Text | Yes | None | Komodo API key. The dialog labels it "API Key". |
| `token` | Password | Yes | None | Secret that belongs to the API key. The dialog labels it "API Secret". |
| `insecure` | Boolean | No | `false` | Skips TLS certificate verification, for self-signed certificates. The dialog labels it "Skip TLS Verification". Only `true` turns it on. |

One more key goes in the config table of the TOML file:

- `selected_items`: Comma-separated stack IDs or stack names to monitor.

## Base URL

Komodo has no hosted default, so `server_url` is required. Pipedash trims spaces and a trailing slash, then posts to `{server_url}/read` and `{server_url}/execute`. A blank `server_url`, `api_key` or `token` fails with `Missing <key> in config`.

## Pipeline discovery

Pipedash lists all stacks from Komodo Core and leaves out stacks that are templates. The picker lists them with a description of the form `State: running | Server: prod-1 | Repo: acme/web@main`. The Server part appears only when the stack has a host, and the Repo part only when it has a repository.

- The picker groups stacks by host. The host is the server name, or the swarm name when there is no server name, or the server ID when there is no name at all. Stacks without a host have no group.
- Search matches the stack name and the description text, ignoring case.
- A picker page holds 100 stacks by default.

`selected_items` takes stack IDs or stack names. A stack stays when either one matches an item. Without the key, all stacks stay. An empty `selected_items` string shows no stacks.

The pipeline list shows these columns, in addition to the common ones:

| Column | Shows | Visible by default |
|---|---|---|
| State | Live state of the stack, such as Up, Stopped, Unhealthy or Down | Yes |
| Server | Server or swarm the stack is deployed on | Yes |
| Update | Whether a newer image is available for any service | Yes |
| Git Repository | Git repository the stack is deployed from | No |
| Deployed Commit | Short commit hash that is deployed (repo based stacks) | No |
| Latest Commit | Short commit hash at the head of the branch (repo based stacks) | No |
| Docker Status | Status string reported by docker compose | No |

The repository shown for a stack is `host/stack-name`, or only the stack name when the stack has no host. The branch shows only when the stack has a Git repository and a branch.

The last run of a stack is the start time of its newest Komodo update. Pipedash looks it up for all selected stacks with a shared query and repeats the query for the stacks still missing, so a stack with no recent updates still shows its last run next to busy stacks. A stack with no updates has no last run.

## Run history

Pipedash reads the updates of the stack from Komodo, newest first, page by page, up to the requested limit. A run is one Komodo update:

- The run number is the start time of the update in milliseconds. Two updates with the same start time fail with an error that names the stack and the run number.
- The `operation` column shows the operation Komodo recorded, for example `DeployStack` or `StartStack`.
- The actor is the user name of the update, or its operator when the user name is empty.
- The run link opens `{server_url}/updates/{update_id}` in Komodo. Without an update ID, it opens `{server_url}/stacks/{stack_id}`.
- Run details also load the end time, the duration and the commit hash of the update.

## Trigger parameters

Triggering a pipeline runs `DeployStack` on the stack. The plugin has no trigger parameters. Pipedash shows the notification "Triggered deploy of stack `<stack id>`" and links to the new update.

## Cancel

Cancel is not supported.

## Run logs

The Logs tab of a run shows the logs of the Komodo update in the app. See [Run logs](/docs/features/run-logs).

- **Stages:** Each stage of the update is one job. The job name is the stage name, or `Stage N` when the stage has no name.
- **Lines:** Each stage shows its command, then its output, then its error output. Error output shows as a warning when the stage succeeded and as an error when it failed. Pipedash does not infer errors from the text.
- **Live logs:** While an update is `InProgress`, the last stage is open and its log is partial. When the log grows, Pipedash appends the new lines. When the text before the cursor changed, it reloads the stage.
- **Size:** Pipedash writes the log in chunks of 64 KiB.
- **Timeout:** Loading the logs of an update waits at most 900 seconds.
- **Missing update:** When Komodo no longer has the update, the error is `Update <id> no longer exists`.

## Status page

The plugin has no `status_page_url` key. Komodo shows no status page signal.

## TOML example

```toml
[providers.komodo-prod]
name = "Komodo Prod"
type = "komodo"
token = "${KOMODO_API_SECRET}"
refresh_interval = 30

[providers.komodo-prod.config]
server_url = "https://komodo.example.com"
api_key = "K-xxxxxxxx"
insecure = "false"
selected_items = "web,db"
```

## Status mapping

<Screenshot src="provider-komodo-state" alt="Pipelines page filtered to the Komodo Homelab provider, with stacks labelled Up, Unhealthy, Restarting and Stopped" caption="The status of a stack shows its live state. Unhealthy and Restarting stacks read as Degraded in the filters." />

The pipeline status follows the live state of the stack.

| Pipedash status | Komodo stack state | State label |
|---|---|---|
| `success` | `running` | Up |
| `running` | `deploying` | Deploying |
| `running` | `removing` | Removing |
| `degraded` | `restarting` | Restarting |
| `degraded` | `unhealthy` | Unhealthy |
| `failed` | `dead` | Dead |
| `cancelled` | `paused` | Paused |
| `cancelled` | `stopped` | Stopped |
| `cancelled` | `down` | Down |
| `pending` | `created` | Created |
| `pending` | Any other state | Unknown |

For a stack that is not `running`, the state carries a message. It joins, with `; `, "Project is missing on the host", `Missing files: <list>` and the status strings of the stack, as far as they apply.

Runs follow the update status and the success flag.

| Pipedash status | Komodo update |
|---|---|
| `success` | `Complete` with success |
| `failed` | `Complete` without success |
| `running` | `InProgress` |
| `pending` | `Queued`, and any other status |
| `skipped` | Not produced by this plugin |

Log stages use the same rule: the open stage of a running update is `running`, all other stages are `success` or `failed` by their own success flag.