No provider on earth gives you an unbounded pipe to the internet for $7 a month, and none of them are lying when they advertise "unlimited bandwidth" either. Both things are true because "unlimited" describes the billing model, not the physics. What's actually unlimited is that you won't get charged per gigabyte. What's very much limited is how many gigabytes you can physically push through the port in a month.
The confusion is understandable, because the words providers use — unlimited, unmetered, generous allowance — all sound like variations on the same promise. They aren't. Each implies a different answer to the one question that actually matters: what happens on the day your traffic is genuinely unusual, either because you got popular or because something went wrong. If you are looking at what "unlimited bandwidth" really means on a VPS from the commercial side rather than the engineering side, the XenGrowth practice publishes guides on the same ground.
Metered, unmetered, and fair-use — these are three different promises
Metered means exactly what it sounds like: every gigabyte is counted and billed, the way Vercel bills bandwidth. Unmetered means the provider doesn't count gigabytes at all — you pay the flat monthly price regardless of how much you transfer, up to whatever your port physically allows. "Unlimited" is a marketing word draped over one of the other two, and on a VPS it's almost always draped over unmetered with a fair-use policy attached, which is the part that actually matters and the part the headline number never mentions.
Fair-use is the clause that reconciles "unmetered" with the fact that the provider's own network isn't infinite. It says, in effect: we won't bill you per gigabyte, but if your usage pattern looks nothing like a normal server's — sustained, near-continuous saturation, for instance — we reserve the right to slow you down rather than charge you more. That's a materially different risk than a surprise invoice, and it's worth understanding exactly how it plays out before you assume "unlimited" means what the word implies.
If it's unmetered, what actually stops me from transferring infinite data?
Port speed. Every VPS connects to the network through a port with a fixed maximum throughput — 100 Mbit/s, 1 Gbit/s, whatever the plan specifies — and that ceiling caps your transfer regardless of what the traffic-allowance number says. A 100 Mbit/s port, saturated continuously, 24 hours a day, for a full month, moves somewhere in the neighborhood of 32 TB. That's not a coincidence: providers size their traffic allowances against exactly this math, because a genuinely saturated port at that speed for a full month is already an unusual usage pattern for anything that isn't intentionally running as a bandwidth service. The XenGrowth resource library approaches this from the the operations side of this side.
This is also why the allowance number rarely bites a normal app. A self-hosted SaaS product, a blog, an API backend — these have traffic patterns with peaks and quiet hours, not a port pinned at 100% for 30 straight days. The allowance exists as a backstop against the workloads that would actually do that: video hosting at scale, a public file-sharing service, something closer to a CDN than an app.
It's also worth being precise about which direction of traffic the allowance actually measures, because providers aren't consistent about it and the difference matters. Fair-use and traffic policies are almost always written against outgoing bandwidth — the data your server sends out to visitors — with incoming traffic (uploads, requests coming in) either unmetered outright or counted far more generously. That asymmetry makes sense once you think about what actually costs a provider money: serving data out to the wider internet, not receiving it. An app that mostly serves file downloads or video is the shape of workload that tests an outbound allowance; an app that mostly receives uploads rarely comes close, regardless of file size.
What actually happens if I go over the allowance?
Not a bill — a throttle, and it's worth sitting with the gap between that and the marketing page. Contabo's pricing page advertises Cloud VPS 4 as "Unlimited Traffic," full stop, no asterisk above the fold. Its own article on bandwidth and traffic limits is more candid and, oddly, less specific: there is no default bandwidth limit, only a fair-use policy, under which Contabo "reserves the right to throttle servers at its own discretion" if usage is "exceptionally high or disruptive" — measures it calls rare, and says it will raise by email first. Both statements are true at once, and the gap between them is the whole subject of this post. Note what is not there: no gigabyte threshold, no overage rate, no defined trigger. An earlier version of that article did publish a hard number, and the number is gone. That is worth more than the number was, because it tells you what you are actually buying — not a metered allowance with a published ceiling, but a shared pipe governed by someone else's judgement about what counts as disruptive.
This is the structural difference worth internalizing: on an unmetered VPS, the failure mode of heavy usage is degraded speed, recoverable by using less or upgrading the plan. It is not a bill that shows up two weeks later for an amount you didn't budget for. That's a genuinely different risk profile than a metered platform, and it's the actual reason "cheap unmetered VPS" and "pay-as-you-go platform" attract such different kinds of anxiety from the people running them. For the AI agents and marketing automation angle, see XenGrowth on governed AI marketing workflows.
Vercel's model isn't wrong for doing it differently — metering per gigabyte is how you charge fairly for a platform where compute and bandwidth genuinely are the product, and its included allowances (1 TB fast data transfer, 100 GB fast origin transfer on Pro) are generous for a huge share of small apps. The mismatch only shows up at the edges: an app that serves large media, or one that gets a sudden viral spike, meters its way into a real bill exactly where the equivalent workload on an unmetered VPS would just get throttled and keep running, slower but free.
Model | How overage is handled | Example |
|---|---|---|
Unmetered VPS | Port throttled after sustained overage; no per-GB bill | Contabo: discretionary throttle under fair use, no published threshold |
Metered platform | Billed per GB past the included allowance | Vercel Pro: $0.15/GB past the included 1 TB fast data transfer |
Metered origin transfer | Billed per GB from the first byte, absorbed by credit first | Vercel: $0.06/GB fast origin transfer |
There's a more mundane way to actually approach an unmetered allowance than a deliberate abuse case, and it's worth naming because it's the version that actually happens to small self-hosted apps: an unoptimized image library serving full-resolution originals to every visitor, an aggressive scraper or bot hitting the same large endpoint on a loop, or a backup job configured to push a full snapshot offsite every night without compression. None of those are malicious, and none of them look like "running a bandwidth service" from the outside, but they can add up to real sustained traffic over a month if nobody's watching the number. Checking outbound traffic in whatever dashboard your provider exposes, even just monthly, is enough to catch this well before it becomes a fair-use conversation.
How does a CDN in front of the origin change any of this?
It changes what actually counts against either number, on both sides of this comparison. Put Cloudflare in front of a self-hosted origin and every cached response — a static asset, an HTML page under a cache rule, an image — gets served from Cloudflare's edge and never touches the VPS's port at all. Only cache misses and genuinely dynamic responses pull bandwidth from the origin, which is usually a small fraction of total traffic once caching is configured properly. I've covered what Cloudflare's free tier actually covers and where its limits sit in a separate post, but the bandwidth angle alone is often reason enough to put it there.
On the metered side of this comparison, the same shift matters even more directly, because there it's not just about staying under a soft cap — it's about a real, itemized dollar figure. Vercel's own fast origin transfer charge is billed from the first byte, not from some included threshold, which means every byte a CDN in front of the origin manages to serve instead is a byte that never appears on that line item at all. That's a meaningfully different incentive than the unmetered side, where caching mostly buys headroom against a policy you'd likely never trigger anyway. If AI search, GEO and discovery is the part you are stuck on, XenGrowth on building one SEO and GEO content system is the better reference.
Self-hosted VPS behind Cloudflare: caching mostly buys margin against a fair-use ceiling that a normal workload rarely approaches in the first place
Metered platform like Vercel: caching directly reduces a per-GB bill with no included allowance protecting the origin-transfer portion of it
Either way, the mechanism is the same — traffic that never reaches the origin can't count against whatever limit that origin is measured by
This is also the point where the two billing models actually converge in practice, even though they start from opposite premises. A well-cached self-hosted setup and a well-cached Vercel deployment both end up sending a small fraction of their total served bytes through the metered or fair-use-relevant path — the origin, in both cases, mostly answers cache misses. The difference isn't in how much protection caching buys; it's in what the uncached remainder costs you if you don't put a CDN in front at all. On Contabo, skipping the CDN mostly costs you nothing until a genuine anomaly happens. On Vercel, it costs money every single month, quietly, at $0.06/GB from the first byte.
"Unmetered" and "metered" aren't points on the same scale of generosity. They're different bets about how a provider wants to handle the day you actually use a lot of bandwidth — one throttles you, the other sends an invoice.
Port speed | Max transfer if saturated 24/7 for a month | Realistic for most small apps? |
|---|---|---|
100 Mbit/s | ~32 TB | Yes — and it's this port speed, not any published allowance, that sets the real ceiling |
250 Mbit/s | ~80 TB | Only reachable by workloads doing continuous large transfers, not typical request/response traffic |
1 Gbit/s | ~320 TB | Essentially never reached by a normal app; this ceiling exists for burst capacity, not sustained use |
So does "unlimited bandwidth" mean I don't have to think about it?
For nearly every self-hosted app at the traffic levels this cluster is written for, yes — a €5.50/mo (first 24 months) Contabo box behind a CDN that catches most static traffic before it reaches the origin is not a ceiling you're likely to test. The number to actually understand was never the headline "unlimited"; it's the port speed underneath it, and what the provider does when someone genuinely saturates that port for days at a time. On Contabo that answer is now a judgement call rather than a documented rule — which is fine at this scale, and worth knowing before you build a business on the pipe.
The one habit worth keeping regardless of which model you're on: check the actual outbound number in your provider's dashboard every so often, not because you expect to hit a ceiling, but because a number that's quietly climbing month over month is usually the first sign of something worth investigating — an image that should be compressed, a bot that should be blocked, a cache rule that isn't actually catching what you think it's catching. The bill or the throttle is the lagging indicator. The dashboard number is the leading one. Compare that against what each pricing tier actually includes before assuming every provider's "unlimited" means the same thing — the traffic allowance is one more line where the tiers genuinely differ, not just a shared marketing word, and it's worth reading the fair-use policy behind the headline number before you pick a provider based on the number alone.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on governed AI marketing workflows — what you'll learn: how the teams running AI marketing agents keep them governed and measurable.
XenGrowth on building one SEO and GEO content system — what you'll learn: how search and AI-answer visibility get run as a single content system.
Where this work meets go-to-market
If what "unlimited bandwidth" really means on a VPS is part of a growth programme rather than a standalone build, XenGrowth's marketing operations practice is the companion reading.
Four questions on the gap between the marketing word and the contract underneath it. Nobody is selling you an unbounded pipe; knowing what they are selling is the useful part.
