Feature Flags with OpenFeature and Flagsmith: Ship Safely in Production

Why Feature Flags Change Everything

Feature flags decouple deployment from release. You can deploy code to production without making it visible to users, then gradually roll it out, test it with specific segments, or kill it instantly if something goes wrong.

This enables:

• Trunk-based development: Everyone merges to main. No long-lived feature branches.
• Progressive rollouts: Show features to 1% of users, then 10%, then 50%, then 100%.
• Instant rollback: Toggle a flag instead of deploying a rollback.
• A/B testing: Show different variants to different user segments.

OpenFeature: The Standard

OpenFeature is a CNCF project that provides a vendor-neutral API for feature flags. Instead of coupling your code to a specific feature flag provider, you code against the OpenFeature SDK and swap providers without changing application code.

// Install OpenFeature SDK and Flagsmith provider
// npm install @openfeature/server-sdk @openfeature/flagsmith-provider

import { OpenFeature } from '@openfeature/server-sdk';
import { FlagsmithProvider } from '@openfeature/flagsmith-provider';

// Initialize with Flagsmith provider
const provider = new FlagsmithProvider({
  environmentKey: process.env.FLAGSMITH_KEY,
});
await OpenFeature.setProviderAndWait(provider);

// Get a client
const client = OpenFeature.getClient();

// Evaluate a boolean flag
const showNewCheckout = await client.getBooleanValue(
  'new-checkout-flow',
  false,  // default value
  { targetingKey: userId }
);

if (showNewCheckout) {
  renderNewCheckout();
} else {
  renderLegacyCheckout();
}

The beauty of OpenFeature: if you later switch from Flagsmith to LaunchDarkly or PostHog, you only change the provider initialization. All flag evaluations remain the same.

Flagsmith: Self-Hosted Feature Flags

Flagsmith is our recommended feature flag platform because it is fully open-source and self-hostable. At TechSaaS, we run it as a Docker container alongside our other services.

# docker-compose.yml
services:
  flagsmith:
    image: flagsmith/flagsmith:latest
    container_name: flagsmith
    restart: unless-stopped
    environment:
      DATABASE_URL: postgresql://postgres:secret@postgres:5432/flagsmith
      DJANGO_ALLOWED_HOSTS: "*"
      ALLOW_ADMIN_INITIATION_VIA_CLI: "true"
      FLAGSMITH_DOMAIN: flags.techsaas.cloud
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.flagsmith.rule=Host(`flags.techsaas.cloud`)"
      - "traefik.http.services.flagsmith.loadbalancer.server.port=8000"
    networks:
      - app-net
    mem_limit: 512m

Feature Flag Patterns

1. Release Flag (Boolean)

The simplest pattern. Show or hide a feature:

# Python example
from openfeature import api

client = api.get_client()

if client.get_boolean_value("dark-mode", False):
    enable_dark_mode()

2. Progressive Rollout (Percentage)

Roll out gradually to catch issues early:

Day 1: 1% of users (internal team)
Day 3: 10% of users (power users)
Day 7: 50% of users
Day 14: 100% of users

In Flagsmith, this is configured in the UI with percentage-based rules. The SDK handles consistent hashing so the same user always sees the same variant.

3. User Segment Targeting

Show features to specific user segments:

const context = {
  targetingKey: userId,
  plan: 'enterprise',
  country: 'US',
  betaTester: true,
};

const value = await client.getBooleanValue('advanced-analytics', false, context);

Flagsmith evaluates rules like "if plan is enterprise AND country is US, enable the feature."

4. Kill Switch

Every production feature should have a kill switch:

const enablePayments = await client.getBooleanValue('payments-enabled', true);
if (!enablePayments) {
  return res.status(503).json({
    message: 'Payment processing is temporarily unavailable'
  });
}

If your payment provider has an outage, toggle one flag instead of deploying code.

5. Configuration Flag (String/Number)

Use flags for runtime configuration:

const maxUploadSize = await client.getNumberValue('max-upload-mb', 10);
const maintenanceMessage = await client.getStringValue(
  'maintenance-banner',
  ''
);

Feature Flag Best Practices

Naming Convention

Use a consistent naming convention:

{team}.{scope}.{feature}

Examples:

• checkout.payment.apple-pay
• dashboard.analytics.new-charts
• api.rate-limit.premium-tier

Flag Lifecycle

Every flag should have an expiration plan:

The most common mistake: never cleaning up flags. Stale flags accumulate and become technical debt. At TechSaaS, we set calendar reminders to remove flags 2 weeks after they reach 100% rollout.

Testing with Flags

Test both flag states in your CI pipeline:

describe('Checkout Flow', () => {
  test('renders new checkout when flag is on', async () => {
    mockFlagValue('new-checkout-flow', true);
    const result = render(<Checkout />);
    expect(result.getByText('Express Checkout')).toBeTruthy();
  });

  test('renders legacy checkout when flag is off', async () => {
    mockFlagValue('new-checkout-flow', false);
    const result = render(<Checkout />);
    expect(result.getByText('Standard Checkout')).toBeTruthy();
  });
});

Provider Comparison

For self-hosted infrastructure like we build at TechSaaS, Flagsmith is the clear winner. It is free, open-source, and runs as a single container with PostgreSQL.

Feature flags are a foundational DevOps practice. If you are still using long-lived feature branches and big-bang releases, adopting feature flags will transform your deployment confidence. Start with a kill switch for your most critical feature, then expand from there.