Why we chose a CDN partner instead of building our own edge

Every few weeks someone asks why Omega does not run its own global edge network. The honest answer: building and operating an edge proxy in dozens of cities is a full engineering org's job, and Omega is one person. The smart move for a small operator is to stand on infrastructure that already exists and is already operated well. So we route customer traffic through a partnered CDN rather than pretending to own one.

What running your own edge actually costs

An edge proxy is latency-critical and security-critical at the same time. Every millisecond you add is a millisecond a visitor waits, and the proxy sits directly on the public internet terminating TLS for other people's domains. To run that credibly you need presence in many cities, anycast announcements with transit relationships, 24-hour on-call for when a node misbehaves, and a software team to keep the proxy patched against the next TLS or HTTP/2 parsing bug. None of that scales down to a sole operator. Trying to fake it would be the opposite of honest.

There is a real engineering decision here, it is just not 'write a faster proxy.' It is 'which partner do we trust with the request path, and how do we wire our origins behind it.' That is the work this post is about.

What we checked before picking a CDN partner

We did not pick on logo recognition. The checklist below is what mattered for the traffic our customers actually run, mostly WordPress, small apps, and static sites served close to visitors in the nine regions we sell into.

• · PoP coverage that overlaps real eyeball networks in the regions we serve, not a marketing map of city pins
• · Anycast routing so visitors hit a near edge by BGP rather than a fixed hostname per region
• · Modern TLS done for you: TLS 1.3, automatic certificate issuance and renewal, OCSP stapling, sane cipher defaults
• · Honest cache control: support for Cache-Control, stale-while-revalidate, cache-key normalization, and per-path purge
• · An origin shield or tiered cache so a cold edge does not stampede our origin
• · Real logs and HIT/MISS/BYPASS visibility, so we can debug a customer's cache ratio instead of guessing

How Omega routes through it

The setup is deliberately boring. A customer's domain points at the partnered CDN. The CDN terminates TLS at its nearest PoP, serves cacheable responses from its own cache, and on a miss forwards to the origin we host for that customer. We keep origin behind the CDN's published address ranges so direct-to-origin traffic can be refused. Cache rules and bypass rules live in the CDN config; the application code does not change.

# Confirm a domain is actually being served through the edge,
# not hitting origin directly.
curl -sI https://customer-site.example/ \
  | grep -iE 'server|x-cache|cf-cache-status|age|cache-control'

# A cached HTML response should show a HIT and a sane max-age.
# A direct-to-origin response will not carry the edge cache headers.

What you give up, and why it is fine

Using a partner means we do not control the proxy internals. We cannot ship a custom congestion-control tweak or a bespoke header parser, and we are exposed to the partner's incidents. In exchange we get a request path operated by people who do nothing else, kept current on TLS and HTTP vulnerabilities, with a PoP footprint no solo operator could staff. For the traffic our customers run, that trade is not close.

The honest version of an edge network for a one-person shop is a good partner and a clean config, not a fleet of servers you cannot actually staff.

If you are a small operator weighing the same decision, resist the urge to build the impressive thing. Pick a partner whose coverage and cache controls match your traffic, wire your origins behind it cleanly, and spend your limited time on the part customers feel: fast origins, correct cache rules, and support that answers.