Private pre-alpha

Git-native data pipelines, run from the CLI.

Braidplane is a developer-first, ETL-first operating layer for data teams that want Git-native pipeline authoring and CLI-first operation. The CLI controls the workflow; Braidplane runs it and keeps every run, schedule, source checkpoint, contract, and validation result in a readable operational trail.

Private pre-alpha. Access is invitation-only. Do not connect Braidplane to production systems, use it for production workloads, or provide sensitive data.
Contact us about early access View pipeline walkthrough
CLI-first operation Validate, deploy, run, schedule, and inspect data pipelines without making the UI the source of truth.
Spec repositories now Use GitHub, Git, or GitLab repositories for pipeline specs; richer provider automation stays on the roadmap.
Simple integration Bring ETL definitions close to the repos and workflows teams already use.

High-level ETL walkthrough: source, transform, sink.

The first walkthrough keeps the shape generic: connected systems read, native SQL transforms, and target systems receive validated output.

High-level walkthrough / source -> transform -> sink
Source
Read from connected systems

Postgres is the walkthrough source; other catalogue examples depend on connector capability metadata.

optional output contract
Transform
Transform with native SQL

Native SQL handles the transform step today, with more transform options coming.

Validate spec bp pipeline validate
Run native SQL source rows -> mapped output
More options additional transform modes coming
optional input contract
Sink
Write into the target system

S3 is the walkthrough sink; write targets depend on connector capability metadata.

Connector capabilities decide which systems can read and write. HubSpot is shown source-side; sink support follows connector capability metadata.

Source capability

Postgres is the walkthrough source; connector metadata decides which systems can read.

Source capability Postgres is the walkthrough source; connector metadata decides which systems can read.
Native SQL transform Transform logic runs in native SQL today, with more transform options coming as the pipeline model expands.
Sink capability S3 is the walkthrough sink; connector metadata decides which systems can write.
CLI recording

Recorded walkthrough of the runnable pipeline.

The capture creates the pipeline from the committed spec, syncs logical refs from the spec, validates the bound runtime target, deploys the pinned spec hash, starts a run, and checks the written S3 output.

Full UI walkthrough coming soon. This recording shows the CLI path end to end.

local cast 00:00
Loading recorded CLI walkthrough...
00:00
Loading local .cast
Pipeline spec

See how the pipeline is defined.

Two source reads, one sql_v1 join transform, one JSON write, with optional contracts around the transform.

  • SourceOrders and customers come from logical source references.
  • TransformNative SQL maps the two row sets into joined order records.
  • SinkEach run writes a scoped JSON object to the target system.
Open the pipeline spec
metadata:   slug: golden-path-joined-orders  name: Golden Path Joined Orderssteps:   - kind: query    slug: fetch-paid-orders    name: Fetch paid orders    query:       data_source_ref: golden-path-orders-postgres      operation_type: sql      operation_ref: golden-path-orders      output_contract:         name: golden-path-paid-orders        representation: rows        fields:           - name: order_id            type: string            required: true          - name: customer_slug            type: string            required: true          - name: order_total_cents            type: integer            required: true          - name: discount_cents            type: integer            required: true          - name: net_total_cents            type: integer            required: true          - name: placed_at_utc            type: string            required: true  - kind: query    slug: fetch-active-customers    name: Fetch active customers    query:       data_source_ref: golden-path-customers-postgres      operation_type: sql      operation_ref: golden-path-customers      output_contract:         name: golden-path-active-customers        representation: rows        fields:           - name: customer_slug            type: string            required: true          - name: customer_name            type: string            required: true          - name: customer_segment            type: string            required: true          - name: region            type: string            required: true  - kind: transform    slug: join-orders-customers    name: Join orders to active customers    transform:       inputs:         orders: fetch-paid-orders        customers: fetch-active-customers      input_contract:         name: golden-path-join-inputs        representation: rows        fields:           - name: orders.order_id            type: string            required: true          - name: orders.customer_slug            type: string            required: true          - name: orders.order_total_cents            type: integer            required: true          - name: orders.discount_cents            type: integer            required: true          - name: orders.net_total_cents            type: integer            required: true          - name: orders.placed_at_utc            type: string            required: true          - name: customers.customer_slug            type: string            required: true          - name: customers.customer_name            type: string            required: true          - name: customers.customer_segment            type: string            required: true          - name: customers.region            type: string            required: true      sql: |        SELECT          orders.order_id AS order_id,          orders.customer_slug AS customer_slug,          customers.customer_name AS customer_name,          customers.customer_segment AS customer_segment,          customers.region AS region,          orders.order_total_cents AS order_total_cents,          orders.discount_cents AS discount_cents,          orders.net_total_cents AS net_total_cents,          CAST(orders.net_total_cents AS DOUBLE) / 100 AS net_total_amount,          orders.placed_at_utc AS placed_at_utc        FROM orders        JOIN customers ON customers.customer_slug = orders.customer_slug        ORDER BY placed_at_utc, order_id      output_kind: rows      output_contract:         name: golden-path-joined-orders        representation: rows        fields:           - name: order_id            type: string            required: true          - name: customer_slug            type: string            required: true          - name: customer_name            type: string            required: true          - name: customer_segment            type: string            required: true          - name: region            type: string            required: true          - name: order_total_cents            type: integer            required: true          - name: discount_cents            type: integer            required: true          - name: net_total_cents            type: integer            required: true          - name: net_total_amount            type: number            required: true          - name: placed_at_utc            type: string            required: true  - kind: sink    slug: write-joined-orders    name: Write joined orders to S3    sink:       idempotency_class: naturally_idempotent      input: join-orders-customers      input_contract:         name: golden-path-joined-orders-s3-input        representation: rows        fields:           - name: order_id            type: string            required: true          - name: customer_slug            type: string            required: true          - name: customer_name            type: string            required: true          - name: customer_segment            type: string            required: true          - name: region            type: string            required: true          - name: order_total_cents            type: integer            required: true          - name: discount_cents            type: integer            required: true          - name: net_total_cents            type: integer            required: true          - name: net_total_amount            type: number            required: true          - name: placed_at_utc            type: string            required: true      data_source_ref: golden-path-s3-sink      operation_type: s3      operation_ref: golden-path-s3-write-joined-orders      config:         key: runs/{{runtime.sink_replay_identity}}/joined-orders.json        format: json        content_type: application/json        metadata:           source: braidplane-golden-path          run: "{{runtime.run_slug}}"        overwrite: true
Data source refs Portable logical source and sink references keep credentials out of the spec.
Operation refs Source and sink steps call saved connector operations by slug.
Transform contracts Input and output contracts make each data edge explicit.
Run slug Run-scoped output keys keep artifacts tied to execution evidence.
The recording above and this spec describe the same joined-orders pipeline.
What Braidplane is

A Git-first operating layer for ETL data pipelines.

Braidplane gives teams a standard runtime for repeatable ETL workflows: connectors, contracts, transforms, deployments, runs, retries, diagnostics, and auditability. Custom code still has a place; routine data movement should not default to a bespoke runtime to package, patch, deploy, and debug.

CLI-first for the people doing the work Reviewable specs, typed contracts, inspectable runs No per-pipeline runtime ownership for routine ETL

Spec-first declarative ETL

Define sources, native SQL transforms, sinks, contracts, schedules, and runs in pipeline specs. YAML and JSON work today, CUE support is pending, and routine ETL runs through reviewed specs and a managed runtime boundary.

specYAML / JSON / CUE pendingruntimemanaged boundaryCLI gatevalidate before deploy

Connected business systems

Register databases, warehouses, APIs, SaaS systems, files, Git, S3, and even HTTP operations with credential safety and readiness checks.

setuptest + introspectruntimesource / sink opssafetycapability checks

Environment-aware deploys

Promote the same pipeline version across dev, staging, and prod while each environment resolves its own bindings.

deployspec hash pinnedtargetenvironment bindingstriggermanual or scheduled

Operable run history

Inspect what ran, why it ran, what moved, what failed, and whether a run can be replayed or retried.

sourcerow + cursor summarycheckpointwatermark / cursorreplayspec hash + logs
Current pre-alpha surface What Braidplane already includes CLI operation, machine access, incrementals, events, alerts, notifications, contracts, and deployment evidence are already part of the current surface.

For technical evaluators who want the fuller scope, this is the current pre-alpha surface behind the walkthrough.

Access and automation
CLI workflowAPI keysPATsMachine integration
Pipeline runtime
DeploysRunsSchedulesIncrementalsRetries
Operational evidence
EventsRun historyValidationContractsTimelines
Operator loop
NotificationsAlertsReplay safetyFailure diagnostics
Integration model
Git specsData-source bindingsSource opsSink opsConnection tests
Early-access conversations

Talk to us about your operational data workflow.

Interested in early access? Email us. We will use the information you provide only to answer your request. Contacting us does not create an account, subscribe you to marketing, or guarantee access.

No public launch date yet. Pre-alpha access remains guided.