When we shipped branches in beta, connectors didn't work. If your data came from Kafka or S3, branches couldn't replicate your production environment. Preview deployments weren't there either.

That's all fixed.

We didn't build all of this just to close a feature gap. We built it because branches are how agents develop with Tinybird. An agent that can create an isolated environment, define datasources and endpoints, ingest real data through connectors, test the results, and iterate. All without touching production. That's the workflow branches enable now.

Here's what's new:

1. Connector support. Kafka, S3, and GCS connectors work in branches.
2. Preview deployments from CI. One command creates an ephemeral branch per PR.
3. Agentic development workflows. Branches as sandboxes for coding agents.

Connectors in branches

The --with-connections flag creates connectors alongside your branch:

tb --cloud branch create my_feature --last-partition --with-connections

This auto-creates your Kafka and S3/GCS connectors in the branch. By default, branches inherit your production secrets, so connectors point at the same Kafka cluster or S3 bucket as production. You can override any secret in the branch to point at a staging or development resource instead.

Kafka

Kafka connections start stopped by default. This is intentional. You don't want a new branch immediately consuming from production topics.

# Start consuming when you're ready to test with live data
tb --branch my_feature datasource start my_events

# Stop when done
tb --branch my_feature datasource stop my_events

When you start a Kafka connection in a branch, it creates a new consumer group with a {group_id}_{branch_name} suffix. It skips any pending messages and starts consuming from the current offset. Each branch has its own consumer group, so there's no interference with production or other branches.

S3 and GCS

S3 and GCS connectors support sample import in branches. You can import files into the branch to test with realistic data, and re-import the same files when iterating on schema changes:

tb --branch my_feature datasource sample my_s3_datasource --wait

Combining with production data

The --last-partition flag brings the latest modified partition from each production datasource into your branch. This is a zero-copy operation, made possible by the storage/compute separation in Tinybird's ClickHouse^® fork: data isn't duplicated, both production and the branch read from the same underlying cloud storage (not available in upstream ClickHouse). The branch gets its own isolated snapshot: you can mutate, truncate, or re-import without side effects on production.

Combined with --with-connections, you get:

• Historical data from the last production partition
• Live streaming data from Kafka (once started)
• Batch data from S3/GCS sample imports

Preview deployments

If you've read the TypeScript SDK announcement, you've seen the preview command. Here's what it means for branches.

npx tinybird preview

This creates a branch named tmp_ci_<git_branch>, builds your resources, and deploys them. If the branch already exists, it recreates it fresh. One command, one isolated environment per PR. When the PR closes, clean up with tb --cloud branch rm.

Every PR gets its own Tinybird environment

Add one step to your CI:

on: pull_request

jobs:
  preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx tinybird preview
        env:
          TINYBIRD_TOKEN: ${{ secrets.TINYBIRD_TOKEN }}

Each pull request gets its own branch with its own endpoints, data, and tokens. Reviewers can query the branch endpoints directly to validate changes before merging.

Automatic token resolution

The SDK detects preview environments (Vercel, GitHub Actions, GitLab CI, CircleCI, Azure Pipelines, Bitbucket Pipelines) and resolves the correct branch token automatically. No extra configuration beyond your existing TINYBIRD_TOKEN.

This means your frontend preview deployment on Vercel automatically queries the matching Tinybird branch. No code changes, no environment variables to wire up per PR.

A concrete example

Take the web-analytics-starter-kit. A developer opens a PR to add a new metric, say, unique visitors by country. The CI runs npx tinybird preview, which creates a branch with the new endpoint. The Vercel preview deployment picks up the branch token and renders the new chart with real data. The reviewer sees the actual result, not just the code diff.

Agentic development

When your Tinybird resources are TypeScript, coding agents can read your data model, write new endpoints, and deploy them. But deploying directly to production is a non-starter for an agent. Or anyone, really.

Branches give agents a sandbox. The agent creates a branch, defines datasources and endpoints in TypeScript, and syncs to the branch with npx tinybird dev. From there it can query the endpoints, check the response, iterate if something's wrong, and leave the branch for a human to review when it's done.

Tell your agent: "Create an endpoint that returns top 10 pages by unique visitors for the last 7 days, grouped by country."

The agent reads your datasource schema from TypeScript, writes the endpoint definition, deploys it to a branch, and verifies the response shape and data. If something's off, it iterates, all within the branch. Production is never touched.

Why cloud branches

Tinybird Local supports branches too, with the same isolation and ephemeral behavior. If you're running Cursor or Claude Code on your laptop, local branches work great.

But background agents (Codex, Devin, remote Claude Code sessions) run on servers without Docker. They need an environment they can reach over the network, with real production data and real connectors attached. Cloud branches give them that: zero infrastructure to manage, real Kafka streams and S3 data, and a URL anyone on the team can open to review the result.

Branches take seconds to create and seconds to delete (tb --cloud branch rm). The agent can spin up and tear down as many as it needs. The human reviews the final result.

What to keep in mind

• Forward workspaces only. Classic has its own branches implementation.
• Work both in the cloud and in Tinybird Local, with the same isolation and ephemeral behavior.
• Automatically mapped to your git branch via tinybird dev or npx tinybird preview in CI.
• Branches currently share compute with your production environment. Dedicated branch infrastructure is on the roadmap.

Get started

Read the branches documentation, or jump straight into the quickstart guides.

We want to see what you build with this. If you have feedback, tell us in the #feedback channel of our Slack community or send us an email.