Affordable CDN File Hosting With a Predictable Bill

Search for a cheap CDN and you get rate cards: a headline per-GB price, a second meter for storage, a third for requests, and a different number in every region. The bill you actually receive depends on traffic you can't forecast, which is the wrong kind of cheap. cdn22.net is affordable CDN file hosting in a narrower, more honest sense — storage, edge delivery, and API requests all draw down one prepaid credit balance, so the number you budget is a single number rather than three meters you reconcile after the month closes.

We are not claiming to be the cheapest CDN in every scenario, because that claim is almost always false. A pure bandwidth reseller with a low per-GB rate can beat us on raw delivery if you are willing to run your own object store, wire an origin pull, and own the cache rules. What a budget CDN does not give you is one balance, one API, and a CDN URL the moment a file finishes uploading. That bundling is the trade: predictable and operationally boring, against a lower theoretical floor you have to assemble yourself.

When cdn22.net is cheaper than the stack you'd otherwise build. The comparison that matters is not our per-GB rate against a rate card — it is our single line against everything the assembled stack bills you. Object storage plus a CDN in front means a storage line, a request line on the bucket, an egress or data-transfer-out line, a request line on the CDN, and sometimes invalidation charges, spread over two products with two credentials and two bills.

Our bill has no separate egress line item, no per-request surcharge, and no monthly minimum or per-seat fee. If your monthly delivery is modest relative to what you store, or your traffic is spiky enough that you'd be forecasting egress blind, the bundled number usually wins on both cost and the hours you don't spend operating it.

The pricing mental model. Two multiplications and an addition: GB stored × storage rate plus GB delivered to users × delivery rate, with $0 in request fees. That's the whole formula — nothing per-upload, per-invalidation, or per-region. The CDN storage cost calculator runs that arithmetic with the live per-GB rates and prices the same bytes against the AWS list-price baseline (S3 Standard storage plus CloudFront or S3 internet egress) so the CDN bandwidth comparison is explicit rather than implied.

Worth internalising the ratio it exposes: serve your library twice a month and storage dominates the bill; serve it fifty times and delivery is essentially the entire bill. That ratio, not the headline rate, decides which provider is cheap for you.

What people actually host here. Downloadable assets — installers, release binaries, PDFs, asset packs — where one file gets pulled thousands of times and per-GB egress is the whole problem. User uploads from your app, ingested through the API and served straight back over the CDN (how to store user uploads walks the flow).

Image and WebP assets that need correct content types and edge delivery without a transformation pipeline. Static front-end files — CSS, JS bundles, fonts — behind content-hashed names. And the common one: replacing a hand-built S3 CDN URL, where you set up a bucket, a distribution, and an origin access policy just to get a public link, with a permanent CDN URL that exists the moment the upload confirms.

Where this is the wrong tool. It is not an edge compute platform — no workers, no functions, no request-time logic at the edge. It is not a media pipeline: no transcoding, no image resizing, no on-the-fly format conversion, so you upload what you want served. It is not a free tier, and there is no free plan behind a signup; billing is prepaid credits drawn down by real storage and bandwidth.

And if you need fine-grained CDN control — edge price classes, custom cache behaviours, per-path rules — a configurable CDN in front of your own bucket is the honest answer. What it is good at is narrow and useful: files you store, delivered globally, reachable over plain REST.

The upload path is three calls and no SDK — POST /v1/files/{folderId} returns a presigned URL and id, you PUT the bytes, then POST /v1/files/confirm-upload — authenticated with your raw API key. Public files get an edge-served permanent link; private files stay private and are reached through short-lived signed URLs your backend mints.

Full endpoint detail is on the cloud file storage API page, the platform shape is covered by file storage with CDN, and the at-rest cost argument in depth is no-egress-fee storage.