We are excited to announce the Insights Dashboard — a built-in analytics view that gives you full visibility into your Bucketeer usage, right from the console.
PostgreSQL is now supported as a data warehouse (DWH) option in Bucketeer 2.2.0, alongside BigQuery and MySQL. We added it because Postgres supports TimescaleDB, which fits OLAP-style event and analytics workloads well.
As AI-powered software development rapidly proliferates, new challenges have emerged that traditional development and deployment processes cannot adequately address. The unpredictable nature of AI models, high costs, and potential risks necessitate more cautious and controllable release strategies.
In this context, OpenFeature, a standardization project for feature flags, is playing an increasingly important role in the safe and efficient deployment of AI products.
Are you a Quality Assurance (QA) engineer struggling with these daily challenges?
It works in development, but you can't test it in staging right away because there's no data.
The combination patterns for each feature are too complex to test everything.
In today's world, where development cycles are sped up by Generative AI, the role of QA is more important than ever. Yet, preparing test environments and testing complex feature combinations takes a lot of time and can slow down development.
What if you could freely switch specific features ON or OFF without changing any application code or environments?
This article will show you concrete ways to use Bucketeer, a feature flag and A/B testing platform, to solve the problems QA engineers face and drastically improve test quality and efficiency.
Recently, we have released the Bucketeer Lite to easily run Bucketeer anywhere with Docker Compose. However, the standard Bucketeer provides a more robust and scalable solution for more demanding purposes, e.g. withstand high traffic, large data volume, multi-region deployment, etc.
In this blog post, we will share the idea how we deploy Bucketeer in Google Cloud using Terraform, Helm and PipeCD. Terraform scripts will be shared in the future.
This is the general structure of our infrastructure in Google Cloud and also represents the Terraform modules that we will share in the future. Let's break down each component!
We create a VPC network with public and private networks. Cloud DNS managed zone is used for public DNS to allow access to Bucketeer web and API services from the internet.
Private DNS is used to create communication between Redis and Cloud SQL with the Bucketeer services in the GKE cluster.
GKE cluster is where Bucketeer services run, linked to the VPC network with subnet configured. For more information about Bucketeer Kubernetes configuration and helm chart, we can check in the Bucketeer repository
Secrets for TLS certificate, OAUTH keys, Service Token, Go Server SDK API Key are also created and stored in here.
Google Redis MemoryStore is deployed as instance or cluster, depending on the environment (development or production) or traffic needs. We use private IP to connect to the GKE cluster.
MySQL instance is deployed for Bucketeer to store its data. Private IP is also used to connect to the GKE cluster.
Google Pub/Sub infrastructure is maintained by Google, we just need to create topics for Bucketeer services to use.
Google BigQuery infrastructure is also maintained by Google, data table is created for Bucketeer to store analytics data.
After setting up the infrastructure and prepare the secrets, we can deploy Bucketeer using Helm. In this step, we need to replace values in the Helm chart to match our infrastructure configurations.
To automate the deployment, we install piped in the GKE cluster to deploy Bucketeer. To learn more about how to use PipeCD, please check the PipeCD documentation.
That's the high-level idea and components of how Bucketeer is deployed in Google Cloud, it's more complex than Bucketeer Lite but provides a more robust and scalable solution.
We will share the Terraform scripts, detailed steps to generate certificates, setup secrets, piped configuration, ingress, ... as well as some notes and mistake we can learn from in the future. stay tuned!
We're excited to announce Bucketeer 2.0, a major update to our feature flag management platform. This release is all about usability, speed, and flexibility — making it easier than ever to manage flags, collaborate with your team, and roll out changes with confidence.
Over the past months, we've listened closely to feedback from the community. Many of you wanted a smoother workflow, faster flag management, and more intuitive tools. With Bucketeer 2.0, we've reimagined the console from the ground up to deliver just that.
Bucketeer has always been a powerful open-source platform for feature flag management and A/B testing.
But until now, self-hosting Bucketeer required Google Cloud services like BigQuery and Pub/Sub. That meant local testing was difficult, and teams who preferred to host outside GCP had limited options.
With Bucketeer Lite, we're changing that.
Now you can run Bucketeer in just a few minutes using Docker Compose, with Redis Streams for pub/sub and MySQL for data storage.
No GCP required — just Docker, MySQL, and Redis.
The Bucketeer Demo Site provides a simple way to try out Bucketeer in a sandbox environment. This guide walks through how to access the demo site, create a demo organization, and start using the system.
All the coolest Bucketeer features are available and ready to explore. So let's hop in and see how to get started!
Feature flags have revolutionized how we deploy and test software, but managing them often requires context switching between multiple tools and interfaces. Today, we're excited to announce the Bucketeer MCP Server, a Model Context Protocol implementation that brings comprehensive feature flag management directly into your AI-assisted development workflow.
Improving a website or application inevitably involves releasing new features and changing designs. However, every change carries inherent risks: "Will this break something?" or "Will this negatively impact the user experience?"
This article explains how to use a powerful technique called feature flags to manage these risks and effectively run A/B tests that are both safe and data-driven, complete with practical examples.