Column

If you've deployed a Next.js app on Vercel for more than a few months, there's a good chance you've reached for Edge Config without fully noticing it: a feature flag that toggles a banner, an A/B test weight, a maintenance-mode switch, a list of blocked IPs. It's one line of get() calls in middleware, and Vercel handles the rest — a globally replicated, low-latency key-value store with no database to provision. The moment you move that same app onto your own Kubernetes cluster, those get() calls still compile, but there's nothing behind them. That gap is easy to miss until a feature flag silently returns undefined in production.

What Edge Config Actually Does

Edge Config is a read-optimized key-value store built into Vercel's platform, designed to be read from Edge Middleware and Edge Functions with sub-millisecond latency. It's not a general-purpose database — Vercel explicitly positions it for small, frequently-read, infrequently-written data: feature flags, redirects, A/B test buckets, and configuration that needs to change without a redeploy.

The appeal is operational, not just technical. There's no connection pool to manage, no region to pick, and no separate service to monitor — it's just part of the Vercel runtime. That's exactly the kind of convenience that doesn't survive a move to standard Kubernetes, where every piece of infrastructure is something your team provisions and keeps running.

Why This Breaks Silently, Not Loudly

Unlike a missing environment variable, which usually throws at build time or fails fast on a missing process.env read, a missing Edge Config client tends to fail quietly. The Vercel SDK's get() function returns a Promise that resolves to undefined if the store can't be reached, and most feature-flag code is written defensively around that — if (flag) { ... } just skips the feature instead of crashing. On Vercel, that defensiveness is a safety net. Off Vercel, it's a trap: every flag quietly evaluates to its default, and nothing in your logs says why.

This is where most teams discover the dependency only after shipping: a redirect rule that worked in staging (still on Vercel) doesn't fire in the self-hosted production cluster, or a kill-switch meant to disable a flaky integration does nothing because the client it's calling never had a config source to connect to.

Replacing It: Three Approaches That Actually Work

1. Redis (or any managed key-value store) behind a thin client. This is the closest architectural match to Edge Config — same read pattern, same low-latency expectations, same "someone else runs the flags" trust model, except now it's your Redis instance instead of Vercel's. The tradeoff is real: Redis needs memory sized for your working set, a persistence strategy if the flags matter after a restart, and — critically — enough replicas that a single pod restart doesn't blank out every flag at once.

2. A config file baked into the container image, reloaded via rolling deploy. For flags that change a few times a week rather than a few times a minute, this is the boring, reliable option: a JSON file loaded at startup, with changes shipped through the same CI/CD pipeline as the rest of the app. No new infrastructure, no new failure mode — just a slightly slower change cycle, since updating a flag means a deploy instead of an API call.

3. A dedicated feature-flag service (self-hosted or managed). Tools like Flagsmith or Unleash exist specifically to fill this gap, and they add things Edge Config doesn't attempt — percentage rollouts, user targeting, audit logs of who flipped what and when. They're worth the extra moving part once flag logic outgrows a flat key-value lookup, but they're also one more stateful service for your cluster to keep healthy.

Whichever you pick, the common thread is that the read needs to stay fast and cheap, because middleware runs on every request. A flag lookup that adds 50ms to every page load erases whatever Edge Config was buying you in the first place, so most production setups put a short-lived in-memory cache in front of whichever store you choose, refreshing every few seconds instead of hitting Redis (or the file, or the flag service) on every single request.

Where the Cluster Comes In

None of these three options are hard to run in isolation — a Redis pod, a ConfigMap, or a small flag-service deployment are each a weekend of setup. What's harder is making sure they stay available under the same load your Next.js pods see, and that scaling one doesn't starve the other. If your middleware is calling out to Redis on every request and traffic spikes 5x during a launch, both the app pods and the config store need to scale in step, not just the app.

That's the kind of coordination standard Kubernetes is built for — but only once the cluster itself is sized and running. Picking the right cluster shape before you build that dependency graph saves a second migration later: teams that start with a single over-provisioned node tend to end up re-deciding which Kubernetes distribution fits their scale right around the time Redis and the app start competing for resources.

Kubo gives you that standard Kubernetes environment — the same APIs you'd use to run Redis, a flag service, or a config ConfigMap alongside your app — without spending the first few weeks of a migration just getting a cluster to a reliable baseline.

Picking the Right Replacement for Your Flags

If you're weighing which approach fits, the deciding factor is usually change frequency, not scale. Flags that change a few times a year belong in a config file. Flags that change a few times a day belong in Redis or a flag service. Few teams need all three at once — most are well served by picking one and being consistent about it, rather than scattering flag logic across whichever mechanism was fastest to wire up that week.

Conclusion

Replacing Edge Config is a small piece of code, but it only stays reliable if the cluster underneath it can take the load — your config store and your app pods scaling together instead of one starving the other. If you're still deciding what to run that cluster on in the first place, see what a managed Kubernetes setup looks like before you commit to building one from scratch.

Frequently Asked Questions

Does Edge Config have a direct open-source equivalent? Not exactly. Edge Config's value is as much about being bundled into Vercel's edge network as it is about the key-value API itself. Redis gets you the same data shape and read pattern, but you're responsible for the low-latency distribution Vercel handles for free.

Can I just use environment variables instead? For flags that never change without a deploy, yes — and it's simpler than running a config store. The gap appears only when you need a flag to flip without redeploying the app, which is Edge Config's entire reason to exist.

Will this affect Next.js build output? No. Edge Config and its replacements are runtime concerns — they don't change how next build works or what gets shipped in the standalone output. This is purely about what middleware and server code call at request time.