Skip to main content
PARIXDocs

What is Parix?

What Parix is, who it is for, and what the managed TigerBeetle platform includes today.

Parix is a managed TigerBeetle platform for teams building systems that need exact balances, ordered transfers, and durable transaction history without running TigerBeetle infrastructure directly.

TigerBeetle remains the database. Parix adds the hosted control plane around it: database creation, provider routing, secure gateway access, organization auth, API keys, billing checks, cluster workflows, observability, backups, restore eligibility, and Change Data Capture configuration.

The current implementation is built around a Cloudflare-hosted control plane and AWS or GCP data-plane deployments. The product surface lives in the React Router web app under apps/web-app; provider routing is handled by the app-dispatcher Worker and the provider-local gateway path.

Parix features

The fastest way to understand Parix is to look at the product surfaces that are already implemented in this repository.

Managed TigerBeetle databases

Parix provisions TigerBeetle-backed databases from the dashboard and the versioned API.

The dashboard create flow supports:

  • new empty TigerBeetle databases
  • imported .tigerbeetle data files
  • AWS and GCP provider selections from the create catalog
  • region, topology, storage tier, storage size, and cluster-size choices
  • Stripe billing readiness checks before provisioning starts

The API exposes the same core create catalog and database lifecycle shape through /api/v1/catalog/create, /api/v1/databases, and /api/v1/databases/{databaseId}. Create and delete operations require db:write; read operations require db:read.

Private gateway access

Parix does not expose raw TigerBeetle replicas as a broad public network surface. Requests go through the Parix gateway path:

  1. A client calls the Cloudflare entrypoint.
  2. Parix authenticates the request with an API key or first-party OAuth access token.
  3. app-dispatcher resolves the database provider and region.
  4. Workers VPC bindings and tunnel services route traffic to the provider-local tb-gateway.
  5. tb-gateway validates the request and performs the TigerBeetle operation.

The public TigerBeetle operation API is currently HTTP-based at /api/v1/databases/{databaseId}/tb/{operation}. It supports:

  • query_accounts
  • query_transfers
  • create_accounts
  • create_transfers
  • lookup_accounts
  • lookup_transfers
  • get_account_balances
  • get_account_transfers

Read operations require db:read. Write operations require db:write.

Dashboard workflows

The Parix dashboard is the main control-plane interface today. It includes database detail pages, the connect flow, API key management, logs, metrics, backups, and cluster configuration.

The cluster section is split into dedicated tabs:

  • Instances
  • Storage
  • Parameters
  • Change Data Capture
  • Changes

Those pages queue workflows instead of mutating provider infrastructure directly from the browser. For example, instance and storage changes resolve catalog selections, compare them with the active database profile, enqueue the appropriate workflow, and surface durable outcomes in the Changes tab.

Cluster shape and storage

Parix models cluster shape with catalog data rather than one-off form values. The control plane tracks topology, node count, storage tier, storage size, CPU, memory, and monthly price on the database profile.

Current workflow behavior is provider-aware:

  • GCP topology and storage changes can use backup-driven migration when data must be preserved.
  • AWS topology and storage changes are blocked where restore-backed migration is not implemented for that path.
  • Local NVMe clusters block post-create topology, size, and storage changes in v1.

Observability

Parix includes dashboard observability for provider host metrics, TigerBeetle-native metrics, and runtime logs.

The metrics page supports AWS and GCP database profiles and includes fixed windows such as 15m, 1h, 12h, 24h, and 7d. It can show aggregate or replica-scoped views, gateway request metrics, and TigerBeetle replica health, sync, cache, and request timing series.

The logs page reads from the Collector Durable Object path. It provides time-window presets, a histogram for narrowing into spikes, incremental loading, and live polling when the selected range is close to the present.

Backups and restores

Parix supports manual backup creation through the dashboard for active database profiles on supported deployment paths. Backup jobs and replica artifacts are tracked in control-plane state, and backup retention is organization-configurable with a 7-day default.

Restore is wired as an in-place workflow when a backup is eligible. Eligibility currently checks the active profile, provider support, completed backup status, complete replica artifacts, matching region, node count, CPU, memory, storage, network mode, development mode, and TigerBeetle version. Restore support is currently limited to active GCP deployments and AWS local NVMe deployments.

Point-in-time recovery is not a shipped product surface yet.

Change Data Capture

Parix models CDC configuration in the control plane. The current modes are:

  • disabled
  • direct_amqp
  • managed_amqp

Direct AMQP mirrors TigerBeetle-native AMQP settings. Managed AMQP stores platform-managed delivery configuration, including webhook destinations, destination authentication, and active destination validation. CDC changes are queued through workflows and later reflected through durable control-plane state.

API and integration surface

The versioned API is implemented with @hono/zod-openapi under apps/web-app/workers/routes/api. The current API surface includes:

  • session context
  • create-catalog discovery
  • database list, create, get, and delete
  • TigerBeetle operation execution
  • generated OpenAPI at /api/v1/openapi.json

For application code, the normal authentication path is an API key in x-api-key or Authorization: Bearer .... API keys can be scoped to all databases or one specific database.

Current support boundaries

These docs describe the implementation in this repository, not an aspirational roadmap. Today you should assume:

  • provider work centers on AWS and GCP
  • TigerBeetle access is gateway-first
  • broad raw TigerBeetle network access is not the product contract
  • cross-region replication and multi-region HA are out of scope
  • point-in-time recovery is not available
  • there is no apps/cli package in this checkout, so the dashboard and HTTP API are the current product integration surfaces here

Start with the Quickstart to create a database, connect with an API key, and run your first TigerBeetle operation.