DEV Community

RAXXO Studios
RAXXO Studios

Posted on • Originally published at raxxo.shop

5 Vercel Edge Config Patterns I Use For Shopify A/B Tests

#ai #productivity #claudecode #automation

  • Edge Config reads in ~15ms at the edge, no cold start, no extra request to Shopify

  • I cut a 50 EUR/month LaunchDarkly bill to 0 EUR on Vercel Pro, 4 storefronts share one config

  • Five patterns covered: hero copy split, price experiment, geo free-shipping flag, kill-switch, multi-arm bandit

  • Each flag is a JSON key, flipped via REST API, picked up by middleware.ts before the page renders

I run four Shopify storefronts off the same Vercel Pro account. Last quarter I ripped out a feature-flag SaaS and replaced it with Vercel Edge Config. The bill went from 50 EUR a month to 0 EUR, and my A/B reads got faster.

Here are the five patterns I actually use, in production, on real traffic.

Why Edge Config (And Not KV, Postgres, Or A SaaS Flag Tool)

I tried three things before landing on Edge Config.

First was Vercel KV (now Upstash Redis). It works, but every read is a network call to the KV region. From a European edge node hitting an EU KV instance I was seeing 25-40ms per read. Multiply that by three flags on a single page render and you have just added 100ms of TTFB for no good reason. KV is great for session state. It is the wrong tool for "is this hero variant on or off".

Second was Postgres via Neon. Same problem, worse numbers. Adding pg pool warmup just to read a boolean felt insane. Plus I was paying for compute hours to answer "show banner: yes/no".

Third was LaunchDarkly. It is a proper product, but their starter plan started at 50 EUR/month for the seat I needed, and the SDK adds bundle weight to every storefront. For a solo studio shipping experiments on five-figure-monthly traffic, the math did not work.

Edge Config solves the specific problem I had. It is a tiny read-only JSON blob (8KB on Hobby, 64KB on Pro) that Vercel replicates to every edge node. Reads from middleware run in ~15ms because the data is already sitting next to the function. Writes go through a REST API and propagate globally in a few seconds.

It is included on Pro at 0 EUR extra. I share one Edge Config across all four storefronts by referencing the same EDGE_CONFIG connection string. One flip, four sites updated.

The mental model that finally clicked: Edge Config is for things you read on every request and change rarely. Feature flags. A/B variants. Kill-switches. Banner copy. Country lists. It is not a database. It is the thing you reach for when you want a config file you can edit without redeploying.

If you are building on Shopify Hydrogen or a custom Next.js storefront talking to the Shopify Storefront API, this slots in cleanly. Middleware reads the flag. The page reads the variant. Done.

Pattern 1 + 2: Hero Copy Split And Price Display Test

Pattern one is the boring-but-useful one: hero banner copy split. I want 50% of visitors to see headline A and 50% to see headline B, and I want to flip which copy wins live without a deploy.

Edge Config holds it as one JSON object:


{
  "hero_test": {
    "active": true,
    "variants": ["bold_promise", "soft_curiosity"],
    "split": [50, 50]
  }
}
Enter fullscreen mode Exit fullscreen mode

In middleware.ts I read it once, pick a variant deterministically off the visitor cookie, and stamp the choice into a header the page route reads.


import { get } from '@vercel/edge-config';
import { NextResponse } from 'next/server';

export async function middleware(req) {
  const test = await get('hero_test');
  if (!test?.active) return NextResponse.next();

  const id = req.cookies.get('visitor_id')?.value ?? crypto.randomUUID();
  const variant = pickVariant(id, test.variants, test.split);

  const res = NextResponse.next();
  res.headers.set('x-hero-variant', variant);
  res.cookies.set('visitor_id', id, { maxAge: 60 * 60 * 24 * 30 });
  return res;
}
Enter fullscreen mode Exit fullscreen mode

The whole read is ~15ms. No SDK. No initialization. Just get().

Pattern two is the same shape with higher stakes: price display. On one storefront I tested anchoring (showing a struck-through "was 49 EUR" next to "now 33 EUR") versus a clean single price.

The variant gate sat in Edge Config:


{ "price_anchor": { "active": true, "split": [70, 30] } }
Enter fullscreen mode Exit fullscreen mode

Server component reads the header, branches the JSX, ships the variant. Both arms point at the same Shopify product (no risk of price drift between arms because the actual checkout price is the same, only the display differs). I tracked clicks to PDP and add-to-cart events into Shopify customer events.

The 30% arm with the anchor lifted add-to-cart by 11% over two weeks. I flipped the split to 100/0 from a curl call without redeploying. That is the real win, the speed of iteration, not any specific lift number.

Pattern 3 + 4: Country-Aware Free Shipping And Emergency Kill-Switch

Pattern three is geo-aware free shipping. Vercel middleware exposes request.geo.country. I keep a country allowlist in Edge Config and toggle it during campaigns.


{
  "free_shipping_countries": ["DE", "AT", "CH", "NL"],
  "free_shipping_threshold_eur": 50
}
Enter fullscreen mode Exit fullscreen mode

Middleware reads both keys, attaches them to a header, the cart UI reads the header and renders the right banner ("Free shipping in DE, AT, CH, NL on orders over 50 EUR" or nothing).


const allow = await get('free_shipping_countries');
const country = req.geo?.country ?? 'XX';
if (allow?.includes(country)) {
  res.headers.set('x-free-ship', '1');
}
Enter fullscreen mode Exit fullscreen mode

When a campaign ends I remove a country from the array. Live in seconds.

Pattern four is the one I sleep better with: a global kill-switch. Every experimental feature reads a master flag first.


{ "kill_switch": { "experiments": false } }
Enter fullscreen mode Exit fullscreen mode

If experiments is false, middleware short-circuits every A/B branch and serves the control. I have flipped this twice. Once when a third-party script tanked LCP on the test arm and once when a cart bug looked like it might be variant-specific. From spotting the issue to "everything back to control on all four storefronts" was under 30 seconds. I did not have to redeploy anything, I did not have to log into a dashboard, I curl'd a write to the Edge Config REST API.


curl -X PATCH \
  "https://api.vercel.com/v1/edge-config/$ID/items?teamId=$TEAM" \
  -H "Authorization: Bearer $VERCEL_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"items":[{"operation":"update","key":"kill_switch","value":{"experiments":false}}]}'
Enter fullscreen mode Exit fullscreen mode

I keep that as a one-liner alias. Killing experiments in 4 storefronts at once is a single command.

Pattern 5: Multi-Arm Bandit Rollout Via Edge Middleware

Pattern five is where I get a little fancy. A standard 50/50 A/B test wastes traffic on a losing arm once you have signal. A multi-arm bandit shifts traffic toward the winner as data comes in.

I run a lightweight Thompson sampling setup. The bandit state lives in Edge Config and gets updated by a Vercel cron every 30 minutes.


{
  "checkout_cta_bandit": {
    "arms": {
      "buy_now":  { "trials": 4120, "wins": 372 },
      "get_yours":{ "trials": 4080, "wins": 401 },
      "claim":    { "trials": 3990, "wins": 318 }
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Middleware does the assignment. It reads the arm stats, samples each arm from a Beta distribution, picks the highest, stamps a header. The page renders the matching CTA copy.


const bandit = await get('checkout_cta_bandit');
const pick = sampleThompson(bandit.arms);
res.headers.set('x-cta-arm', pick);
Enter fullscreen mode Exit fullscreen mode

A separate cron job, also on Vercel, queries my events store every 30 minutes, recomputes trials and wins per arm, and PATCHes the new numbers back into Edge Config. The whole job runs in under 5 seconds.

The benefit over fixed-split A/B: by week two, ~70% of traffic was getting the winning arm instead of being stuck at 33%. Lift on add-to-click jumped accordingly without me touching anything.

The shape that makes this work: Edge Config is the read path (fast, edge-cached, free), the cron is the write path (slow is fine, runs every 30 min), and the actual event data lives somewhere else (Shopify analytics, in my case). Three jobs, three tools, each doing what it is good at.

I documented the cron side in The 5 Vercel Cron Jobs That Keep My Studio Running. And if you are weighing edge platforms, 5 Cloudflare Workers Patterns I Use for Shopify Edge Logic covers the other side of the fence.

Bottom Line

Five patterns, one shared Edge Config, four storefronts, 0 EUR added cost on top of the Vercel Pro plan I was already paying for. The thing that surprised me was not the price, it was how often I now ship experiments because the friction is gone. Edit a JSON value, hit save, watch the next request pick it up. No deploy, no SDK, no dashboard.

If you are running a Shopify storefront on Vercel and you have ever thought "I would test this if it were not such a hassle", Edge Config is probably your missing piece. Start with the kill-switch (pattern 4), it pays for itself the first time something breaks. Add the hero copy split next, you will feel the iteration speed inside a week.

I keep a running list of these small infra patterns and the actual configs I use over at the Studio page if you want to see what else is in rotation.

Top comments (0)