harness feature flags

Harness feature flags: create, target, and roll out

TL;DR

Create your flag in the Harness UI under Feature Flags, add targeting rules per environment, then evaluate it from your app with the Harness SDK. Start with a boolean flag defaulting to off and roll out with percentage or targeted rules. Flags evaluate server-side per target and SDKs pick up changes without a deploy, which is the whole point.

harness feature flags

Steps

1. Set up a project and environments. In Harness, go to Feature Flags, create a project, and confirm your environments exist (for example dev and prod).

Expected: the environments are listed and selectable when you create flags.

1. Create the flag. Make a boolean flag (or multivariate if you need more than on/off) and leave the default variation off.

Expected: the flag appears in the flag list showing its default variation.

1. Add targeting rules. Serve the on variation to specific targets, segments, or a percentage rollout. Order matters: specific rules first, default last.

Expected: the rule summary shows exactly who gets which variation.

1. Wire up the SDK. Install the Harness SDK for your language, initialize it with the environment's SDK key from the environment settings, and evaluate the flag for a target in your code.

Expected: the SDK returns the expected variation for a test target.

1. Flip it live and verify. Toggle the flag in the UI and watch your app change behavior without a redeploy.

Expected: the variation changes within the SDK polling window.

Use this when

• Doing progressive delivery or percentage rollouts with Harness
• Adding a kill switch to a risky feature
• Running A/B tests backed by Harness flags

Not for this skill when

• You use an open-source flag tool (Unleash, Flagsmith, OpenFeature self-hosted)
• Migrating flag definitions from LaunchDarkly or Split specifically
• Harness CD pipeline failures (different product surface)
• Writing a custom flag evaluation engine from scratch

Variant phrasings

• harness ff getting started
• harness split feature flags
• how to use feature flags in harness
• harness flag targeting rules

Why it happens

Harness Feature Flags evaluates each flag against a target (a user, service, or custom identifier) on the server side, and SDKs poll or stream for updates. That split is why flipping a flag in the UI changes app behavior with no deploy: the decision point is the evaluation call, not the shipped code.

Edge cases

• SDK keys are per environment. Using the wrong environment's key silently evaluates the wrong rules.
• Flag changes take up to the SDK polling interval to propagate. It is not instant.
• Deleting a flag that code still references falls back to the SDK default. Set a sensible default before you delete.
• The audit log records who flipped what and when. Use it when a rollout surprises you.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__-IFSuNEPWhvqkWvmd4JoA