> AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt

# Linking Octopus Deploy as a source - Docs

Copy page

# Linking Octopus Deploy as a source - Docs

![](https://res.cloudinary.com/dmukukwp6/image/upload/texture_tan_9608fcca70)

![](https://res.cloudinary.com/dmukukwp6/image/upload/texture_tan_dark_a92b0e022d)

Let AI connect your sources for you

Skip the manual setup — run this in your project and the wizard auto-detects your databases and APIs and connects them to PostHog.

`npx @posthog/wizard warehouse`

[Learn more](/wizard.md)

![PostHog Wizard hedgehog](https://res.cloudinary.com/dmukukwp6/image/upload/wizard_3f8bb7a240.png)

![](https://res.cloudinary.com/dmukukwp6/image/upload/wizard_3f8bb7a240.png)Let AI connect your sources for you

**Alpha release**

This source is currently in **alpha**. The interface and available tables may change.

The Octopus Deploy connector syncs your deployment data – deployments, releases, projects, environments, tasks, and audit events – into PostHog. This is useful for analyzing deployment frequency, change failure rate, and recovery time per project and environment.

## Prerequisites

You need an Octopus Deploy account (Octopus Cloud or self-hosted) and an API key. Self-hosted servers must be reachable from the internet over HTTPS. The API key inherits your user's permissions, so its user needs read access to the spaces you want to sync.

## Adding a data source

1.  In PostHog, go to the [Sources tab](https://app.posthog.com/data-management/sources) of the data pipeline section.
2.  Click **\+ New source** and click **Link** next to this source.
3.  Enter your credentials (see [Configuration](#configuration) below) and click **Next**.
4.  Select the tables you want to sync, choose a sync method and frequency, then click **Import**.

Once the syncs are complete, you can start querying this data in PostHog.

When linking Octopus Deploy, you'll need:

-   **Octopus Deploy URL** – your Octopus Cloud URL (like `https://your-org.octopus.app`) or your self-hosted server's public URL.
-   **API key** – created in the Octopus web portal under **your profile > My API Keys**. Click **New API key**, give it a purpose, and copy the generated key (it starts with `API-`).

The connector discovers every space your API key can see and syncs each space-scoped table (projects, deployments, releases, and so on) across all of them, with a `SpaceId` column identifying the space each row belongs to.

## Sync modes

Each table can be synced in one of several modes, depending on what the source supports:

-   **Webhook** (when available) – the source pushes changes to PostHog in real time. Fastest freshness, lowest ongoing cost, and the only mode that reliably captures updates and deletes.
-   **Incremental** – only new or updated rows are synced on each run, using a cursor field (such as an `updated_at` timestamp). Cheaper than a full refresh, but deletes aren't captured.
-   **Append only** – new rows are appended using a cursor field; existing rows are never updated. Ideal for immutable, append-only tables like event logs.
-   **Full refresh** – the whole table is reloaded on every sync. Use it when a table has no reliable cursor or when you need deletions reflected.

See [sync methods](/docs/cdp/sources.md#sync-methods) for a full explanation of how each mode works and how to choose between them.

Tasks and audit events support incremental syncs. Incremental task syncs filter on completion date, so a task only appears once it finishes. Deployments and releases don't expose a server-side date filter in the Octopus API, so they always sync with a full refresh.

## Configuration

| Option | Type | Required |
| --- | --- | --- |
| Octopus Deploy URL | text | Yes |
| API key | password | Yes |

## Supported tables

| Table | Description | Sync method | Incremental field | Primary key |
| --- | --- | --- | --- | --- |
| spaces | Spaces partition an Octopus Deploy instance; every other resource belongs to exactly one space. | Full refresh | — | — |
| projects | A project is a deployable application or component, holding its deployment process, variables, and releases. | Full refresh | — | — |
| project_groups | Project groups organize related projects within a space. | Full refresh | — | — |
| environments | Environments are the stages deployments are promoted through, such as Development, Test, and Production. | Full refresh | — | — |
| channels | Channels let a project run multiple release cadences (for example default and hotfix) with their own version rules and lifecycles. | Full refresh | — | — |
| tenants | Tenants model per-customer or per-region deployments of the same project (multi-tenancy). | Full refresh | — | — |
| machines | Machines are deployment targets (VMs, Kubernetes clusters, cloud targets) that deployments run against. | Full refresh | — | — |
| releases | A release is a versioned snapshot of a project's deployment process, variables, and packages, ready to be deployed. | Full refresh | — | — |
| deployments | A deployment is one execution of a release into an environment (optionally for a tenant) — the core record for deployment frequency and DORA metrics. | Full refresh | — | — |
| tasks | Incremental syncs filter on completion date, so tasks only appear once they finish | Incremental, Full refresh | CompletedTime | — |
| events | Audit events record every significant action on the instance (deployments queued, releases created, settings changed). | Incremental, Full refresh | Occurred | — |

## Troubleshooting

If your sync is failing or data looks wrong, see the [Data warehouse troubleshooting guide](/docs/data-warehouse/troubleshooting.md). If that doesn't help, [contact support](https://us.posthog.com/#panel=support%3Asupport%3Adata_warehouse%3A%3Atrue) – we're happy to help.

### Was this page useful?

HelpfulCould be better