FeatureSignals
SOC 2 Type IISub-ms LatencyOpenFeature NativeApache 2.0

Feature flags for every stage of delivery.

From canary releases to kill switches — see how engineering teams use FeatureSignals to ship safer and faster, with zero added latency and complete control.

Release Pipeline

checkout-redesign · production

1% Canary

Internal team + beta users

Done

10% Rollout

10% of US traffic

Done

50% Rollout

50% of all users

In Progress

100% Launch

Remove flag, archive code

Pending
Progressive Delivery

Roll out features gradually. Stop bad releases instantly.

Deploy code to production behind a feature flag, then progressively expose it to users. Start with internal teams, expand to beta users, then dial up to 100% — all without a redeploy.

How it works

1

Deploy new code behind a feature flag — off by default.

2

Roll out to 1% of users. Monitor error rates, latency, and business metrics.

3

Increase rollout: 10% → 50% → 100%. Adjust at any time without a redeploy.

4

If something breaks, kill the flag in one click. Issue resolved in seconds.

5

Once fully launched and stable, the AI Janitor removes the stale flag code.

Sub-millisecond evaluation means zero added latency

Percentage Rollout

Consistent hashing · MurmurHash3

Rollout percentage42%
0%25%50%75%100%

10.5K

Users receiving

14.5K

Users not receiving

Kill Switch
One click to disable

Canary Target

Beta users + EU region · ~5% of traffic

user.groupeqbeta

Internal testers and early adopters

user.regioneqEU

European data center users only

user.planin["pro", "enterprise"]

Exclude free-tier users

0.12%

Error Rate

42ms

p95 Latency

99.98%

Crash Free

Canary Releases

Test in production with real users

Staging environments can't replicate production traffic patterns. Canary releases let you validate new features with a small subset of real users before going wide — with automatic rollback if metrics degrade.

How it works

1

Target a specific cohort: internal users, beta testers, or a geographic region.

2

Route a small percentage of production traffic to the new feature path.

3

Monitor error rates, latency, and business metrics against the control group.

4

Gradually expand the canary group as confidence increases.

5

Automated rollback via webhook if health checks fail — no human intervention needed.

Learn more about canary releases
Kill Switch

Emergency off-switch for any feature in production

When a feature causes issues in production, you don't have time for a rollback pipeline. Kill switches give you instant control — one click, API call, or automated trigger disables the feature globally.

How it works

1

Every flag is a kill switch. Toggling off instantly returns the default value to all SDK consumers.

2

Kill via dashboard, API, or automated webhook trigger from your monitoring stack.

3

Graceful degradation: SDKs receive the off state and your application handles it with sensible defaults.

4

Every kill action is audit-logged with before/after state, user, and timestamp.

5

Notify your team via Slack, Datadog, or PagerDuty — webhooks fire on every kill event.

Kill actions propagate to all SDK instances in under 100ms

Active Kill Actions

Audit trail · Last 24 hours

checkout-redesignKilled

jane@acme.com · 8 min ago

Error rate spike to 2.3% in canary group

search-ml-v2Killed

automation (Datadog) · 47 min ago

p95 latency exceeded 500ms threshold

new-onboardingRestored

mike@acme.com · 2 hours ago

Root cause identified and patched

A/B Experiment

pricing-page-v2 · 3 variants · 50/30/20 split

Control
50% · 2.1%
Variant A
30% · 3.8%+81%
Variant B
20% · 2.4%+14%

48.2K

Impressions

1,204

Conversions

2.5%

Conv. Rate

A/B Testing

Measure what moves your metrics

Ship hypotheses, not guesses. Run A/B experiments directly on your feature flags with weighted variant assignment, impression tracking, and per-environment configuration. No separate experimentation tool required.

How it works

1

Create an A/B flag with multiple variants and weighted distribution.

2

Users are deterministically assigned to a variant via MurmurHash3 — consistent across sessions.

3

Fire impression events from your application to track which variant each user sees.

4

Measure conversion events against variant assignments to calculate lift.

5

Combine with targeting rules to run segmented experiments on specific user cohorts.

Learn more about A/B testing
Migration

Switch from LaunchDarkly without rewriting your codebase

The Migration Engine imports your flags, environments, segments, and targeting rules in minutes. OpenFeature-native SDKs mean this is the last migration you'll ever need — future provider changes are a one-line config switch.

How it works

1

Connect to your existing provider via API key — LaunchDarkly, ConfigCat, Flagsmith, or Unleash.

2

Run a dry-run preview. See exactly which flags, segments, and rules will be created.

3

Review the migration plan. Operator mappings, strategy translations, and edge cases are surfaced.

4

Execute the migration. All configuration is imported while your existing provider stays live.

5

Swap your SDK initialization to FeatureSignals. OpenFeature means a single config change.

Learn more about migration

Migration Path

Zero-downtime switchover

LaunchDarklyFeatureSignals
142 flags12 segments3 envs
ConfigCatFeatureSignals
67 flags5 segments2 envs
FlagsmithFeatureSignals
38 flags8 segments3 envs
OpenFeature-native SDKs — future migrations are a one-line config change

GitOps Workflow

PR #312 · feat: add holiday-promo flag · Open

Terraform Configuration

resource "featuresignals_flag" "holiday_promo" {
key = "holiday-promo"
name = "Holiday Promotion 2026"
type = "boolean"
environments = ["staging", "production"]
}

CI/CD Pipeline

Terraform Plan — 3 resources, 0 changes
Policy Check — All approval rules passed
Drift Detection — No drift detected
GitOps

Manage flags as code. Review, approve, deploy.

Treat feature flags like the rest of your infrastructure. Version flag configurations in git, review changes through pull requests, and apply through your existing CI/CD pipeline — with full drift detection.

How it works

1

Define flag configurations as code using Terraform, Pulumi, or Ansible providers.

2

Open a pull request. Your team reviews flag changes alongside application code.

3

CI/CD runs a plan: see exactly which flags will be created, modified, or removed.

4

Merge and apply. Flag state is synchronized with your infrastructure.

5

Drift detection continuously monitors for discrepancies between IaC and live state.

Learn more about GitOps
Enterprise Governance

Ship fast without compromising compliance

Enterprise-grade access controls, audit logging, and compliance readiness — so your platform team can enable developers without losing control. SOC 2, GDPR, and HIPAA ready.

How it works

1

Assign roles: Owner, Admin, Developer, Viewer — with per-environment permission scopes.

2

Enable change approval workflows for production environments. Configurable reviewer pools.

3

Every action is logged: flag creation, toggle, targeting change, approval — with before/after diffs.

4

Integrate with your identity provider via SAML/OIDC SSO. Enforce MFA across your organization.

5

Restrict access by IP range, provision users via SCIM, and create custom roles for your needs.

Learn more about enterprise governance

Role-Based Access

Per-environment permissions · 4 built-in roles

PermissionViewerDeveloperAdminOwner
View flags
Toggle flags
Edit rules
Manage segments
Approve changes
Manage billing
SOC 2 Type IIGDPRHIPAASSO (SAML/OIDC)SCIMMFAAudit Logs

Ready to ship safer and faster?

Join engineering teams that use FeatureSignals for progressive delivery, canary releases, A/B testing, and more. Start free — no credit card required.

Free forever for up to 50 flags. No credit card required. Open source under Apache 2.0.