# Vercel Edge Config and Feature Flags: A Guide to Sub-Millisecond Configuration

> Learn how Vercel Edge Config enables sub-millisecond feature flags and global configuration reads at the edge — architecture, use cases, and integration patterns explained.

- **Published:** 2025-07-21
- **Author:** Clixo
- **Reading time:** 6 min read
- **Tags:** vercel, edge-config, feature-flags, edge-functions, cloud-infrastructure
- **Canonical URL:** https://clixo.sh/blog/vercel-edge-config-and-feature-flags-guide

Feature flags backed by a remote API call have a latency problem. Every request that reads a flag value to decide what to serve is waiting on a network round-trip — to LaunchDarkly, to your database, to wherever the flag value lives. At the edge, that round-trip defeats the purpose of running code close to users. Vercel Edge Config solves this by making configuration data readable at the edge with sub-millisecond latency — no origin call required.

## What Vercel Edge Config Is

Edge Config is a globally distributed key-value store built into Vercel's edge network. Configuration values are replicated to every edge location where your functions run. Reads happen in memory at the local PoP — they do not traverse the network.

The result is configuration reads that take under 1ms regardless of where the edge function is executing. This is fast enough to use on every request without meaningfully impacting response latency.

Writes to Edge Config, however, are not real-time in the traditional sense. Updates propagate to edge nodes within roughly 300ms globally. For feature flags and configuration values that change deliberately (not continuously), this propagation delay is acceptable.

## Architecture: How Edge Config Works With Edge Middleware

The most common pattern is reading Edge Config values in Vercel Middleware — the file that runs on every request before any other code executes.

```mermaid
sequenceDiagram
  participant U as User
  participant MW as "Edge Middleware"
  participant EC as "Edge Config"
  participant O as Origin
  U->>MW: HTTP request
  MW->>EC: get flag value
  EC-->>MW: value in under 1ms
  MW->>MW: evaluate routing rules
  MW->>O: forward or rewrite request
  O-->>MW: response
  MW-->>U: final response
```

```
// middleware.ts
import { NextResponse } from "next/server";
import { get } from "@vercel/edge-config";

export async function middleware(request) {
  const maintenanceMode = await get("maintenance_mode");

  if (maintenanceMode === true) {
    return NextResponse.rewrite(new URL("/maintenance", request.url));
  }

  return NextResponse.next();
}
```

This middleware reads a flag value on every incoming request. Because Edge Config reads are in-memory at the local PoP, this adds negligible latency compared to skipping the check entirely.

The same pattern extends to:
- A/B test variant assignment
- Gradual feature rollouts
- Geolocation-based content decisions
- Kill switches for specific features

## Use Cases Where Edge Config Fits

### Feature Flags at the Routing Layer

Feature flags implemented at the middleware layer run before any page or API route logic. This means you can redirect users to a different URL, serve a completely different page, or short-circuit API calls based on a flag — without any flag evaluation cost in your application code.

This is faster and simpler than SDK-based feature flag tools for routing-level decisions. It is not a replacement for rich experimentation platforms (LaunchDarkly, Split, etc.) that track exposures and support complex targeting rules, but for simple on/off flags and redirect logic, Edge Config is sufficient.

### Maintenance Mode and Traffic Routing

Edge Config is ideal for kill switches that need to activate globally within seconds. Pushing `maintenance_mode: true` to Edge Config propagates to all edge nodes within 300ms. Your middleware reads it on the next request and serves a maintenance page without hitting your origin at all.

This is faster than a DNS change, more reliable than a CloudFront behavior update, and deployable from a dashboard without a code push.

### A/B Test Assignment

For simple A/B tests where variant assignment is random or cookie-based, Edge Config can hold the experiment configuration (variant weights, start/end dates, eligible routes). The middleware assigns the variant, sets a cookie, and routes the request accordingly.

For statistically valid experimentation requiring exposure tracking and analysis, you still need a dedicated experimentation platform. Edge Config handles the routing and configuration; event tracking goes to your analytics system.

### Rate Limiting Thresholds and Allow/Block Lists

Edge Config can store configuration that changes your rate limiting behavior — request limits per IP range, blocked user agents, allowed API key prefixes. Reading these values in middleware at sub-millisecond cost means you can enforce dynamic limits without adding network latency to every request.

## Setting Up Edge Config

Edge Config is available on Vercel Pro and Enterprise plans. Setup:

1. Create an Edge Config store in the Vercel dashboard
2. Connect it to your project under Project Settings
3. Install the SDK: `npm install @vercel/edge-config`
4. Read values in middleware or edge functions using `get`, `getAll`, or `has`

To write values to Edge Config programmatically (from a deployment hook, a CI pipeline, or an admin dashboard), use the Vercel API:

```
PATCH https://api.vercel.com/v1/edge-config/{edgeConfigId}/items
Authorization: Bearer {token}

{
  "items": [
    { "operation": "upsert", "key": "feature_checkout_v2", "value": true }
  ]
}
```

This API call updates the value in Edge Config and triggers propagation to all edge nodes.

## Limits and Constraints to Know

- **Read latency:** Under 1ms at the edge PoP. Reads in server-side Next.js routes (not middleware/edge functions) go over the network and have standard API latency.
- **Write propagation:** Roughly 300ms global propagation after a write via the API.
- **Value size:** Individual values have a size limit; the store has an overall size limit. Edge Config is not a database — keep values small and flat.
- **Read-heavy design:** Edge Config is optimized for reads, not writes. If your configuration changes more than a few times per minute, Edge Config is not the right tool.
- **Not for user-specific data:** Edge Config is global configuration, not per-user state. Do not put user data in Edge Config.

## Combining Edge Config With Other Feature Flag Systems

A practical pattern for teams with an existing feature flag platform (LaunchDarkly, Split, Statsig):

- **Edge Config** holds the routing-layer flags — kill switches, maintenance mode, A/B test routing — that must be evaluated on every request with sub-millisecond overhead
- **The feature flag SDK** runs in your application code for user-targeting, percentage rollouts, and experiment tracking that require richer targeting rules and event logging

This layered approach keeps the edge layer fast and simple while preserving the analytical capabilities of a full experimentation platform for application-level decisions.

## When to Choose a Different Approach

Edge Config is the right tool when:
- You need configuration reads in Vercel Middleware or Edge Functions
- The configuration changes deliberately, not continuously
- Values are small and few (dozens to low hundreds of keys)

Consider alternatives when:
- You need user-level targeting with complex rules — use a dedicated feature flag SDK
- You need configuration with sub-second write propagation — Edge Config's 300ms window may be too slow for fast-moving state
- Your application does not run on Vercel — Edge Config is Vercel-specific

Edge Config is one of the more underused features in the Vercel platform. For teams already running on Vercel, it is a low-effort way to add fast, globally consistent configuration to middleware and edge functions without adding an external service.

If you are building a Vercel-based platform and want the edge layer designed to take full advantage of what the platform offers, [talk to Clixo](https://clixo.sh/#contact). We build production Next.js systems from routing layer to data layer.

---

Clixo · 1141 W Bryn Mawr Ave, Itasca, IL 60143, US · [hello@clixo.sh](mailto:hello@clixo.sh)
[Start a build](https://clixo.sh/#contact) · [All services](https://clixo.sh/services) · [Agent guide (llms.txt)](https://clixo.sh/llms.txt)