Vercel added a vercel flags segments command to its CLI on July 3, 2026, letting teams create, update, and script the targeting groups behind feature flags without opening the dashboard. The command exposes flag targeting as something a CI pipeline or an autonomous agent can read and modify, with --json output and incremental --add and --remove tokens for composable edits. Who sees what can now live in version control, if a team decides it should.
What shipped on July 3
Vercel shipped vercel flags segments as the terminal surface for managing Flags segments, the reusable targeting groups that Vercel Flags uses to decide which users a flag applies to, according to the company’s changelog. Segment targeting until now lived primarily in the dashboard; the CLI command moves create, update, and inspection into scriptable commands.
Segment membership composes from three repeatable tokens, per the same announcement:
include:for exact-value membership, such as a specific user IDexclude:for removal from the segmentrule:for condition-based targeting against an attribute and an operator
These tokens go to --add or --remove for incremental edits, or to --data for a full JSON replacement of the segment definition. Every segment command accepts --json for structured output, which is the hook for CI and agent-driven pipelines that need to inspect or mutate targeting from a shell.
What a Vercel Flags segment actually is
A segment is a reusable targeting group that updates across every flag referencing it when it changes, per Vercel’s segments documentation. The distinction from per-flag rules is the point: instead of pasting the same “enterprise users on plan X” condition into five flags, you define it once as a segment and reference it wherever needed. Edit the segment and every consuming flag picks up the change in one operation.
Vercel Flags supports boolean, string, number, and JSON flag variants for feature gates, experiments, and structured configuration, per Vercel’s Flags overview. Segments sit on top of those variants as the targeting layer, the “who” before the “what” a flag serves. A boolean flag gates a release on or off; a segment decides which audience the gate applies to before the variant is even chosen.
Rule conditions compare an entity attribute against a value, per the segments documentation. The documented operators are equals and does not equal, contains and does not contain, starts with and ends with, and is one of / is not one of for lists, with multiple conditions combinable through AND or OR logic. The CLI surfaces those comparisons through the rule: token; the changelog example uses eq (rule:user.plan:eq:enterprise).
Creating, updating, and deleting segments from the CLI
Segment CRUD maps to four operations: create, update, inspect through --json, and delete, with deletes gated on active references. The changelog ships two example flows. The first creates a segment and seeds it with two specific users:
vercel flags segments create beta-users \ --label "Beta users" \ --add include:user.id=user_123 \ --add include:user.id=user_456The second adds a rule and removes a user in one update:
vercel flags segments update beta-users \ --add rule:user.plan:eq:enterprise \ --remove include:user.id=user_123The token format is kind:attribute.path:operator:value for rules and kind:attribute.path=value for includes and excludes. Multiple --add and --remove flags compose within a single invocation, so the update path is additive rather than whole-object. For a full rewrite, --data takes the complete segment definition as raw JSON and replaces it.
Deletion carries a documented edge. Segments cannot be deleted while referenced by flags or by other segments, per the CLI flags reference; a delete script has to inspect the reference graph and clear dependencies first. There is no documented cascade or force flag, which means cleanup is a two-step operation the operator owns.
Why a CLI for segments matters now
A feature-flag CLI is table stakes for the incumbents; the reason to notice Vercel’s is timing. The release lands as autonomous agents increasingly touch rollout state, turning scriptable controls from a convenience into a governance prerequisite. A LinkLoot analysis published July 7, 2026 made the case directly: the CLI path lets teams put a review gate in front of agents or scripts before they update production targeting, rather than discovering the change after the fact in a dashboard audit log.
That reframes what the --json flag is for. It is not just tidy output. It is the contract that lets an agent read current targeting, propose a diff, and write back through a pipeline that can require human approval, run tests against the proposed segment, or block if the change widens exposure past a threshold. None of that gating ships inside the CLI. It is what the CLI makes possible once you wrap it in CI.
The dashboard-only alternative has no comparable seam. An agent that wants to change targeting through a UI has to either drive the UI or call an undocumented internal API, and neither produces a reviewable artifact. The CLI gives the change a text representation that diffs cleanly and commits to Git, which is the difference between an auditable change and an event in a log.
Where Vercel’s segment CLI still trails the incumbents
Vercel’s CLI surface for segments is CRUD plus --json. Create, update, inspect, and delete, with the reference-check on delete as the one documented governance behavior. That is enough to script targeting, and it is enough to put a Git review in front of changes. It is not the governance surface the established flag vendors market.
LaunchDarkly’s platform documentation foregrounds capabilities Vercel’s CLI release does not address: enterprise-scale governance framed around “guardrails and permissions” for building, automating, and scheduling releases, and a flag delivery architecture that LaunchDarkly says propagates changes in 200 milliseconds worldwide. The company positions SDKs as the primary integration path for application code. Vercel’s value proposition, by contrast, is that the flag system and the deployment platform share one account, one project boundary, and one CLI binary, which is the integration story LaunchDarkly has to meet through SDKs and partner connectors.
One question the announcement does not resolve: whether Vercel plans to add approval or governance controls to the CLI. The environment story is already documented. Per the segments documentation, segments exist in all environments (Production, Preview, Development), and per-environment targeting requires separate named segments, such as “Beta Users - Production”, rather than a single segment with environment-conditional rules.
A review-gate pattern for scripted segment changes
Treat segment definitions as checked-in code and route every change through a pull request; that is the review gate the CLI enables and the dashboard cannot. The repository holds the desired segment state as JSON, produced by vercel flags segments --json. A CI job diffs the checked-in state against the live state, and the PR merges the diff. The CLI apply step runs only on merge, not on commit, which is what creates the gate.
A minimal pipeline has three stages. First, a render stage exports the current segment with --json and writes it to the repo so reviewers see the baseline. Second, a plan stage runs the proposed update as a dry comparison, surfacing which flags the change touches before it lands. Third, an apply stage runs vercel flags segments update after merge, scoped to the production project. Because deletes are blocked while references exist, the apply stage also needs a pre-check that lists dependents and fails loudly if any remain, rather than letting the delete error out mid-pipeline.
That structure answers the ownership question the dashboard model leaves open. Whoever merges the PR owns the change, and the merge commit is the audit record. An agent can open the PR and propose the segment edit, but it cannot ship targeting to production without the review the repository requires. That is the governance property worth the operational cost.
The cost is real. Segment scripts need version pinning against the CLI release, the token needs scoped credentials that can touch flags but not the rest of the project, and someone has to own the reference-graph cleanup before deletes. None of that ships in the box. What ships is the ability to make targeting a reviewed artifact, which is the part that was missing.
Frequently Asked Questions
Which comparison operators does the CLI accept in segment rules?
Beyond the equals/contains family the changelog highlights, the CLI reference documents eq, !eq, oneOf, !oneOf, containsAllOf, containsAnyOf, containsNoneOf, startsWith, endsWith, contains, !contains, ex, !ex, gt, gte, lt, and lte. That gives you numeric range rules and richer set operations than the dashboard example suggests.
How does this differ from LaunchDarkly’s segment tooling?
LaunchDarkly has offered CLI and Terraform-based segment management for years, plus marketed governance controls like guardrails, permissions, and scheduled releases. Vercel’s release matches the CRUD and JSON-export basics, but approval gates, dependency graphs, and role-based access have to be built in CI rather than configured inside the flag product.
What credentials and access scope should a CI job use?
The CLI needs a Vercel token that can write flags for the target project, but nothing else. Best practice is to scope the token to flags only and store it as a repository secret, because a compromised token could add users to production segments or remove blocks across every flag that references a shared segment.
What might force a team off dashboard-only segments?
The tipping point is usually agent-driven changes. The dashboard produces an audit log after the fact; the CLI produces a text diff that can sit in a pull request, pass tests, and require human approval before merge. Once scripts or agents touch targeting, reviewable artifacts become a prerequisite rather than a convenience.
Can the CLI promote a segment across environments?
No. Segments exist in all environments by default, and per-environment targeting requires separate named segments like “Beta Users - Production”. There is no documented promote or copy command, so environment drift has to be managed by keeping environment-specific segment files in version control and applying them separately.
