--- title: "Branches are GA: data infrastructure for agents" excerpt: "Branches now support Kafka, S3, and GCS connectors, preview deployments from CI, and agentic development workflows. Branches are how agents develop with Tinybird." authors: "Jorge Sancha" categories: "Product updates" createdOn: "2026-02-24 12:00:00" publishedOn: "2026-02-24 12:00:00" updatedOn: "2026-02-24 12:00:00" status: "published" --- When we shipped [branches in beta](https://www.tinybird.co/blog/introducing-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](https://www.tinybird.co/docs/forward/test-and-deploy/branches#test-with-connector-data). Kafka, S3, and GCS connectors work in branches. 2. [Preview deployments from CI](https://www.tinybird.co/docs/forward/test-and-deploy/deployments/cicd#preview-deployments). One command creates an ephemeral branch per PR. 3. [Agentic development workflows](https://www.tinybird.co/docs/forward/get-started/quick-start-coding-agents). Branches as sandboxes for coding agents. ## Connectors in branches The `--with-connections` flag creates connectors alongside your branch: ```bash 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](https://www.tinybird.co/docs/forward/dev-reference/commands/tb-secret), 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. ```bash # 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: ```bash 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{% sup %}®{% /sup %} 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](https://www.tinybird.co/blog/tinybird-now-in-typescript), you've seen the `preview` command. Here's what it means for branches. ```bash npx tinybird preview ``` This creates a branch named `tmp_ci_`, 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: ```yaml 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](https://github.com/tinybirdco/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](https://www.tinybird.co/blog/tinybird-now-in-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](https://www.tinybird.co/docs/forward/test-and-deploy/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](https://www.tinybird.co/docs/forward/test-and-deploy/branches) only. Classic has its own [branches implementation](https://www.tinybird.co/docs/classic/work-with-data/organize-your-work/branches). - Work both in the cloud and in [Tinybird Local](https://www.tinybird.co/docs/forward/test-and-deploy/local), with the same isolation and ephemeral behavior. - Automatically mapped to your git branch via [`tinybird dev`](https://www.tinybird.co/docs/forward/dev-reference/commands/typescript-sdk-cli) 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](https://www.tinybird.co/docs/forward/test-and-deploy/branches), or jump straight into the [quickstart guides](https://www.tinybird.co/docs/forward/get-started). We want to see what you build with this. If you have feedback, tell us in the `#feedback` channel of our [Slack community](https://www.tinybird.co/community) or [send us an email](mailto:support@tinybird.co).