Linking Railway as a source
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 Railway connector syncs your Railway projects, services, environments, deployments, project members, volumes, usage data, metrics, and activity events into PostHog. This is useful for analyzing deployment activity, resource consumption, and failure rates alongside your product data.
Prerequisites
You need a Railway account with access to the projects you want to sync, and permission to create an API token for your account or workspace.
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.
You need a Railway API token:
- Go to your Railway account settings.
- Create a new token. To sync projects from a specific workspace, select that workspace when creating the token. A token created without a workspace is an account token and syncs all projects your account can access.
- Back in PostHog, paste the token into the
API tokenfield and click Next.
Project tokens are not supported. They are scoped to a single environment and can't list your projects.
Railway rate limits API requests per plan (as low as 100 requests/hour on the Free plan), so a large initial sync can take a while.
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 following tables support incremental syncs:
deployments: each run pulls deployments created since the last sync, and also re-syncs the previous day so recent status changes (for example a deployment moving fromDEPLOYINGtoSUCCESS) are picked up. Status changes on older deployments are only reflected on a full refresh.deployment_events: syncs events for deployments created since the last sync, with a 24-hour lookback for deployments that were still in progress.usage: daily resource usage per project and service. The first sync pulls the last 90 days.metrics: hourly resource metric samples per service and environment. The first sync pulls the last 30 days (Railway only retains about 30 days of metrics).
All other tables (projects, services, environments, project_members, volumes, events, and estimated_usage) sync as full refreshes.
Configuration
| Option | Type | Required |
|---|---|---|
API token | password | Yes |
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
projects | A Railway project — the top-level container that groups services, environments, deployments, and volumes. | Full refresh | — | — |
services | A service within a Railway project — a deployable unit such as an app, database, or worker. | Full refresh | — | — |
environments | An environment within a Railway project (e.g. production, staging, or an ephemeral PR environment). | Full refresh | — | — |
deployments | Incremental syncs page newest-first and stop at the last-seen createdAt. A 24h lookback re-pulls recent deployments so late status changes are picked up; older status changes only refresh on a full refresh. | Incremental, Full refresh | createdAt | — |
project_members | A member of a Railway project and their role. | Full refresh | — | — |
volumes | A persistent storage volume attached to a Railway project. | Full refresh | — | — |
events | An entry in a Railway project's activity feed, recording an action taken on an object in the project. | Full refresh | — | — |
deployment_events | Incremental syncs read events only for deployments created since the last-seen createdAt, with a 24h lookback for deployments that were still in progress. | Incremental, Full refresh | createdAt | — |
usage | Daily resource usage per project and service, over the last 90 days on the first sync. | Incremental, Full refresh | date | — |
estimated_usage | Estimated usage per project at the end of the current billing period. | Full refresh | — | — |
metrics | Hourly resource metrics per service and environment. Railway keeps about 30 days of metrics. | Incremental, Full refresh | timestamp | — |
service_instances | The configuration of a Railway service in one environment: how it builds, starts, scales, and restarts. | Full refresh | — | — |
volume_instances | A Railway volume in one environment, mounted on a service. | Full refresh | — | — |
volume_instance_backups | A backup of a Railway volume instance. | Full refresh | — | — |
deployment_triggers | A rule that deploys a Railway service when a connected repository branch changes. | Full refresh | — | — |
workspaces | A Railway workspace — the team or account that owns projects and is billed for them. | Full refresh | — | — |
Troubleshooting
"Your Railway API token is invalid, revoked, or lacks access": create a new account or workspace token in your Railway account settings and reconnect. Make sure you didn't paste a project token.
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.