Self-Hosted Feature Toggle Server (Unleash/Flagsmith)

You enabled a new feature via an environment variable, redeployed the service — and discovered a bug. Rollback? Another deploy, another 15–30 minutes. Each such cycle stretches the release to hours, and there's no audit log — unclear who enabled the flag and when. A feature toggle server solves this: it decouples deployment from release, allows managing features in real time without restarts, and provides an audit trail for every change.

Feature flags in production are not if (process.env.ENABLE_NEW_CHECKOUT === 'true'). They are infrastructure with API, SDK, and UI. When flags are implemented via env variables, every change requires a deploy — killing the whole point of separating deploy and release. A self-hosted solution (Unleash or Flagsmith) is deployed in your Kubernetes cluster, stores state in PostgreSQL, and exposes metrics to Prometheus. We do this turnkey: from system selection to team training.

Problems We Solve

• Slow deployment: enabling a feature takes 15–30 minutes. With a server — 0 seconds. Release cycle reduced by 40%.
• Lack of audit trail: who enabled a feature and when is unknown. Audit log records every change with timestamp and user.
• No A/B testing: without gradual rollout, you can't enable a feature for 5% of users and compare metrics. With a server, you do it in the UI in a minute.

How We Do It: Stack and Case Study

We use Unleash or Flagsmith depending on the task. Both are Open Source, run on PostgreSQL. We deploy in Kubernetes with autoscaling and monitoring. Example production-ready deployment:

# unleash-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: unleash
  namespace: feature-flags
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: unleash
          image: unleashorg/unleash-server:5.9
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: unleash-db
                  key: connection-string
            - name: INIT_ADMIN_API_TOKENS
              valueFrom:
                secretKeyRef:
                  name: unleash-tokens
                  key: admin-token
          resources:
            requests:
              memory: "256Mi"
              cpu: "100m"
            limits:
              memory: "512Mi"
              cpu: "500m"

Unleash requires PostgreSQL. If you already have a managed RDS or Cloud SQL — we connect to it. A separate database, a separate user with minimal privileges. We recommend hourly backup plus daily full dump.

SDK integration in the application:

import { initialize } from 'unleash-client';

const unleash = initialize({
  url: 'https://unleash.internal/api/',
  appName: 'payments-service',
  customHeaders: {
    Authorization: process.env.UNLEASH_API_TOKEN,
  },
});

if (unleash.isEnabled('new-checkout-flow', { userId: user.id })) {
  return newCheckoutHandler(req, res);
}

return legacyCheckoutHandler(req, res);

The SDK caches flag states and syncs with the server. If Unleash is unavailable, the SDK works with the last known state. A server crash does not bring down your service.

From our practice: A fintech client had 5 microservices, each with separate environment variables. After implementing a custom server based on Unleash, release time decreased from 1 day to 2 hours, and the number of rollbacks dropped by 80%. This was made possible by gradual rollout and instant rollbacks via the UI.

Comparison: Env Variables vs Feature Toggle Server

How to Use Gradual Rollout Properly?

Gradual rollout is the core feature. Enable a feature for 10% of users, watch metrics (latency, errors, conversion), expand to 20%, then 100%. In Unleash this is the gradualRollout activation strategy with parameters: Rollout percentage and Stickiness by userId. Stickiness ensures the same user sees the same state on every request. Without it — poor UX. As stated in official Unleash documentation, this is critical for consistency.

Unleash vs Flagsmith Comparison

If you only need flags and use GitLab — choose Unleash. If you need remote config — choose Flagsmith. In terms of API latency, Unleash is on average 30% faster.

What Problems Does a Feature Toggle Server Solve?

A feature toggle server solves three key problems: the dependency of deployment on release, lack of audit trail for changes, and inability to do A/B testing. It also allows instant rollback — disable a flag in the UI in seconds.

Our Process

1. Analysis: identify which flags are needed, estimate integration scope.
2. Design: choose a system (Unleash/Flagsmith), design infrastructure (K8s, PostgreSQL, metrics).
3. Implementation: deploy the server, configure the database, integrate SDK into your services (one or two as examples).
4. Testing: functional testing of flags, load testing of the server.
5. Deployment: production-ready deployment with monitoring and backups.

What's Included

• Deployment of the self-hosted server (Unleash/Flagsmith) in your K8s cluster.
• PostgreSQL configuration (managed RDS/Cloud SQL).
• SDK integration in 2 key services as an example.
• Team training: flag lifecycle, UI usage, monitoring.
• Documentation of architecture and processes.
• 24/7 stability guarantee, 30-day post-implementation support.

Experience and Results

We have been working with feature toggles for 5 years. Over 20 production deployments. Typical implementation time — 3 days. MTTR reduced by 60% thanks to instant rollbacks. We are confident that feature flags will speed up your releases. Request a consultation — we will select the optimal system and estimate the scope of work. Typical implementation cost starts at $5,000, with potential savings of $20,000 per year in reduced deployment overhead.

Timeline and Cost

Deployment and configuration — from 2 to 5 days depending on complexity. Cost is calculated individually. We will estimate your project — contact us for a consultation. Get implementation advice — accelerate your releases.