Linking env0 as a source
This source is currently in beta. It works end to end, but you may still hit rough edges. Let us know if you do.
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.
Contents
The env0 connector syncs your infrastructure-as-code data into PostHog: organizations, projects, teams, templates, organization members, roles and role assignments, environments, deployment history, the steps and resources behind each deployment, drift causes, audit logs, project budgets, and cloud cost at the environment, project, and organization level. You can attribute cloud spend to teams and projects, compare it against budgets, and analyze deployment and drift activity alongside your product data.
Prerequisites
You need an env0 API key. Organization administrators can create an organization API key, or you can use a personal API key scoped to your user. The key needs read access to the organizations you want to sync.
Cost data additionally requires cost monitoring to be configured in env0 for the environments you want cost records for. Project and organization cost roll up the environments below them, so they are empty until cost monitoring is on.
Adding a data source
- In PostHog, go to the Sources tab of the data pipeline section.
- Click + New source and click Link next to this source.
- Enter your credentials (see Configuration below) and click Next.
- 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.
To connect env0, you need an API key ID and an API key secret:
- In env0, go to Organization Settings → API Keys (or create a personal API key from your user settings).
- Create a new API key and copy both the API Key ID and the API Key Secret — the secret is only shown once.
- Paste them into the PostHog source setup form.
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_attimestamp). 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 for a full explanation of how each mode works and how to choose between them.
The deployments table supports incremental sync on startedAt. Deployments can change after they first sync (their status and finish time land when the run completes), so incremental syncs re-pull a one-day window behind the last synced deployment to keep recently-synced rows fresh.
The deployment_resources table supports incremental sync on deployment_started_at, the start time of the deployment that managed the resource. An incremental sync only visits deployments inside that window, which keeps the table cheap to refresh. A full refresh visits every deployment in every environment, so use incremental sync once the first load finishes.
The deployment_steps table works the same way, with incremental sync on deployment_started_at.
The audit_logs table supports incremental sync on timestamp.
The cost tables always sync the last year of daily cost records, so full refresh is the right mode for them. The same goes for drift_causes and organization_users, which env0 returns in full on every request.
Configuration
| Option | Type | Required |
|---|---|---|
API key ID | text | Yes |
API key secret | password | Yes |
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
organizations | An env0 organization the API key can access, including its policies and plan settings. | Full refresh | — | — |
projects | A project groups environments, templates, and team access under an organization. | Full refresh | — | — |
teams | A team of users used to assign roles and project access within an organization. | Full refresh | — | — |
templates | A template (blueprint) defines a deployable environment type: its IaC repository, revision, and tooling. | Full refresh | — | — |
environments | An environment is a deployment managed by env0 — the live instance of a template within a project. | Full refresh | — | — |
deployments | A deployment log records one deploy, destroy, plan, or drift-detection run of an environment. | Incremental, Full refresh | startedAt | — |
environment_costs | Daily cloud cost records for an environment over the last year. Requires cost monitoring to be configured for the environment. | Full refresh | — | — |
project_costs | Daily cloud cost records for a project over the last year, rolling up the costs of the environments it contains. Requires cost monitoring to be configured. | Full refresh | — | — |
organization_costs | Daily cloud cost data points for an organization over the last year, one per date and project. Requires cost monitoring to be configured. | Full refresh | — | — |
organization_users | A user or API key with access to an organization, with the role it holds. Resolves the user ids stamped on deployments, environments, and role assignments. | Full refresh | — | — |
drift_causes | A drift cause detected across an organization: a change that made deployed infrastructure differ from the code, grouped across every environment it affects. | Full refresh | — | — |
deployment_resources | A resource that a deployment created or changed, giving one row per resource behind each deployment. | Incremental, Full refresh | deployment_started_at | — |
deployment_steps | A step within a deployment (such as init, plan, or apply), with its status and timing. | Incremental, Full refresh | deployment_started_at | — |
roles | A role that grants a set of permissions in an organization, either built in or custom. | Full refresh | — | — |
team_role_assignments | The role a team holds on a project. | Full refresh | — | — |
user_role_assignments | The role a user holds on an environment. | Full refresh | — | — |
project_budgets | The cost budget set on a project, with the thresholds that trigger alerts. | Full refresh | — | — |
project_budget_summaries | A project's spend against its budget in the current budget period. | Full refresh | — | — |
audit_logs | An audit log event that records an action on an environment, deployment, project, or template. | Incremental, Full refresh | timestamp | — |
Troubleshooting
Missing cost data: the cost tables only have rows for environments and projects where env0 cost monitoring is configured. Those without it are skipped. The budget tables only have rows for projects with a budget.
Rate limits: env0 limits API usage to 1,000 requests per 60 seconds. Deployments and costs are fetched per environment, and deployment_resources and deployment_steps are fetched per deployment, so accounts with very many environments or deployments may sync these tables slowly. The connector backs off and retries automatically.
Audit logs: reading audit logs needs the VIEW_AUDIT_LOGS permission in env0.
API keys in organization_users: env0 counts organization API keys as users, so they appear in this table alongside people. The app_metadata column marks them. They are included because a deployment can be started by an API key, so leaving them out would make the table an incomplete lookup.
If your sync is failing or data looks wrong, see the Data warehouse troubleshooting guide. If that doesn't help, contact support – we're happy to help.