Tinybird Local: Build with data on your machine

We launched Tinybird Local, a free Docker image that replicates the Tinybird cloud service for local development. Pull the Docker image, and you'll have a local version of Tinybird on your machine.

Tinybird Local is useful when you want to:

• Build and test your app or service locally before deploying.
• Make Tinybird calls in your CI/CD pipeline with external deps.
• Run things locally just because you prefer to work that way.

Using the image

To get started, run the following command:

Once the container is running, you can get an authentication token for the default workspace:

Then you can use that token with the API or Tinybird CLI.

What's included

Tinybird Local includes all the essential features to test a data project locally:

• Create pipes and data sources
• Ingest data using the standard APIs, including the Data Sources API and the Events API
• Token management
• Workspace management

Tinybird Local does not include:

• Connectors (like Kafka, BigQuery, Snowflake, and so on)
• Scheduled copy jobs 
• A browser UI
• Sinks

We’ve focused on the basics for simplicity; we will evaluate additional features based on your feedback. If you have feedback, please let us know in the Tinybird Slack community. We'll prioritize the features you ask for.

For more information about Tinybird Local, read the docs.

Updating the image

The image is updated with our continuous delivery system, so every time we deploy a new Tinybird version in our cloud, a new image is generated and pushed to Docker Hub. Take that into account when working with it.

Please note this image is not meant for production usage (in fact, the license forbids it). You’ll likely experience issues if you use it with more than a few megabytes of data.

Director’s cut

We were honestly a bit hesitant to release this. It's not uncommon to have external dependencies during build if you work with managed services, so maybe we could have gotten by without it.

But, after talking with our users we realized there are some really good reasons to create a local container:

1. It eliminates networking. When you can build local, you can build from anywhere you can take your machine. That's valuable, especially in remote work cultures. It's also faster. No roundtrips means faster builds.
2. No external deps in CI. External services increase pipeline flakiness, which reduces development velocity. Tinybird exists to improve developer velocity, so having a container for CI fits our philosophy.
3. "Infinite" environments. It's much easier to create (and kill) environments with a Docker container, so you can more quickly test and iterate without impacting production.

At the end of the day, we (as developers ourselves) know that building local just "feels good" - it's what developers want. That’s why companies like LocalStack are successful, and that's why we released Tinybird Local.

The Tinybird Local Docker image prioritizes usability over strict adherence to Docker best practices. It runs multiple services inside a single container, which doesn't align with conventional Docker practices.

We could have created a docker-compose-like system. In fact, we use docker-compose internally for our local development. We feel this approach is simpler and avoids potential conflicts with your dev environment, making it easier to use overall. Let us know if you think differently.