Growthbook Release Notes

Running an experiment gives you an answer to a question. Running thousands of experiments gives you a lot of answers, but also something much more valuable: a body of evidence about how your product, users, and business actually behave.

The problem is that this knowledge is surprisingly difficult to use in practice.

A PM working on onboarding might not know that another team tested a similar idea six months ago. An engineer building a new checkout flow might not know which patterns have consistently helped conversion on other parts of the product. Even when people remember that relevant experiments exist, reading through dozens or hundreds of them to find the important patterns is rarely practical.

Today, we are launching Learnings in GrowthBook to help solve this problem.

Learnings let teams capture what they have learned across experiments, user research, and other sources of evidence, then make that knowledge available to both people and AI agents when they are building something new.

Learnings: Turn experiment learnings into a living knowledge library.

Experiments produce more than winners

Experiments produce more than winners

The most obvious output of an experiment is a decision. Those decisions create incremental gains, and over time those gains compound.

But there is another output from experimentation that is easier to overlook: knowledge. Every experiment produces it, including the ones that lose or move nothing at all.

You might learn that:

• Showing pricing earlier in the funnel consistently improves qualified conversions.
• Simplifying onboarding helps new users but hurts activation for experienced users.
• Social proof matters on acquisition pages but has little effect inside the product.
• Asking users to configure everything upfront creates friction, while progressive configuration performs better.

None of these conclusions necessarily come from a single experiment. They emerge after five, twenty, or a hundred experiments, once somebody notices the pattern.

This is where an experimentation program becomes more powerful than a sequence of isolated A/B tests: individual tests give you answers, but the program gives you a model of how your users behave. You are gradually identifying patterns and putting your learnings to work for future growth.

Learnings compound your experimentation program

Learnings compound your experimentation program

If an experiment improves conversion by 2%, that improvement can continue generating value for as long as the change remains in the product (novelty effects aside). That’s real compounding, and it’s the return most programs measure.

But that win only compounds one thing: a metric. A learning acts on something different: the quality of the next decision.

Imagine your team learns through repeated experiments that users perform better when complex actions are introduced progressively rather than all at once. That insight might influence your next onboarding flow. Then your settings experience. Then a new AI feature. Then the way an agent designs a workflow six months later.

It doesn’t stay with one team either. An insight can travel to whoever picks your onboarding feature or settings work next. Your experimentation program can widen, since everyone starts from organizational knowledge.

The value is not limited to the experiment that produced the learning. It changes the starting point of future work. Instead of beginning every project from first principles, your team starts with a set of evidence-backed assumptions about what tends to work (and what doesn’t).

Learnings in GrowthBook

Learnings in GrowthBook

GrowthBook Learnings are designed to capture this organizational knowledge explicitly.

A learning can reference evidence from multiple experiments, rather than being tied to the result of a single test. That matters because many useful conclusions only become visible across a collection of experiments.

The New Learning form in GrowthBook, with fields for title, description, status, tags, projects, and supporting and contradicting experiments.

Every learning can cite the experiments that support it and the ones that don't, then be scoped to the projects and tags where the pattern actually held

You can use Learnings to document things like:

• Patterns that repeatedly improve a metric
• Approaches that consistently fail
• Differences between user segments
• Design principles supported by experimentation
• Unexpected behaviors observed across multiple tests
• Areas where the evidence is contradictory or uncertain

The same change isn’t universally applicable, though. Streamlining a flow can lift conversion in one part of your product and lower it in another, and the right amount of friction depends on what the user is trying to do. Learnings can be scoped to specific projects or tags, so that patterns that have been tested for your self-serve signup aren’t applied to your enterprise onboarding flow.

And learnings do not have to come exclusively from experiments either. You can capture qualitative findings from user research, customer interviews, support conversations, or other sources and combine them with quantitative evidence.

The goal is not to turn every observation into an immutable rule.

It is to give your organization a shared, evidence-backed memory. Each learning can be updated if new evidence comes in, and also have a specific status for when the learning is not verified yet, or if it’s no longer relevant. Statuses for learnings are entirely customizable. Once captured this way, that memory becomes something both people and AI agents can draw on, which raises the question of how much of it to hand an agent at once, and in what form.

The context window problem for organizations

The context window problem for organizations

There is a useful analogy to working with AI coding tools.

If you give an agent every line of code your company has ever written, you have technically given it more information. But you have not necessarily given it better context.

The useful question is:

what does the agent actually need to know to make this decision well?

Organizations have the same problem. After thousands of experiments, nobody should need to read thousands of experiment reports before starting a project. They need the relevant conclusions.

Learnings act as a compressed context layer over your experimentation history. The underlying experiments are still there as evidence, but people and agents can work from the higher-level patterns that those experiments have established.

For example:

Learning:
Users are more likely to complete complex setup flows when advanced configuration is deferred until after initial success.

Evidence:
Seven onboarding experiments across three product areas.

A PM planning a new onboarding experience can start with that knowledge instead of rediscovering it. An engineer can incorporate it while designing the implementation. The same applies to agents, even more strongly. An agent without access to your evidence will still produce a confident answer, but it will be generic and maybe an approach you’ve already disproved. Point your agents at your Learnings, and they start from what you already know.

Learnings are available through GrowthBook's APIs and MCP support, just like your experiments and other experimentation data. Through GrowthBook Skills, you can instruct agents to retrieve relevant Learnings before they design or implement something.

Instead of giving agents generic product-development best practices, you can give them exactly what they need to know to make this decision well: your company’s own compressed, decision-relevant knowledge, grounded in real outcomes and updated as new evidence comes in.

AI can help find the patterns humans miss

AI can help find the patterns humans miss

As experimentation programs grow, manually identifying patterns becomes harder if not impossible. A team running ten experiments a year can probably remember most of them. A company running thousands cannot. GrowthBook can use AI to analyze your experiment history and surface commonalities across results.

GrowthBook's Find Learnings panel proposing a learning about friction reduction in conversion flows, citing three supporting experiments.

GrowthBook proposes candidate learnings from your experiment history, with the supporting evidence and a suggested next step attached. You decide which ones to keep.

Perhaps a certain type of messaging consistently works for new users but not existing customers. Maybe several unrelated experiments show that reducing perceived commitment improves activation. Maybe a UI pattern that teams keep proposing has actually failed in four different areas of the product.

These patterns are easy to miss when every experiment is analyzed independently.

AI makes it possible to search across a much larger body of evidence, while Learnings give teams a place to review, refine, and preserve the conclusions that matter.

Good experiment hygiene becomes even more valuable

Good experiment hygiene becomes even more valuable

There is an important prerequisite.

AI cannot infer very much from an experiment called "Homepage test 7" with no hypothesis, description, or conclusion.

The better your experiment documentation, the more useful your accumulated knowledge becomes.

This is one reason GrowthBook has increasingly invested in experiment quality and hygiene, including checklists and workflows that encourage teams to document the hypothesis, context, results, and conclusions of an experiment. Good documentation has always made individual experiments easier to understand.

With Learnings, it also makes the entire experimentation history more valuable. Every well-documented experiment becomes another piece of evidence that can contribute to future decisions.

From experimentation history to organizational memory

From experimentation history to organizational memory

The long-term value of experimentation is not just making better decisions today. It is making every future decision from a stronger starting point.

Experiments that win improve the product. All your experiments improve the ideas, assumptions, and decisions that come next, increasingly including the ones your agents make. That’s the part that really compounds. Firmer footing leads to better experiments, which produce better evidence, which produces better judgment. Over time, your experimentation program is not only improving your product, it’s improving your organization’s ability to build one.

Experiments should not disappear into a results archive once a decision has been made. The best ones should keep teaching you.

Security Patch Release

Fixes critical auth vulnerability affecting self-hosted non-SSO deployments with publicly accessible /auth/* endpoints

Switches to Docker Hardened base images to reduce exposure to 3rd party vulnerabilities

Bump dependency versions to address various security vulnerabilities

New Databricks OAuth M2M option for increased security

New org setting to completely disable all Personal Access Tokens

Various performance and bug fixes throughout the app

We recommend all self-hosted users update as soon as possible.

This is also a great time to read through our production hardening docs and ensure you are following all best practices for security.

Starting an experiment should be easy

Every team that runs experiments wants to run more, faster. The difference between teams is where friction lives.

Consider two teams. The first team is finishing its first dozen experiments. Their process works, technically, but they run all experiments through two or three technical staff they trust. Experiments feel complex and high-stakes, and they worry that a bad customer experience could set the company back. The second team runs hundreds of experiments every day, against a warehouse with petabytes of data. They have the opportunity of fast, high-scale experimentation, but every analysis run has compute costs that equal real time and money. They need infrastructure to match their opportunity.

Different stages produce different friction.

GrowthBook 5.0 meets friction at every stage, making it easier to experiment when you’re building the habit, faster and more efficient at the frontier, and safer all along.

One of the biggest barriers to early teams is an empty experiment creation screen, especially when it’s long and involves more complex, technical options.

In 5.0, we cut the experiment creation flow from 23 fields to 5. The rest of the options move to the experiment overview page. You can write a hypothesis, set up experiment assignment, and share the draft to your team in the time it used to take to scroll through the previous version.

The streamlined experiment creation flow

We ran an experiment as we rolled this out, and there’s a surprisingly large effect. More people can create an experiment without feeling like they need to be an expert, and with sensible defaults, starting doesn’t mean shipping something accidentally.

Making experiment creation “cheaper,” with less time and expertise invested, makes it easier to imagine running more experiments and building a broader culture of experimentation. A thin experiment, with just the minimum fields, becomes a shared surface your team can edit and learn in together. Experimentation begins as collaboration rather than a handoff.

More hands, same standards

As the team grows and experimentation velocity increases, more and more people kick off experiments. You have an experimentation process that works, and you want more of it. More teams want to experiment, but a small handful of experts is still a bottleneck. Ideas for experiments might abound, but the organization is short on the people needed to push experiments from beginning to end.

Scaling experimentation means handing more people, more operations, the keys without giving up control of what ships. GrowthBook 5.0 helps.

More people can create. AI agents can now operate GrowthBook, which means anyone, through their code editor or with our new in-app AI Assistant, can brainstorm and create experiments, launch them, and check results with natural language. The new AI Visual Editor opens another door for teams, like growth and marketing, who prefer a point, click, and prompt experience. With the slim experiment creation flow and reusable templates, it’s so much easier to set up an experiment now and build on an existing experimentation program.

Creating an experiment through Claude

Guardrails travel with tests. Opening the door for more experimentation only helps your org if your best practices and processes stay in place for everyone. Our new custom hooks let teams codify their own rules and run checks for every experiment before it starts, automatically. Mandatory custom fields make sure every experiment is categorized and filled before it’s ever created. Linked feature flags mean a teammate still reviews production changes before launch. These checks live with the experiment, and are present and documented in GrowthBook.

Shared understanding builds shared commitment. Experiments that finish and features that roll out without others knowing can help a business, but they don’t help build shared knowledge and experimentation culture. We now have new meta-analysis experiment blocks for dashboards, so your team can have better oversight of what’s running, win percentages, lift, and scaled impact. Everyone in the org can learn, and, hopefully, be inspired to experiment also.

Using experiment meta blocks to understand impact on a metric

You don’t have to be at your desk to launch. GrowthBook 5.0 supports scheduled starts for experiments. You can kick off a test without being live at your computer. It sounds like a small thing, but as you scale and coordinate more and more experiments, control like this is what keeps a program manageable, right up until the next constraint takes over: compute.

Solve for people and trust, though, and a new limit appears: the volume of experiments you can now run starts to outgrow the infrastructure running them, and the bottleneck shifts from who can experiment to what your compute can afford.

Where compute is the constraint

At the frontier of experimentation scale, the bottleneck becomes compute. Data-rich environments give you the raw material for fast, accurate results, but can come with a bill to match. Teams that run hundreds of experiments a day against high-volume warehouses need infrastructure that meets their opportunity without equally large bills or compromises on velocity.

We think two techniques are highly relevant for these teams: quantile treatment effects (like the effect of a change on your p99 latency) and CUPED, which uses pre-experiment behavior to cut noise and bring results faster. Neither technique is new, but there’s a challenge to running them efficiently with a warehouse-native platform when data is large and quickly changing.

GrowthBook 5.0 includes major performance improvements with both approaches. For quantiles, we use KLL sketches to gather an event-level histogram into a single column that doesn’t grow as events pile up, which keeps quantiles cheaper at volume and even allows for pre-aggregations in the warehouse to be consumed by GrowthBook. For CUPED, we can now run a nightly pre-aggregation of each experimentation unit’s history, and since GrowthBook holds metric definition in our semantic layer, it refreshes only summaries that go stale when a definition changes.

We’ve seen >80% reduction in wall time for an experiment update, faster individual runtimes for experiments, and overall reduction in compute, which leads to lower warehouse bills. We’ll write about this in more detail later, but if you’re experimenting and analyzing at petabyte scale, come talk to us.

A platform you never outgrow

Everything in this post moved as you grew: the friction of starting, the bottleneck of people, the ceiling of compute. Safety is the one thing that didn't.

With GrowthBook 5.0, you can run experiments a little more easily, a little faster, with as much safety as ever, so you can make more chances to really learn about your product and users. That’s the real goal of experimentation: knowing instead of guessing, and building a better product for the people who use it.

Want to hear from our co-founders and engineers how we’ve made feature flagging and experimentation better? Come to our live Office Hours on July 30, 9am PT, and we’ll answer any questions you have.

Governance, for those unaccustomed to this buzzy word, is simply referring to guardrails.

With feature flags, it can be really easy to work yourself into a pickle. Our latest 5.0 release focused on many cool things, but one of the big ones was protecting you and your co-workers from yourselves. So you can work faster while still shipping safely.

As AI speeds up how fast code can be written and large organizations release more changes across more teams, the challenge is no longer simply getting work out the door. It is vital to make sure every change is valid, behaves as expected alongside everything else, and reaches production with the right context.

With this in mind, there are three areas in which we focused our feature flag governance in 5.0:

1. Catch problems while someone is making the change
2. Catch problems created by the full rule set
3. Make the final decision with context

Catch problems while someone is making the change

For this category of features, GrowthBook is checking whether the change itself is valid, sensible, and no larger than it needs to be. The best time to catch a bad flag change is before it becomes a review comment, a Slack thread, or a production scavenger hunt.

Schema validation for string and number flags

GrowthBook could already validate the shape of JSON flag values. Now you can also set rules for string and number flags.

For example, you can now limit a checkout layout flag to classic, compact, or express. GrowthBook will reject anything else, including typos.

["classic", "compact", "express"]

For number flags, now you can set a minimum and maximum, such as allowing results-per-page to be anywhere from 10 to 100.

It is basically type safety for remote config, because TypeScript cannot save you from someone entering "expres" in a dashboard. Invalid values can now be caught before they are saved or published.

Feature-scoped Custom Hooks

Custom Hooks let your team write its own rules for what counts as a valid flag change.

For example, you could require a description, prevent targeting by email address, or make sure every rollout uses userId.

Custom Hooks already existed, but they previously applied to every feature in an organization or project. Now you can attach one to a single feature that needs its own rules.

• Organization-wide: Every feature flag must have an owner and at least one tag.
• Project-wide: Every rollout in the checkout project must use userId for hashing.
• Single feature: Only the checkout-config flag must include a Jira ticket before it can be changed.

Soft warnings

Not every questionable choice deserves the full red-screen treatment.

Custom Hooks can now raise a warning instead of blocking the save:

addWarning("Consider adding a ticket number");

The person editing can review it and choose Save anyway.

So now you have two volumes:

• addWarning() says, “Are you sure about this?”
• throw says, “Absolutely not.”

Sparse patches for JSON rules

Suppose a JSON flag has ten fields, but a rule only needs to change one.

Instead of copying the entire object, you can save just the keys and values you want to update:

{
  "theme": "dark"
}

A sparse patch preview showing only the changed field before it merges onto the default value.

GrowthBook merges that onto the default value, which means smaller changes, cleaner diffs, and fewer stale copied fields.

One important caveat: the merge is shallow. It only merges top-level keys, not deeply nested objects.

Together, these features make the editor feel less like a blank text box with consequences and more like a development environment that knows what “valid” means.

The value can be checked against an expected shape, custom rules can catch requirements unique to your team, warnings can flag questionable choices without blocking every save, and sparse patches keep changes focused on the fields someone actually meant to touch. By the time the change reaches review, many of the easiest mistakes have already been caught, while they are still cheap to fix.

Catch problems created by the full rule set

A rule can be perfectly valid on its own and still cause trouble once it joins the group chat.

GrowthBook evaluates rules from top to bottom. An earlier rule can serve a user before a later rule ever gets the chance.

For example:

1. Force a value for everyone in the US.
2. Force a different value for Pro users in the US.

The second rule will never run. Pro users in the US already matched the first rule and left the building.

GrowthBook already warned when a rule was completely unreachable. In 5.0, that detection expands to catch more ways rules can compete for the same traffic.

The warnings now have three levels:

• Unreachable: No matching traffic will reach the rule.
• Will not reach: Some matching traffic will definitely be served by an earlier rule.
• May not reach: An earlier rule might serve some of the same traffic, but we cannot say exactly how much.

GrowthBook flags a rule as unreachable when an earlier rule already matches the same traffic.

That last distinction matters for partial rollouts. A 90% rollout above another rule does not completely block the rule below it, but it does take a large bite out of the traffic before it gets there.

The warning also points to the earlier rule causing the conflict, so you can reorder the rules, narrow the targeting, or confirm that the overlap is intentional.

This catches a different class of problem than schema validation or Custom Hooks. Each rule may be valid, but the full rule set may not behave the way you pictured it.

Make the final decision with context

Automated checks can catch a lot, but eventually a human still has to decide: Is this change ready to go live?

GrowthBook 5.0 adds a dedicated Review & Publish tab that brings the scattered pieces of that decision into one place. It replaces separate publishing, review, and conflict-resolution flows with one shared workspace.

The Conversation view summarizes what changed and lets you publish the draft directly.

The Conversation view gives you the readable version of the story: what changed, why it changed, who contributed, any comments or reviews, and what needs to happen next.

When you need the technical receipts, the Changes view shows the detailed diff and lets people comment on the specific changes.

If Approval Flows are enabled, reviewers can leave a comment, request changes, or approve the draft before it is published. Without required approvals, someone with permission can still review the same context and publish directly. Approval Flows are a commercial feature.

The goal is not to make every flag change pass through a courtroom. It is to put the diff, discussion, reviewers, conflicts, and final action in the same room, so the person clicking Publish knows exactly what they are sending out the door.

Guardrails not stop signs

Good governance is not about slowing creators down. It is about making the work they publish quality and catching problems early before they hit users.

By adding governance while changes are created, when rules interact, and before publishing, teams will catch mistakes earlier and ship with more confidence. I'm so excited for what 5.0 at GrowthBook has brought to feature flags. If you'd like to learn more or hear from the engineers behind all of our newly released features, you can join us for Office Hours Live on Thursday, July 30 at 9 a.m. PT. See you online and happy experimenting!

AI-powered analytics

A native AI chat agent is built directly into Product Analytics. This opens up analytics to any user, turning a few prompts into actionable insights without needing to know the schema or rely on a data analyst for answers.

Ask questions in plain language, such as “Chart the number of daily users and conversions for the past 30 days” and the agent will build the exploration, render the chart, and surface insights behind the data.

In-app AI assistant

GrowthBook 5.0 also includes a platform-wide AI assistant available from any page in the app. In addition to taking action and supporting workflows across feature flags and experiments, it can also pull up analytics and surface trends from wherever you're working. This assistant pulls from 25+ open-source skills spanning feature flag management, experiment design, and product analytics.

The Metric Explorer: visualize and explore your data

The Metric Explorer lets you visualize any metric your team has defined in GrowthBook without needing to write SQL. These are the same metric definitions powering your experiments, so there's no custom SQL to write and no risk of metric drift between your analytics and your experiment results. This lets teams go quickly from question to chart in seconds.

The Metric Explorer supports a range of chart types (line, area, bar, stacked bar, horizontal bar, stacked horizontal bar, timeseries table, table, and big number) and the ability to segment by dates, dimensions, and filters.

If your team hasn't fully defined metrics yet, the Explorer also supports querying fact tables directly or even raw data source tables in your warehouse, so you can start exploring immediately and promote what you find to reusable metrics over time.

Because GrowthBook generates the SQL behind the scenes, it works with GrowthBook's Managed Warehouse, BigQuery, Snowflake, Databricks, Redshift, ClickHouse, Postgres, and more. Your data never leaves the warehouse.

SQL Reports

The SQL Explorer lets you write, save, and share queries directly within GrowthBook. No external BI tool needed. Pin results to any dashboard alongside your metric explorations and experiment data.

Write a query in the built-in editor with schema browsing and autocomplete, or describe what you want in plain language and let AI generate the SQL from your warehouse schema. Run the query, then layer on the types of visualizations you’d like to see: bar, line, area, scatter, pivot table, or big value (KPI). Configure axes, aggregations, dimensions, and filters visually without touching the SQL again.

Save reports, refresh them on demand, and pin individual visualizations to any dashboard alongside your metric explorations.

Funnel analysis

Define step sequences to visualize conversion rates between each step and understand where users fall out of the flow. Break funnels down by any dimension to find where specific segments convert differently.

For example, you might define a checkout funnel and break it down by device type. You notice mobile users drop off at the payment step at twice the rate of desktop. That's a clear signal. From the same platform, you can launch an experiment to test a simplified mobile payment flow and measure whether it closes the gap.

Whether it's your onboarding flow, checkout, or activation sequence, funnel analysis turns drop-off points into experiment hypotheses you can act on immediately.

Dashboards

Dashboards let you tell a story with your data. Create custom dashboards tailored to your north star metrics so they remain front and center. Arrange the KPIs that matter most to you on a flexible grid with drag-and-drop, and set a refresh schedule to keep everything current, and share with your team.

GrowthBook dashboards support a range of block types, from metric explorations and saved SQL queries to rich text, so you can build exactly the narrative your team or stakeholders need to get the full picture.

A typical dashboard might include your north star metric trend, a product funnel showing where users drop off, and the scaled impact from all your experiments pertaining to the relevant metrics.

One source of truth

Product Analytics is an extension of the work your data team has already done. The metrics are defined. The warehouse is connected. Now those same definitions power dashboards, funnels, and ad-hoc exploration, not just experiment results.

For teams that want programmatic access, the REST API exposes endpoints for running explorations, and every exploration gets a shareable URL encoding its complete configuration.

Product Analytics is available now. Get started or book a demo to see it in action.

TL;DR: GrowthBook 5.0 ships with an AI Visual Editor that lets anyone build and launch a live experiment on their website from a plain-language prompt, no engineering ticket required.

Growth and marketing teams rarely suffer from a shortage of ideas.

There is always another headline to test, another landing page to improve, another audience that may respond to different messaging, or another campaign that could convert more effectively.

The problem is getting those ideas into production. The reality for many marketing and growth teams is that testing capacity is capped by engineering bandwidth.

The GrowthBook AI Visual Editor unlocks this entire process. For the first time, anyone can vibe code a new home page or product page and deploy a rigorous experiment in minutes without engineering expertise. The AI Visual Editor allows users to move sections, change text and colors, and even swap out images with just a series of prompts. Once a new variation is built, these same users can kick off rigorous experiments using the same metrics and templates created by your data science team. So anyone can run experiments you can trust.

See the visual editor in action here:

Run experiments without waiting for engineering

The most immediate benefit of a visual experimentation system is straightforward: growth and marketing teams can move from an idea to a live experiment without waiting for an engineer to implement every variation.

Using GrowthBook’s AI Visual Editor, teams can describe a change in plain English or make it directly through a WYSIWYG interface. They can update text, modify styles, rearrange content, replace imagery, hide elements, or create more substantial page variations.

The editor then turns those changes into an experiment that can be previewed, reviewed, and launched through GrowthBook.

This removes a significant source of friction from the experimentation process.

Engineering teams no longer need to spend time implementing every headline test, campaign-specific landing page, image variation, or call-to-action adjustment. Growth teams no longer need to wait for an open sprint before learning whether an idea works.

And GrowthBook’s AI Visual Editor keeps engineering teams happy. The AI Visual Editor, like all of GrowthBook, is built on transparency so the technical teams can still review exactly what the experiment is doing, audit the results, look at the metrics, etc. Visual experiments also run on the same SDK used for other parts of GrowthBook, and even be flicker-free.

The difference is that engineering is no longer required for every step of every experiment.

What you can do with the AI Visual Editor

Many visual editors fall short and break on modern sites, and quietly push you back into writing CSS or HTML. We fully rebuilt our new AI Visual Editor from scratch to fix these issues.

The AI Visual Editor lets anyone describe the change they want in plain language and get a working variation without writing code. Use manual mode or enter a prompt to do things like:

• Generate images with AI: Use AI to generate and modify hero images, product photos, background visuals, and more.
• Change headlines and copy: Manually update copy to test different messaging.
• Generate new copy ideas: Prompt the AI to write different headlines, CTAs, or copy variations to test.
• Run multi-arm bandits: Use the AI Visual Editor to make changes to your site and run it as a multi-arm bandit to dynamically allocate traffic to the highest performing variant.
• Update designs and layouts: Adjust fonts, padding, button styles, restructure layouts, and more.
• Import Figma frames or mockups: Bring in a design straight from Figma to test actual user interaction without rebuilding it from scratch, not just as a static image.
• Import image files: Pull in your own images or brand assets.

The variation is built directly in the editor so you can see exactly how all your changes will look to your end users.

Test more ideas and learn faster

Reducing implementation work changes more than test speed. It changes which ideas are worth testing at all.

When every experiment requires engineering time, teams naturally reserve experimentation for larger ideas. Smaller questions remain unanswered because the expected value of the result does not justify the cost of implementation. A visual editor lowers the incremental cost of answering them, resulting in teams running more experiments.

The real advantage is that teams can explore more ideas, test smaller assumptions, iterate on promising concepts, and build a clearer understanding of what customers respond to.

Instead of spending weeks debating which message should become the new default, teams can put several credible alternatives in front of real users and measure the result. You can even run a multi-arm bandit directly from the AI Visual Editor. The new workflow becomes:

1. Identify an opportunity.
2. Create a high-quality variation.
3. Launch it safely.
4. Measure its effect.
5. Use the result to inform the next decision.

The faster that loop becomes, the faster a team can improve.

Personalize messaging for different audiences

Most websites present a single version of the company to every visitor.

But not every visitor arrives with the same problem, the same level of familiarity, or the same reason for evaluating the product.

Someone arriving from an AI-focused campaign may care about evaluating nondeterministic product experiences. An enterprise buyer may care more about security, governance, and deployment flexibility. A developer may care about SDK performance and implementation details. A marketing leader may care about conversion rates and how quickly their team can launch tests.

Sending all of these visitors to the same generic page often means presenting each of them with a diluted version of the message they actually need.

Client-side experimentation gives growth and marketing teams a practical way to test more relevant experiences for different audiences. The objective is not personalization for its own sake. Every additional experience creates complexity, and not every audience needs its own version of a website.

The value comes from being able to test whether a more relevant message actually improves the outcome.

Validate ideas before investing in permanent development

Some ideas require substantial engineering work to implement correctly.

A redesigned pricing page may need new components. A different onboarding flow may require backend changes. A personalized experience may eventually need to be integrated deeply into the application.

But teams do not always need to build the complete version before learning whether the underlying idea has value.

A visual experiment can serve as a lightweight production prototype.

A growth team can create a realistic variation, expose it to a controlled audience, and measure whether it changes customer behavior. If the experiment performs poorly, the company avoids investing in a larger implementation. If it performs well, the team has evidence that can justify and guide the permanent build.

Not every experiment can or should be implemented through a visual editor. Changes involving application logic, backend systems, authentication, pricing calculations, or complex product behavior will still require engineering.

But even in those cases, a client-side test may help validate the customer-facing premise before the company commits to the full investment.

Turn experimentation into a fun part of your work

Growth and marketing teams should not need to choose between moving quickly and running rigorous experiments. But more than that, GrowthBook’s AI Visual Editor allows your team to express their creativity while measuring quantifiable results.

Because the goal is not simply to change the website faster.

It is to learn what works, and have fun while doing it. The new AI Visual Editor is a Chrome extension. You can add it to your browser, open up the extension, connect to your GrowthBook account, and create experiments. Read the Visual Editor docs to see how it fits your setup.

Despite the major version bump, GrowthBook 5.0 does not have any breaking changes and can be upgraded to safely.

A year ago when we released version 4.0, the world of product development looked completely different. Claude Code had just launched, agent skills didn't exist yet, engineers were still writing code by hand. The world today is almost unrecognizable. GrowthBook too has changed rapidly in that time and we wanted to signify the massive improvements over the past year with a new major version.

Agentic Experience

Everything a human can do in the GrowthBook UI, an Agent should be able to do programatically. We aren’t 100% there yet, but this release pushes us much closer to that goal:

• Official Skills for common workflows like starting an experiment, summarizing results, or cleaning up stale flags. Use these in Claude, Cursor, Codex, or wherever else your agents live.
• In-App Assistant with access to the same set of Official Skills, plus context about what page you are currently viewing. Use this to quickly automate tasks in the UI or ask questions about your flags or experiments without leaving GrowthBook.
• GrowthBook CLI - Brand new, with 100% coverage of our public REST API endpoints and a much better agent (and developer) experience.

Feature Flag Governance

Moving at AI speed requires strong guardrails and governance for feature flag changes. GrowthBook already had best-in-class capabilities here, but this release takes it to the next level:

• Custom Hooks V2 can now be configured for individual features and have improved performance, security, and the ability to differentiate between soft warnings and hard blockers.
• JSON Schema validation for string/number flags to enforce min/max values, static enum options, and more.
• Unreachable Rule Detection highlights in the UI when a feature rule is fully or partially unreachable due to conflicting rules above it
• JSON Sparse Patching lets you do partial updates to JSON feature flag values without copy/pasting the entire value.
• Constants let you define a single source of truth for feature values and reference them easily from multiple features and rules.
• Configs are a brand new composable and strongly typed way to build complex JSON flags for remote configuration.
• New Draft Review UX in a dedicated tab on feature pages help you quickly review proposed draft changes

Product Analytics

We launched Product Analytics in beta in GrowthBook 4.2. Since then, we’ve been hard at work fixing bugs, adding new features, and improving the UX. We still have a lot more planned, but we’re excited in this release to remove the “beta” tag and mark Product Analytics as generally available.

• Funnel Analysis lets you understand how users flow through your product. Define steps and see the drop-off rates as users progress through, filter to specific segments and date ranges, break out by dimensions, and more.
• Resizable Dashboard Blocks let you have full control over the grid in dashboards, including the ability to stack graphs side-by-side.
• Global Date Filters in dashboards and a way to easily compare to past date periods
• Meta Analysis Dashboard Blocks with data about your experimentation program. View your experiment velocity, win rate, or cumulative metric impact side-by-side with all of your other Product Analytics data.

Visual Editor

We built a brand new AI-native Visual Editor from scratch.

• Modern Chrome Extension runs in a dedicated side bar so it doesn’t conflict with your site and has a sleek modern design.
• Prompt-based Experiments let you explain what you want to test on your page and an agent will implement and configure everything for you. It feels like magic.
• Image Hosting on our global CDN to easily test AI-generated image variations on your site.
• Figma Integration to automatically implement designs. Go from mock-up to live in minutes.

Faster, Easier, Safer Experiments

Our goal is to reduce the cost of running an experiment down to zero. To that end, we’ve been hard at work making experiments easier to set up, faster to run, and safer to do at scale:

• Experiment Creation went from 23 (!!!) form fields down to just 5. We also redesigned the experiment draft page to make it easier to see what’s remaining and gain confidence before starting.
• Experiment Scheduling to start an experiment automatically at a future date.
• Query Performance has improved drastically for huge datasets, resulting in faster queries and lower compute costs. If you are analyzing experiment data at the petabyte scale, reach out to us so we can help you take advantage of all of these recent improvements.
• Experiment Custom Hooks let you write custom javascript snippets to validate experiments before save. Use this to enforce company (or project) wide standards and best practices. Currently only enabled for self-hosted Enterprise deployments.

Contributors

Thanks to all of our existing contributors: @jdorn, @Kevin-Chant, @mknowlton89, @ahdriel, @gazzdingo, @lukesonnet, @msamper, @bryce-fitzsimons, @nadapzy, @olu-an, @tzjames, @Auz, @oelshaikh, @nhat-growthbook, @csbailey5t, @teresayung, @anna-yn, @johnham-ant, @august-growthbook, @lillialjackson, @madhuchavva, @lukebrawleysmith and a big thanks to everyone who made their first contribution!

• @akramcodez made their first contribution in #6048
• @gerami-ant made their first contribution in #6072
• @alyssamichelle made their first contribution in #6194
• @ilyausorov made their first contribution in #6195
• @Sambhram1 made their first contribution in #5822
• @AnkittChauhan made their first contribution in #5523
• @CedricConday made their first contribution in #6238
• @dlin-growthbook made their first contribution in #6377

How agents operate GrowthBook

The Fyxer team ran 541 experiments last year with a small team. They didn’t just get faster at using their tools. They put agents in the loop to run the workflow itself.

This is the workflow they shared with us: someone fills out a form with a hypothesis and target metrics. This triggers an agent to create a flag and experiment in GrowthBook and publish to a company-wide experiment index. Someone starts the experiment with a “launch” message in Slack. Only 25% of their experiments won, but that fast iteration and learning loop helped drive ARR growth from $1M to $35M.

Fyxer wired that together themselves. GrowthBook 5.0 makes this agentic experience first-class and accessible for more users and teams natively. Now, agents can operate GrowthBook: create flags, set targeting rules, brainstorm and create and launch experiments, with a consistent experience across interfaces.

Agents can now run GrowthBook from the places you work. Picture one experiment over the course of a week.

You start a morning in Claude Desktop brainstorming your next experiment. The GrowthBook skills ground your ideas in your own history: what you’ve run, what succeeded, and how metrics moved.

You pick a direction, switch to Cursor and build it. Your agent creates the feature flag, sets up the variations, and configures the experiment alongside the code changes. Our skills carry guardrails, so the experiment lands as a draft for a teammate to review rather than a live test. Review, launch, and ship it.

Create an experiment with GrowthBook Skills in Claude

Later in the week, you’ve got results. You open the GrowthBook app and ask the new AI Assistant how the test did and whether you should ship. You want to dig deeper into how feature usage differs across segments, so you work with the AI analyst to build out a dashboard to share with the team.

You change tools, but the platform and the experience stay the same.

We built this consistency by building reusable foundation elements:

• 25 open-source skills that teach an agent how to use GrowthBook effectively across flags, experiments, and product analytics.
• A CLI rebuilt with Speakeasy that covers 100% of our REST API and regenerates automatically from our OpenAPI spec. It won’t drift, and it returns typed output with errors an agent can use effectively.
• A comprehensive REST API underneath that fuels the skills and the CLI. If you’d rather see it than read about it, watch here.

This foundation powers new ways you and your agents can run GrowthBook: the in-app AI Assistant, a reworked MCP server that integrates the skills, and a native Slack app (coming soon!).

How to trust your agents

When agents are part of your team, they should follow your team’s standards and processes, just like anyone else shipping flags or experiments. Agents can make mistakes, but we’ve built our skills and Assistant so that agent-driven changes land as drafts and a person reviews before anything publishes. The same approval policies, audit trails, and guardrails to catch bad flags before they ship apply to both humans and agents. Your team maintains judgment and governance.

We’ll dive more into the improvements we’ve made to governance, especially for features flags, on Thursday.

One platform for humans and agents

Whether you and your agents are in the terminal, the editor, or the app, you’re working on the same GrowthBook platform, with your flags, experiments, and warehouse data. We’ll keep evolving interfaces; you should never feel like you’ve outgrown the platform.

Connect your agent and run your first skill.

Sign up and join us for a live Office Hours Thursday, July 30, at 9am PT and tell us what to build next.

Tomorrow: the new AI Visual Editor, rebuilt from scratch to make experimentation easier in the browser.

GrowthBook 5.0 ships today

It’s not enough to write code and ship at the speed of AI. Companies that win consistently make their products better. GrowthBook 5.0 enables companies to build, ship, and improve their product at any scale.

Our last major release (v4) shipped a year ago. Since then, we’ve rewritten feature flags from scratch, built Product Analytics, made experimentation significantly faster, and integrated AI throughout.

GrowthBook 5.0 crystallizes the last year of work, and it’s big enough that a minor version number just wouldn’t do. We've touched nearly every corner of the platform, from how experiments are built to how flags are governed. And we’ve opened experimentation to your whole team, not just engineers. More people can ship flags, run tests, and make decisions from shared data, wherever they work: in the app, terminal, code editor, or browser.

There’s far more to cover than we can fit into one post, so we’re covering something new every day, all week:

• Monday: Agents. Official skills, a new in-app assistant, and a CLI that covers our entire API. Your agents can operate GrowthBook directly: ship flags, launch experiments, analyze results, and clean up after. → Read today's post
• Tuesday: The new AI Visual Editor. Rebuilt from scratch, AI-native experimentation from your browser, with image generation and Figma support. Your growth team can ship tests without waiting on an engineer.
• Wednesday: Product Analytics hits GA. Warehouse-native product analytics for engineers and experimenters, out of beta. Built on the same metrics your experiments already use, now with funnels, composable dashboards, and experiment meta-analysis.
• Thursday: Governance for feature flags. Customizable guardrails that catch bad flags before they ship, protecting rollouts whether they come from humans or AI agents.
• Friday: Faster experiments. Streamlined experiment setup, scheduled starts, and faster, cheaper warehouse queries. Designed for running experiments at scale.

GrowthBook 5.0 is live on Cloud now and available for self-hosted deployments. Check out the full release notes.

Sign up and join us for a live Office Hours on Thursday, July 30, at 9am PT. Bring your questions and tell us what we should build next.

GrowthBook’s AI Visual Editor lets anyone on your team go from idea to live experiment in minutes, without touching code. It's a way to scale experimentation beyond one team and across your whole organization.

Just describe the change you want in plain language. The editor handles the rest. No code, no dev ticket, no flicker. The result is a fully configured A/B test ready to launch from your GrowthBook account.

The AI Visual Editor is available on GrowthBook Pro and Enterprise plans.

How does GrowthBook’s new AI Visual Editor work?

The AI Visual Editor is a Google Chrome extension. Open it, connect to your GrowthBook account, and immediately get started. The extension stays in the sidebar and doesn’t overlap your page.

Describe the change you want, such as “make the headline larger and move the CTA button directly beneath,” and the editor will generate a variant in seconds.

There's no code to write. The editor understands the structure of your page, applies the change, and connects it directly to a GrowthBook experiment. You prompt, then preview your changes in real time without ever leaving the browser. If you want more control, you can use the manual editor to do fine adjustments.

Key features

AI-generated image creation and visual testing

The AI Visual Editor is a powerful creative tool. Describe the image you want and the editor generates it in real time, along with options you can place into the right spot on your page and size to fit exactly. Test hero images, product photos, background visuals, and more, iterating until you get what you want without a designer or a design file.

It’s a quick way to immediately see changes in context and visually brainstorm live before you build anything. Once you’re aligned on variations, publish and A/B test new designs in minutes.

Images are stored in GrowthBook’s image storage bucket and served from a CDN-fronted URL so SDKs can fetch them efficiently when delivering variations.

Design updates and layout changes

Beyond text and images, the AI Visual Editor also lets you adjust fonts, colors, padding, button styles, layouts, and more all through prompts or via the manual editor.

Make design decisions without mocking anything up or writing a line of code. Try it, see how it looks in context, and decide if it's worth testing before it goes live.

Import from Figma or an image design

You can quickly turn a Figma frame or mockup image into a testable variation. Import the file into the AI Visual Editor and it will rebuild it as a new component, placing it on the page as a variation. You can also add additional context as to how the AI is to implement the design. This makes it easy to test designs your team has mocked up, such as a new hero, redesigned pricing card, modal window, or promo banner.

What use cases does this work well for?

Landing page optimization and headline testing

The AI Visual Editor is ideal for landing page optimization, such as testing headlines, messaging, copy order, and structure. Use AI to generate variant ideas, preview them directly on the page, then launch the test in minutes.

Promotional banner and offer testing

Test things like the impact of a promotional banner on bookings to Hawaii. The AI Visual Editor lets you build and swap promotional messaging directly on the page. Run the experiment, read the results, and roll out the winner.

With GrowthBook’s feature targeting capabilities, you can deliver different promotions to different audiences based on the criteria you choose, personalizing as you see fit.

Experimentation for every team

The AI Visual Editor expands experimentation across your organization by putting the ability to build and launch tests directly in the hands of the people with ideas, regardless of technical skillset.

• Marketing and growth teams can independently run their own tests on landing pages, campaigns, and offers.
• Teams that want to move fast can go from idea to live experiment in minutes without touching a line of code.
• Product and design teams can validate new layouts, messaging, and user flows before investing engineering time.
• Developers can stay focused on higher-complexity work instead of implementing every copy or design test.

By unlocking experimentation across your organization, you get more tests, more learning, and faster iteration for everyone. It also improves collaboration by giving marketing, growth, and product teams shared visibility into what's working, so no one operates in a silo.

Your existing guardrails stay in place

The AI Visual Editor handles the creative execution by generating variants, applying changes, and wiring up the experiment, but everything still runs through the GrowthBook platform. Your approval and review workflows, as well as existing processes, remain in place, so your team maintains governance and control.

Get more out of your experimentation platform

The ability to go from idea to experiment in minutes, without engineering support, means more people can run experiments than ever before. And when more people can run experiments, it results in more learnings, faster and more informed decisions, and improvements that compound over time.

Try out the AI Visual Editor (beta)

The AI Visual Editor is currently in beta. Try it today, share your feedback directly with our team, and connect with other users in our community Slack channel.

Download the Chrome extension

Ideate on features, create feature flags, analyze product data, and test what you build, all from Claude Code, Cursor, or Codex against GrowthBook.

AI coding tools are reducing the cost of coding in ways no one ever imagined. Coding that used to take days now takes a prompt. But coding is just one step in the software development lifecycle. Deciding what to build, deploying safely, and tracking the impact of new features still take time. Finding ways to speed to up these processes unlocks even more of the benefits of agentic coding.

That is the vision behind GrowthBook’s 4.4. Your AI coding agent can now drive the entire experiment lifecycle against GrowthBook. From a single conversation in your editor, an agent can analyze your product data, ideate on a new feature, create the feature flag, build the variant, and test it. This post covers what that workflow looks like, how you can incorporate guardrails to create trust, and how to run it from any AI coding agent.

How AI agents can automate the entire lifecycle

Automating the lifecycle is broader than running a single A/B test. AI coding agents can now cover the full product development lifecycle:

• Analyze product data. The agent pulls product metrics and experiment data to identify new product opportunities
• Ideate. Describe a problem in plain language and have the agent propose concrete changes to try, grounded in your actual codebase.
• Create feature flags. The agent creates the feature flag and wires it into your code, so the change is rolled out gradually and safely.
• Build and test. Create experiments using templates, standardized metrics and guardrails.
• Analyze experiments and make decisions. Use AI to analyze experiment data, extract learnings, and make go/no-go recommendations.

How templates and guardrails streamline using AI to create experiments

There are many ways an experiment can go wrong, including flawed assignment rules, bad metrics, and unexpected side effects. Consistency and rigor become even more important as you scale.

GrowthBook addresses these needs in a couple of key ways. Experiment templates pre-define the metrics, randomization, and setup for a class of experiments, so the agent knows your best practices. A team can keep a template for, say, logged-out conversion tests, and every front-end experiment of that type inherits the right goal metrics and guardrails automatically. A built-in decision framework encodes when a result is genuinely shippable, rather than leaving that to the agent's guesswork. And GrowthBook stays the source of truth, so business context lives in one place instead of being re-derived in every prompt.

This is the real shift behind agentic experimentation. The agent handles the mechanics. The platform holds the judgment.

AI can apply a series of skills to automate the experimentation process

Take a simple example: testing new copy for a landing-page headline. You give your coding agent the idea in plain language and point it at the file. From there, the agent works the lifecycle:

• Ideate and build. Reads the file, proposes a few headline variants, and picks one to test.
• Configure. Finds the right experiment template in GrowthBook, confirms the metrics, and creates the experiment in draft.
• Wire it up. Creates the feature flag, links the experiment to it, and edits the component to read from the flag. Nothing is live yet.
• QA checkpoint (you). Confirm the flag is wired correctly in GrowthBook before anything ships.
• Launch. On your approval, the agent starts the experiment and tracking fires automatically as users are bucketed into variants.

(Screenshot of Claude Code showing the results of an experiment)

Reading and shipping work the same way. Later, you ask the agent how the test is doing:

• Analyze. Pulls the latest results, checks the test is well-powered with clean data, and summarizes what happened.
• Recommend. Because the decision framework lives in GrowthBook, the recommendation reflects your team's shipping criteria, not a generic heuristic.
• Ship (your call). If the result clears the bar, tell the agent to roll out the winner. It ships the treatment and writes up the result, with flag cleanup as an optional next step.

This works from any AI coding agent

Whether you use Claude Code, Cursor, Codex or any other coding agent, you can apply this same workflow. All the key components are coding agent-independent, including the programmatic endpoints, the CLI, and a set of open-source skills that teach an agent how to drive GrowthBook correctly. All of this then combines with the context of your own repository.

The governance layer, the templates and the decision framework and your source of truth for experiments, all work the same, consistently and safely with any tool.

The skills are open source and available on GitHub. You can use them as-is or adapt them to how your team runs experiments.

Where humans stay in the loop

Automating the lifecycle does not mean removing yourself from it. The workflow is designed around checkpoints precisely because some decisions should not be fully delegated.

QA is the clearest example. Before an experiment goes live, a person should confirm the feature flag is wired correctly and behaves as expected. Ambiguous results are another. When a test is underpowered, or a goal metric moves while a guardrail slips, that is a judgment call about tradeoffs, not a mechanical decision. The agent can surface the situation and make a recommendation, but a human should own the call.

Think of the agent as a fast, tireless operator that handles the setup, the wiring, the data pulls, and the rollout. The strategy, the QA gate, and the final ship decision stay with you.

Key takeaways

• AI made building cheap, but the experiment lifecycle stayed manual. Agentic experimentation closes that gap.
• An AI coding agent connected to GrowthBook can run the full product development lifecycle: ideate, create feature flags, analyze product data, build, and test.
• Guardrails are what make it trustworthy. Experiment templates and a built-in decision framework move judgment into the platform so agents cannot improvise metrics or ship on noise.
• It is tool-agnostic. The workflow runs from Claude Code, Cursor, Codex, or any agent, because the logic lives in GrowthBook's skills, CLI, and endpoints.
• Humans still own QA and the ship decision. The agent handles mechanics, not judgment.

Get started

The build step and the test step are now both moving at the speed of AI. The way to keep that fast loop safe is to put your experimentation structure into the platform, then let your coding agent drive against it.

The GrowthBook skills are open source and ready to try on GitHub. To see the full workflow end-to-end, watch the walkthrough video. And if you are new to GrowthBook, you can start with feature flagging and experimentation in one platform.

Visual editors are a staple of experimentation platforms. The promise is simple: let anyone change a website and launch an A/B test without writing code or waiting on engineering. In practice, most visual editors fall short. They break on modern sites, cause flicker, and quietly push you back into writing CSS or HTML the moment anything gets tricky.

We designed the GrowthBook Visual Editor from a blank slate to fix these issues. The result is an AI-first editor that lives in your browser's side panel, and it finally lives up to the full potential of a visual editor. This post walks through what is new and why each piece matters for running A/B tests without engineering overhead.

AI first

Most visual editors are visual right up until they are not. The moment you need to nudge spacing or fix a layout, you are back in a CSS box. GrowthBook’s visual editor moves the editing into an AI prompt by default, so any change you can describe, you can build.

Ask it to change the background color, rewrite a headline, generate a few alternative CTAs, or restyle a section. The editor applies the change on the page instantly, and you approve it, reject it, or ask for something different. Nothing is saved to your variation until you accept it.

The AI also reads the live page, including the real elements and their computed styles, so its suggestions are grounded in your actual site rather than guesses. If it is unsure which section you mean, click to select one or more elements and the prompt uses them as context.

AI image editing and generation

Images are often the highest-impact thing to test and the hardest to change without a designer. GrowthBook builds image editing and generation directly into the editor.

Ask the AI to generate a brand new image from a description, replace an existing image, or produce variations based on the image already on the page. Generated images are automatically cropped to the exact dimensions of the slot they replace, so nothing stretches or distorts. You can generate several options at once and pick the one that fits.

Import from Figma or a mockup

Designs usually start in Figma or as a static mockup, and getting them into an experiment has meant a manual rebuild. GrowthBook can import directly from either.

Connect your Figma account and point the editor at a frame, or hand it an image of the design you want. It analyzes the design and turns it into a variation you can preview and refine, so a mockup can become a running test without rebuilding it by hand. You can also add additional context about how you want the design implemented.

Built for modern web platforms

This is where most visual editors quietly fail. Modern frameworks and site builders generate class names like

css-1x9f3k

that change on every deploy. A visual editor that targets those names will silently break the next time your site ships, and the experiment stops running with no warning.

GrowthBook builds durable selectors instead. It ignores hashed and build-generated class names, prefers stable attributes, and anchors to elements in a way that survives redeploys. Your variations keep working after the next release.

Manual mode and global code

When you want precise control, manual mode gives you a full WYSIWYG editor for any element you pick. Edit text, typography, layout, background, visibility, and classes, with each control pre-filled to the element's current values so you are adjusting from where the page actually is. This is also where the most advanced image editor lives. Select any img element to see the options. For changes that span the whole variation, the global CSS and JavaScript editors let you drop in custom code without leaving the panel (or let the AI generate this for you).

No flicker

Flicker is the flash of original content that appears before a variation loads, and it is one of the fastest ways to bias an experiment. GrowthBook avoids it by applying changes before the page renders. Serve the GrowthBook SDK and your feature definitions from your own CDN or edge, and the variation is applied on the initial render rather than after it. Visitors see the variant immediately, with no flash of the control. If you don’t use a CDN, you can still enable the usual no-flicker scripts. See the

docs on avoiding flicker

for setup.

Edit in 4 languages, and even in dark mode

The editor speaks more than English. Switch the interface into German, Spanish, or Portuguese so teams outside English-first organizations can work in their own language. And if you prefer a darker workspace, dark mode is one click away.

Complete transparency

Every change the editor makes is listed in one place. You can see each edit, preview it on or off, jump straight to the affected element on the page, and edit or delete anything you no longer want. Nothing happens in a black box. You can also test your targeting before launch: the built-in URL tester tells you whether a specific URL would be included in the experiment, using the exact same logic the SDK uses in production.

Try it out!

The rebuilt GrowthBook Visual Editor is AI-first, works on modern sites, and keeps you in control of every change. It makes launching an A/B test faster for everyone on the team, not just the people who write CSS. Get started with GrowthBook to create your first visual experiment, or read the

visual editor docs

to see how it fits your setup.

Highlights

This is our biggest release yet! Over 400 PRs closed.

• Cmd+K command pallets for universal search
• Product Analytics explorers and AI Data Analyst (beta)
• Multi-environment feature rules
• Overhaul of feature approval flows and revisions
• Feature flag ramp schedules
• Bandits without sticky bucketing
• Pre-Exposure bias checks
• Huge REST API refactor with tons of new endpoints for metric groups, teams, experiments, features, namespaces, and more

Other Changes

• Holdout scheduling
• Feature revision comparison tool
• Attribute/Identifier type mapping support
• Lookback override option for experiment analysis
• Improved warehouse metadata and tagging for SQL query cost attribution
• Improved stale feature algorithm and UX
• Support for BigQuery reservations
• API keys with arbitrary roles (not just admin or readonly)
• New Saved Group approval flow
• Option to include additional metadata in SDK payloads
• Support for incremental refresh of quantile metrics using KLL sketches
• Ability to disable API keys and track last usage date
• Huge SQL generation refactor (internal, no user-facing changes)
• Better filtering on Insight dashboards
• Namespaces overhaul
• Updated Presentations tool
• Plus tons of UX improvements, bug fixes, dependency updates, security patches, and performance improvements.

Thanks to all of the existing contributors: @Auz, @Kevin-Chant, @ahdriel, @bryce-fitzsimons, @fsarachu, @gazzdingo, @itsgrimetime, @jdorn, @jrnold, @lukebrawleysmith, @lukesonnet, @madhuchavva, @mknowlton89, @msamper, @natasha-growthbook, @nhat-growthbook, @nodirnasirov, @oelshaikh, @royalfig, @tzjames and a big thanks to all of the first time contributors:

• @estrattonbailey made their first contribution in #5283
• @teresayung made their first contribution in #5251
• @nadapzy made their first contribution in #5396
• @dannylin-ant made their first contribution in #5504
• @HampusPoppius made their first contribution in #5572
• @saurabhkashyap-ui made their first contribution in #5564
• @olu-an made their first contribution in #5604
• @csbailey5t made their first contribution in #5614
• @discorev made their first contribution in #5600
• @aiSynergy37 made their first contribution in #5639
• @lillialjackson made their first contribution in #5721
• @nielskaspers made their first contribution in #5629
• @johnham-ant made their first contribution in #5793
• @adittya-upstart made their first contribution in #5778
• @jakemainwaring22 made their first contribution in #5698
• @anna-yn made their first contribution in #5920

The safety net for rapid AI development

AI has empowered developers to build new features faster than ever. What used to take a week can now be shipped in a day. The agentic era has transformed the way engineers work, but shipping fast without the proper guardrails can quickly lead to incidents. GrowthBook Feature Flags set your whole team up for the pace and volume of today’s development lifecycle.

Feature flags allow modern teams to ship fast while maintaining control. The best practice is straightforward: wrap every feature behind a flag so you can ship at scale and roll back the moment something breaks. But as teams scale and AI agents become more deeply embedded in workflows, ad-hoc flag management breaks down.

Without the right metrics monitored on every release, something that breaks in production could go undetected for weeks or even months before you realize the problem. By that point, dozens of other features may have shipped, making it difficult to identify which change is actually the culprit. Smaller failures compound the problem. Someone forgets to increment a rollout. A flag that should have been deleted six months ago is still sitting in production. Each rollout follows a different process depending on who is running it.

Consistency and guardrails are what enable teams to safely keep pace with the compressed development cycles that come with AI coding. Feature flags should be baked into the agent's coding workflow for every new feature, creating a safety net where guardrail metrics monitor performance and auto roll back if something degrades.

With that net in place, teams can move quickly, confident that bad releases will get caught early and rolled back. Humans can then focus on where judgment is actually needed, such as deciding which guardrail metrics matter, reviewing whether the rollout plan aligns to the risk, and approving changes that warrant human review.

Modern teams need enterprise-class flag management with the controls and governance to ship safely at AI speed. That’s where GrowthBook comes in.

GrowthBook 4.4 extends our feature flag platform with 3 major new capabilities: release plans with automated ramp schedules, configurable approval workflows, and enhanced stale feature flag detection through expanded REST API and MCP server endpoints. 4.4 also includes SDK cache improvements, metadata in SDK payloads, a namespace overhaul, and more. Together, these controls turn feature flag management into a repeatable, scalable practice that lets you move quickly while de-risking every release.

Release plans with ramp schedules: Standardize and automate your rollout

In 4.4, we’re introducing release plans with ramp schedules: automated, staged rollout plans attached to a feature flag. Release plans make it fast and easy to define a standardized schedule and rollout process into a reusable template that everyone on your team can follow, with guardrails built in so safety is a standard part of how features are released.

You define the stages, set the percentages, time intervals, and guardrails, and GrowthBook executes the plan automatically. Choose from preset templates or build your own to target specific user groups and attributes. You can also gate individual stages of your release plan by prerequisite features or by the specific feature value a user is currently assigned.

With manual feature rollouts, you can run into two types of problems. Either someone forgets to increment the percentage, and a feature sits at a given stage indefinitely. Or someone moves too fast, and a problem that should have been caught at 10% instead hits 50% of users. Release plans keep rollouts from stalling at an early stage or accelerating past the point where a problem could have been caught. Build in approval requirements at specific stages based on your risk tolerance, requiring the rollout to pause for review and manual approval before advancing. You can also attach guardrail metrics so the feature auto-rolls back if any of them degrade, catching problems automatically between approval gates.

Best practices for designing a release plan

Guardrails help your team feel confident about shipping, and combining them with human approval gates ensures there are no gaps.

1. Start simple and don't over-engineer your first release plan.
2. Build out your process as you go, learning what works and what doesn't with each release.
3. Choose guardrail metrics your team is aligned on
4. Pair guardrail metrics with approval gates where it makes sense.

Once you have a process that works, standardize it as a default template with versions for different risk profiles or product needs (high risk, low risk, internal-only, etc.) Treat these templates as living artifacts and evolve them as your team learns what works and what areas need improvement.

Sample release plans

Rollout processes vary by team, product, and risk tolerance. Release plans are flexible enough to fit whatever process your team uses and ensure every rollout follows that process consistently, no matter who is running it. Below are two of the most common patterns we see, and how to structure a release plan for each.

Example 1: Simple percentage rollout

A simple percentage rollout is where you expose a small percentage of users before gradually going wider. Set approval gates at key checkpoints to enforce a metrics review and manual approval before committing to broader rollout.

Example 2: Segmented rollout

A segmented rollout lets you control who gets access first, reducing risk to your highest-value users. For instance, you may opt to roll out a feature to free users before paid. Free users are valuable, but the risk of churn or revenue impact is lower than with paying customers. By the time you're ramping up paid users, you've already caught the obvious issues.

You may segment by any attribute available in GrowthBook, including location, device type, browser, user group, and more. Start simple or build in as much complexity as you need. You can also apply guardrails to specific stages; for example, you might be okay rolling the feature out to free users, but want it to auto-rollback if metrics degrade when it hits paid users.

The release plan with ramp schedules feature is available in the GrowthBook Pro and Enterprise plans.

Flag revisions, approvals, audit logs: maintain control and visibility

Feature flag revisions

When someone changes a feature flag, a draft revision can be submitted for review to approve or request changes. On approval, the change is published to the SDK. Nothing goes out unreviewed unless you want it to.

Flag revisions provide a complete audit trail, capturing who changed a flag, what they changed, and when they changed it. When something breaks, you get instant visibility into what recently changed. As multiple people manage flags over time, revisions also preserve the intent and context behind each change.

GrowthBook maintains a version history of all previous revisions of a feature flag over time, so you always maintain a clear picture of how a flag has evolved over time.

The revision feature is available for feature flags in all GrowthBook plans.

Feature flag approval workflows

Approval requirements are configurable per project and per environment, giving you the flexibility to require review gates where they make sense. For example, you can require approvals for production while letting staging updates flow freely.

GrowthBook 4.4 expands the scope of approval requirements. Previously, approval workflows applied only to changes to rules and values. Now, you can also require approvals for environment kill switches, pre-requisites, saved groups, and metadata changes. This gives more granular control over what can happen without a review.

These approval workflows help teams move fast with the right safety checks at the right time, making governance tunable to your team’s needs. This level of control is especially important when agents are acting on your behalf. Agents can create drafts for all these change types and require human approval. The separation is clear and enforced, so your governance is applied to the full scope of what an agent can touch.

The feature flag approval workflow feature is available in the GrowthBook Enterprise plan.

Audit logs

For teams with compliance requirements, the audit log provides the paper trail without any extra process. They provide a timestamped record of every feature flag event, including changes, approvals, publishes, creation, and more.

You may also expand for a more detailed view of the specific changes made for each event.

The audit log feature is available in all GrowthBook plans.

Stale feature flag cleanup with agents

GrowthBook categorizes a feature flag as stale if it hasn't been updated in 2 weeks and is not active in any environment, or if there is a one-sided rule that sends 100% of traffic to a single variation.

GrowthBook 4.4 also introduces support for teams using AI coding tools like Claude Code or Cursor to detect and remove stale flags that have outlived their purpose. Using GrowthBook's MCP server or REST API, you can prompt an agent to surface every stale flag in your environment, returning it as a reviewable table with additional context on why the flag is being surfaced as stale. Once you've decided which flags to remove, write a follow-up prompt asking the agent to locate and remove those flag references from your codebase to eliminate technical debt in one pass.

The same endpoints can also surface ambiguous flags that don't definitively meet the stale definition, but show signs they may no longer be in use. Examples include: flags with no rules defined, abandoned drafts, or disabled environments. Results come back as a table you can review to decide which flags genuinely need cleanup and which are still doing real work.

Stale flags create real risk: technical debt, performance overhead, and accidental production changes. Stale and ambiguous feature flag detection together help simplify flag hygiene by surfacing the flags worth reviewing, with enough context to tell what's truly orphaned and what's still needed in production.

The stale feature flag cleanup feature is available in all GrowthBook plans.

REST API and MCP server endpoints

In 4.4, we expanded our REST API and MCP server endpoints across the feature flagging surface. Anything your team can do in the GrowthBook app, AI agents can now do through the API or MCP server: create flags, manage revisions, configure release plans, set targeting rules, locate stale flags, and more.

The same permissions, approval workflows, and audit logs apply to every API- or MCP-prompted action. Whether a human triggers a change from the UI or an agent runs it from your editor, it goes through the same review gate and shows up in the same audit log. Agents get the same platform and the same accountability as your team, with the scoping and guardrails calibrated for how they work.

The REST API & MCP Server endpoints are available in all GrowthBook plans.

Built for the way modern teams ship

The pace of development has fundamentally changed with AI, and the controls around how teams ship need to evolve with it. Teams need to move fast, test everything, ship safely, and roll back at the first sign of trouble.

GrowthBook 4.4 gives engineering and product teams the building blocks to do exactly that: a repeatable rollout process accessible through the app, REST API, or the MCP server. Whether the change comes from an engineer, a product manager, or an AI agent, the process holds.