Everything you need to ship confidently
No credit card required
Catch mistakes before your users do
Most configuration mistakes are small: a number off by one digit, a missing field from a JSON document, a URL without HTTPS. ConfigDirector checks every change against your validation rules and prevents changes that would break your application.
Deliver the configuration values your application needs
Enforce validation and reduce application errors when values are updated. Every config has a fine-grained type: Integer, Float, Timespan, URL, Enum, JSON and more.
- Set the constraints that match what your application expects, like minimum and maximum values, HTTPS-only URLs, or an allowed set of values
- ConfigDirector enforces them on every change, in every environment, before anything is saved
- Validations apply everywhere a value can change: the dashboard, the Admin API, Terraform, and the MCP server
Don't have a bad day. JSON Schema validations can prevent costly configuration update mistakes.
JSON configs are very flexible, which makes them powerful but also risky.
- Validate your JSON configs with a JSON schema
- Every update to the JSON config is validated against the schema before accepting the change
- Leverage the power of JSON schemas to prevent a missing field, incorrect types, unexpected keys, etc
- Safely retrieve the JSON config as an object via our SDKs
Rename a config that's already in use. Nothing breaks.
You don't always come up with the best name on the first try. When renaming is tedious, outdated names proliferate.
We fixed it.
- You can safely rename config keys in ConfigDirector without breaking your application
- When you rename, the config responds to both, the new and the old name
- You update the referencing code at your leisure
- Once ConfigDirector detects the old name is no longer being requested in any environment, it cleans it up automatically
Deliver the right configuration to the right audience
Reduce release risk with phased feature rollouts. Every config and feature flag can be targeted to users and segments, split, and rolled out gradually on a percentage basis.
Targeting rules
- Compare text, numbers, dates, arrays, semantic versions, and more
- Combine multiple conditions into targeting rules, with a default for everyone else
- Each environment can have its own rules to help with thorough testing
User context targeting
Target users and segments by any attribute your application knows.
- Target by user ID, name, plan, region, or any custom trait passed through the SDK
- Rules can also match on application metadata like name and version
Gradual rollouts
Roll out any config or flag to a percentage of users, then increase it as confidence grows.
- Consistent user assignment based on context ID
- Users in your first 10% stay in that treatment when you scale to 20%, 50%, and 100%
- Consistent assignment across devices and SDKs, any given user receives the same treatment regardless of device
A/B testing
Experiment configs let you enumerate named variations of a value.
- Split traffic between variations by percentage or conditional rules, or combine both
- Read the experiment value in your code like any other config
- Track variation assignment with the activity graphs
See which rule wins, before you save
Search for a context your application has already sent, or enter one in. The tester walks your draft rules the way production would and shows you the result. See how the tester works
- Every rule is highlighted as matched, not matched, or not evaluated, with the reason why
- Percentage rollouts show the attribution bucket the identifier landed in and which rollout percentage share it fell into
- Edits are evaluated as you type, so you can test the rules in real time before saving
Know how every value is used
Monitor how configs and feature flags are evaluated. Fine-grained visibility to help you validate and adjust.
- See how often each config is evaluated and the breakdown of values served
- Track usage by application and version, or by SDK used
- Confirm a rollout is behaving as you expected before expanding it
Know when a flag is ready to be removed
Temporary configs and flags let you know when it's time to clean up.
- When a temporary flag has been enabled in production for a while, you'll get an alert to remove it from your code
- Configs and flags no longer evaluated in any environment become ready for archival to help you keep things tidy
Stay on top of issues before they break things
ConfigDirector's telemetry data is monitored to alert you of potential issues.
- Our SDKs are designed to not fail at runtime, and gracefully fall back to the in-code provided default
- Inconsistencies between the in-code default and targeting rules are detected and alerted on
- If the code is requesting a config as an incompatible type, we'll let you know
- Get notified of applications using an outdated SDK
Control who changes what, automate the rest
Audit log
Every change to a config or flag is recorded.
- See what was updated, when, and by whom
- Track down rogue automation, our audit log will tell you if a change came from the dashboard, Terraform, the API, or the MCP server
- Any user can review the history, a surprising value is never a mystery
Role-based access control
Assign each user a role with the access they need.
- Thoughtful roles with strategic permissions to keep things simple
- Unlimited seats, free or paid, so nobody shares a login
MCP server
Let the coding assistant already in your editor create configs and feature flags, roll them out, and check what is live.
- Hosted, nothing to install
- Works with Claude Code, Cursor, VS Code, and more
- API tokens carry fine-grained permissions, so a read-only token produces a read-only assistant
Terraform & OpenTofu providers
Define projects, environments, configs, and targeting rules as code.
- Review changes to configs and feature flags in pull requests
- Apply them with the same tooling as the rest of your infrastructure
From zero to production ready in 5 minutes
$ npm install --save @configdirector/client-sdkimport { createClient } from "@configdirector/client-sdk";
export const client = createClient("YOUR-CLIENT-SDK-KEY");
await client.initialize();
const enabled = client.getValue(
"new-onboarding-flow",
false // default fallback
);