Every CDN request starts somewhere, and if that somewhere is a server metered by the terabyte, your bill grows every time a video goes viral. A dedicated origin server for video CDN delivery flips that model: you size the box on port speed, not on egress, and let the CDN handle fan-out while the origin just needs to survive cache misses, re-encodes, and thundering-herd pulls without falling over. This is a note from the rack on how we think about origin sizing, DDoS exposure, and network control for teams running video behind a third-party CDN.
Why Your CDN Is Only as Good as Its Origin
CDNs are good at caching, not at surviving a bad origin. When a cache expires, a new region spins up, or a purge hits a large object set, dozens or hundreds of edge nodes hit the origin simultaneously for the same file. If the origin is a shared VPS with capped bandwidth or a burstable NIC, that's exactly when you see 5xx errors bubble up through your CDN's own logs. We've watched this happen on undersized boxes during a single popular stream re-encode — the CDN did its job perfectly, the origin choked, and viewers got buffering regardless of how good the edge network was.
The fix isn't a bigger CDN plan. It's a dedicated origin server with headroom on the one resource that actually gets hammered during cache-miss storms: outbound port capacity.
Sizing an Origin Server on Port Speed, Not a Delivery Bill
Most origin-hosting conversations start with "how many TB will we push this month," which is the wrong question for an origin tier. The CDN absorbs the bulk of viewer traffic — the origin only serves what the edge doesn't already have cached. What actually matters is whether the origin can service a burst of simultaneous pulls without saturating its NIC. That's a port-speed question, not a metered-transfer question.
Our dedicated line runs symmetric ports from 1 up to 200 Gbps, unmetered, so a fill-event or cache-purge storm doesn't turn into an overage invoice. You pick the port size based on peak concurrent origin pulls, not projected monthly volume, and you stop budgeting around a bandwidth meter entirely.
| Sizing input | Metered-bandwidth model | Unmetered port model |
|---|---|---|
| What you plan against | Projected monthly TB, revised every viral spike | Peak concurrent origin-pull throughput |
| Cost surprise risk | High — overage bills after a spike | None — same rate at any usage level |
| Cache-miss storm | Can trigger throttling or extra billing | Absorbed within the port's headroom |
| Multi-CDN failover testing | Discouraged (doubles metered egress) | Free to test, same flat cost |
That last row matters more than it looks. Teams running multi-CDN or multi-homed setups often avoid failover drills because a metered origin makes every test expensive. On a flat, unmetered port, you can run failover tests as often as you want.
DDoS Protection at the Origin, Not Just the Edge
Most CDN vendors will tell you their edge is DDoS-hardened, and it usually is. What they won't tell you is that your origin IP is discoverable — through DNS history, misconfigured direct-access rules, or a leaked backend hostname — and once it's known, attackers skip the CDN entirely and hit the origin directly. An origin with no DDoS coverage of its own is a single exposed IP standing behind a CDN that can't protect what it doesn't see.
Every dedicated server we ship includes 100 Gbps of always-on DDoS protection covering layer 3 and 4 traffic. That protection sits in front of the origin itself, independent of whatever the CDN vendor provides at the edge — so a volumetric flood aimed straight at your origin IP gets scrubbed before it ever reaches the box serving your video files.
- Origin IP protected the same way the edge is, not left as the soft target
- Detection and mitigation happen automatically, no manual escalation needed during an attack
BGP and Multi-Homing for Teams Running Their Own Network
Once an origin is serving real production traffic, some teams outgrow single-provider routing. Maybe you're running origins in two locations for redundancy, maybe you want to announce your own address space instead of leasing IPs from a single upstream, or maybe you just want control over how traffic ingresses during a partial outage. That's a BGP conversation, and it only works if the underlying network actually supports it.
We run our own AS60982, and BGP is available on request for dedicated deployments — useful if you're multi-homing an origin tier across providers or want direct routing control instead of depending entirely on a single upstream's default path. It's not something every video origin needs on day one, but it's worth knowing the option exists before you're locked into infrastructure that can't grow into it. Full network specifics, including IPv4 allocation, live on our network page.
What to Look for in an Origin Server for a Video CDN
Whether you're serving VOD libraries, live re-streams, or a hybrid setup feeding a CDN, the checklist for origin infrastructure is short but non-negotiable:
- Symmetric, unmetered port speed sized for peak concurrent pulls, not average monthly transfer
- NVMe storage so disk I/O never becomes the bottleneck ahead of network capacity
- Origin-level DDoS coverage, independent of whatever the CDN already provides at the edge
- Static or near-static IP block — a
/29is enough to separate origin-pull traffic, health checks, and admin access onto distinct addresses - BGP availability if you expect to multi-home or run your own address space later
- Fast provisioning so a capacity upgrade doesn't take days when you're mid-launch
If your video pipeline is closer to live streaming than VOD — ingest, transcode, and short-lived origin caching rather than a long-lived object store — it's also worth comparing against a streaming VPS, which has no per-VM bandwidth ceiling and gives you full root to install the ingest stack (RTMP/SRT/HLS) yourself.
How Noded Can Help
We built our dedicated line specifically for teams that got burned by metered origin bills or discovered their origin IP was the weak point in an otherwise solid CDN setup. Our dedicated servers come with symmetric unmetered ports from 1 up to 200 Gbps, a /31 (one usable IPv4) with /29, /28 and /27 subnets as add-ons, 100 Gbps of DDoS protection covering the origin itself, and BGP on request through our own AS60982 if you're building a multi-homed setup. Plans start from EUR209/mo, and Xeon servers are delivered in about 45 minutes — no lengthy KYC-to-deploy gap when you need origin capacity added before a launch; EPYC builds take about 14 days. If you want to talk through sizing a specific origin workload, our dedicated server page has current configurations, or reach out and we'll size it with you directly.
FAQ
Do I need a dedicated server if I already pay for a CDN?
Yes — the CDN caches and distributes, but every cache miss, purge, or first request still hits your origin. A weak or metered origin becomes the failure point during exactly the traffic spikes a CDN is supposed to protect you from.
How should I size port speed for a video origin?
Size it against peak concurrent origin pulls during a cache-miss storm or re-encode event, not your average monthly transfer. An unmetered symmetric port removes the need to guess at monthly totals altogether.
Does CDN-level DDoS protection cover my origin server?
No. CDN DDoS protection covers the edge; if your origin IP is discoverable, attackers can bypass the CDN and hit it directly. Origin-level DDoS protection, like the 100 Gbps coverage included on our dedicated servers, closes that gap.
When would I actually need BGP for a video origin?
BGP matters once you're multi-homing origins across locations or providers, or want to announce your own IP space instead of relying on a single upstream's routing. It's available on request through our AS60982 for dedicated deployments that need it.
Is a dedicated server or a streaming VPS the right origin for live video?
If you're running long-lived VOD/object origin behind a CDN, a dedicated server sized on port speed is the better fit. If your workload is closer to live ingest and short-lived caching, a streaming VPS running your own ingest stack can be simpler to operate.