Big-bang deploys are a lie we tell ourselves. You ship a feature, 100% of users see it on the same second, and if it's broken, you're on fire. You revert, they see the old version, everyone loses. Feature flags solve this by toggling features on/off without deploying. Velocity X uses GrowthBook—an open-source feature-flag platform you self-host for $4/mo on Hetzner—to roll out new AI Brain capabilities, dashboard tabs, and experiment toggles to a percentage of users first, then ramp to 100% if it sticks.
Why Big-Bang Deploys Are Dead
Feature flags let you decouple shipping code from exposing it to users. Ship the AI Brain code? That's a deploy. Turn it on for 5% of users? That's a GrowthBook toggle. Ramp it to 50%? Click "Update Percentage". Roll it back without code? One toggle switch. The old model—ship and hope—means every deploy is a heartbeat moment. Feature flags move risk off the table by making rollouts gradual and reversible.
LaunchDarkly and Unleash charge by the seat ($30–50/mo per engineer, or $500+/mo for a team). GrowthBook is open-source and self-hosted: Docker image, Hetzner $4/mo server, you own the infrastructure. You also own your data—feature decisions stay on your machine, not sent to a SaaS vendor.
Architecture: GrowthBook + SDK Layer
The core idea. You define features in GrowthBook (which users see them, what percentage, what attributes decide targeting). Your app imports the GrowthBook SDK, runs a quick local JSON lookup, and decides whether a feature is on. All decisions are client-side after the SDK fetches the flag state. No runtime API call per feature check.
Server setup. GrowthBook runs in Docker. You need a PostgreSQL database (included in Docker Compose) and a public HTTPS URL so your app can fetch the flag definitions. Full setup takes ~30 minutes: pull the repo, Docker Compose up, create a GrowthBook account, generate an SDK endpoint token. Hetzner cloud costs $4/mo; your total infra cost is basically free.
{`version: '3.8'
services:
growthbook:
image: growthbook/growthbook:latest
ports:
- "3000:3000"
environment:
MONGODB_URI: mongodb://mongo:27017/growthbook
JWT_SECRET: your-secret-key
mongo:
image: mongo:latest
volumes:
- mongo_data:/data/db
volumes:
mongo_data:`}Point your domain's DNS to the server IP, let's Encrypt handles HTTPS, and you're live.
The Money Pattern: React SDK
In your React app, import GrowthBook, instantiate it with your SDK endpoint token, and wrap your app with a provider:
{`import { GrowthBook, GrowthBookSDKProvider } from '@growthbook/sdk-react';
const gb = new GrowthBook({
apiHost: 'https://your-growthbook.com',
clientKey: 'sdk_your_token_here',
attributes: {
userId: user.id,
email: user.email,
plan: user.subscription.plan,
createdAt: new Date(user.created_at).getTime(),
},
});
export default function App() {
return (
);
}`}Then, anywhere in your component tree, use the useFeature hook:
{`import { useFeature } from '@growthbook/sdk-react';
export function AiBrainToggle() {
const aiBrainFeature = useFeature('ai_brain_v2');
if (!aiBrainFeature.on) {
return null; // Feature is off, don't render
}
return (
AI Brain (Beta)
Your conversational assistant for data analysis
{/* If percentage rollout is 20%, only 20% of users see this */}
);
}`}No API call per check. The SDK fetches flag definitions once on mount, caches them locally, and all subsequent checks are instant. Feature decisions are also sticky: if a user is in the 20% rollout, they stay in the 20% rollout even if they close and reopen the app (based on their user ID hash).
Rollout Patterns
Percentage rollout. You want to ship AI Brain to 10% of users first, monitor error rates and latency, then ramp to 100%. GrowthBook does this with one toggle. Set the feature to "on" with 10% of users, based on a hash of their user ID. After 48 hours, swap it to 50%. Three days later, 100%. If error rates spike at 50%, flip it back to 10% instantly. No deploy needed.
Attribute-based targeting. "Only show this to plan >= Pro". In GrowthBook, set a targeting rule: attributes.plan === "Pro" || attributes.plan === "Enterprise". The SDK evaluates this on the client; if the rule doesn't match, the feature is off. Perfect for gated features tied to billing tier.
Kill switch. You shipped a feature, it went to 100%, and suddenly Slack is on fire: "The AI Brain crashed when I uploaded a CSV". One click in GrowthBook: set the feature to 0%. Users see the feature disappear instantly (on their next page load or hard refresh). No revert commit, no rollback deploy, no incident post-mortem before you fix the code.
Real-World Velocity X Use Cases
Experiment A: AI Brain availability. Velocity X is rolling out a conversational AI assistant. Ship the code, enable the feature for 5% of paying users. Measure: prompt latency, error rate, session duration. If latency is <200ms and error rate is <0.5%, ramp to 50% the next day. 100% by the weekend. If error rate spikes to 5%, kill it and debug.
Experiment B: New dashboard tab. You built a "Insights" tab showing trading analysis. Ship it behind a flag. Rollout to 20% of users. Track: click-through rate, time spent, conversion to paid. After 7 days, check GrowthBook analytics. If CTR > 15%, ship to everyone. If CTR < 5%, kill it and iterate the design.
Experiment C: Pricing change. You want to test a new tier structure. Feature flag the pricing page to show variant B for 30% of traffic. GrowthBook tracks conversions tied to that flag. After 10 days of data, decide: does the new tier convert better? If yes, push to 100% and kill the old pricing page flag. If no, revert and try again.
Six FAQs
Doesn't this mean I ship broken code to production?
Yes, but behind a flag so no user sees it. The feature is code-reviewed, tested, and deployed in off mode. Once it ships, you control exposure via toggles. It's safer than big-bang deploys because you can ramp gradually and kill it with a single click if something's wrong.
What if my flag setup is wrong and the rule doesn't match anyone?
Test the rule in GrowthBook's UI before pushing it live. Assign your user ID to the test attribute and run a quick preview. See if the flag evaluates as expected. Most mistakes are caught in staging.
Doesn't self-hosting mean I'm on the hook for uptime?
Your GrowthBook instance needs to be up to define new flags, but the SDK caches flag state locally. If GrowthBook goes down for an hour, users keep seeing their cached flags—no feature disappears. For long outages (>24h), you'd want a backup, but for a $4/mo server it's fine to treat as "best-effort" staging infra, not critical path.
Can I test flags server-side?
Yes. GrowthBook has SDKs for Node, Python, Go, Java. Useful for toggling backend features (database queries, API endpoints, scheduled jobs). Fetch flag state in your server middleware, decide whether to run the experiment branch or the control.
How long should I keep a flag around?
Once a feature is stable (100% of users, no errors, >30 days), clean it up. Delete the flag from GrowthBook, remove the useFeature hook from your code, ship a new deploy. Keeping old flags clutters your feature list.
Can I run multiple experiments at once?
Yes. You can target different audiences with different flags. One flag runs for Pro users, another for free users. They don't interfere because they're separate rules. With ~3–5 independent flags you're fine; beyond that, you risk confounding effects.
The Bottom Line
Feature flags move risk off deploys by letting you ship code and control exposure separately. GrowthBook self-hosted on a $4/mo server gives you percentage rollouts, kill switches, and user targeting without paying LaunchDarkly's seat tax. For Velocity X, this is the difference between shipping features at midnight (big-bang panic) and shipping them at 9am with a percentage rollout (sleep well). If you're not using feature flags, you're gambling on every deploy. Do not gamble.
See the Velocity X pricing page for plans that include experimental features. For more on testing patterns, check A/B Testing on Static Sites.