After migrating from Classic¶

If Tinybird migrated your Workspace for you, it was upgraded in place and kept its name. Your data, Tokens, and Endpoint URLs are unchanged. What changes is how you make changes from now on.

This guide covers what's different in your migrated Workspace and how to work with Forward from this point onwards. For why Forward works this way, see Why migrate to Forward.

What didn't change¶

The migration moved no data and rewrote no URLs. The following survived it untouched:

• Your data. Every Data Source you had, with every row still in it. The migration upgraded the Workspace around your data rather than copying, moving, or reingesting it, so there's nothing to restore or backfill.
• Your Tokens. Same values and same permissions. Nothing to rotate.
• Your Endpoint URLs. /v0/pipes/<pipe>.json answers as it did before, with the same Query Parameters and the same response formats.
• Your ingestion. The Events API and the Data Sources API append operations are unchanged. Producers kept writing during the migration.
• Your Copy Pipes. Still running on the same schedule.

If your application talks to Tinybird over HTTP, it kept working through the migration and you don't need to change anything in it.

What changed¶

Changes go through deployments¶

Your Data Sources, Pipes, and Connections are now described by datafiles: a project you keep in version control and deploy. The Tinybird UI shows you what's running. It's no longer where you change it.

The Classic management endpoints now return a 403:

Adding or modifying data sources to this workspace can only be done via deployments.

You get the same response for Pipes, for Connections, and for the Classic CLI commands that wrapped them. Reading and querying aren't affected.

Your Classic Branches and releases were deleted¶

The migration deletes your Classic Branches and releases. It doesn't carry them over, and you can't recover them. Each has an equivalent in Forward:

• Branches. Forward has its own Cloud Branches, and they're the default way to develop a project. A branch gets its own database, Token namespace, and API surface, and can attach the latest production partition so you develop against real values. Create one with tb branch create, or run tb build from a Git branch and Tinybird creates a matching Cloud Branch for you.
• Releases. Deployments replace them. You prepare each change as a new deployment, check and test it, then promote it. To roll back, promote the previous deployment.

Read and append Token scopes live in your datafiles¶

Your Tokens keep working and keep their values, but the resource scopes DATASOURCES:READ, DATASOURCES:APPEND, and PIPES:READ are now granted by the datafile that defines the resource:

TOKEN "tracker" APPEND

Granting those scopes through the Tokens API returns the same 403 as above. Admin Tokens aren't affected, so you can still create and revoke them as before. See Tokens.

The CLI is a different tool¶

tb is now the Tinybird Forward CLI. It runs a complete Tinybird on your machine, builds and tests your project locally before anything reaches Tinybird Cloud, and deploys it when you're ready. Classic CLI commands don't carry over. See Where your old workflow went.

The CLI isn't the only way to work with Forward. See How you work with Forward from here.

Get your project onto your machine¶

Your Workspace runs in Forward, but the datafiles that describe it aren't on your machine yet. This is the one piece of setup the migration couldn't do for you.

curl https://tinybird.co | sh

tb login --workspace <your-workspace>

mkdir my-tinybird-project && cd my-tinybird-project
tb --cloud pull

git init && git add . && git commit -m "Tinybird project"

tb dev

Make your first change¶

The loop from now on is the same every time, whether you're adding a column or a whole Endpoint:

tb build
tb test
tb --cloud deploy

tb --cloud deploy creates a deployment, checks it against your live Workspace, and promotes it when it's ready.

How you work with Forward from here¶

tb migrate-to-forward writes project_type: "cli" into your tinybird.config.json, so your migrated project defines its resources as datafiles. That's the closest continuation of how you worked in Classic, and everything above assumes it. It isn't the only option:

• Datafiles and the Tinybird CLI. What you have now. Resources live in .datasource, .pipe, and .connection files, and tb builds, tests, and deploys them. See the CLI quickstart.
• TypeScript or Python SDK. Define the same resources in code and use a typed client for ingest and queries. You don't rewrite them by hand: the SDKs convert your existing datafiles for you. See Work with the TypeScript or Python SDK.
• Coding agents. Install the Tinybird agent skills so an agent understands your project structure and workflow:

npx skills add tinybirdco/tinybird-agent-skills

See Agent skills.

Work with the TypeScript or Python SDK¶

If you'd rather define your project in TypeScript or Python than in datafiles, each SDK ships its own tinybird CLI that can convert what you already have. The result is the same Workspace and the same deployments, described in code.

pnpm add @tinybirdco/sdk

npx tinybird init

npx tinybird pull

npx tinybird migrate "tinybird/**/*.datasource" "tinybird/**/*.pipe" "tinybird/**/*.connection"

npx tinybird dev
npx tinybird deploy --check
npx tinybird deploy

For the full command list, see the TypeScript SDK CLI and Python SDK CLI references. For the resource definitions themselves, see TypeScript SDK resources and Python SDK resources.

Where to look when something breaks¶

Forward gives you the same logs in the UI and the CLI. To follow an ingestion issue, a job, or a failing Endpoint from your terminal:

tb --cloud logs

By default this reads tinybird.datasources_ops_log, tinybird.pipe_stats_rt, and tinybird.jobs_log for the last hour. Use --source to target others, such as tinybird.endpoint_errors or tinybird.kafka_ops_log, and --start to widen the window.

The Logs page in Tinybird Cloud shows the same events. For longer investigations, query the Service Data Sources directly, starting with the query log for Endpoint and query behavior.

Where your old workflow went¶

Troubleshooting¶

403: modifications can only be done via deployments¶

Something is still trying to change resources through the Classic API or the Classic CLI, often a deploy script or a continuous integration job. Point it at a deployment instead, following the steps in Get your project onto your machine. See CI/CD.

tb migrate-to-forward reports that it's unavailable¶

Your Workspace is already migrated, so there's nothing left to run:

This command is unavailable for Tinybird Forward workspaces.

A Classic Branch or release is missing¶

The migration deleted them and they can't be recovered. Recreate the Branch as a Cloud Branch from your pulled project:

tb branch create <branch-name> --last-partition

For a release, promote the equivalent deployment instead.

An Endpoint returns a different result than before¶

The migration doesn't change queries or data, so this isn't expected. Contact Tinybird support with your Workspace name before you change anything yourself.

See also¶

• Forward documentation
• Datafiles
• Deployments
• Tokens
• CI/CD
• Test your project
• Tinybird Local
• TypeScript SDK and Python SDK
• Agent skills
• Service Data Sources