File Storage with Built-in CDN
Storage and CDN in One Platform, One API
Store files and deliver them globally — all in one platform. No separate CDN configuration needed.
The classic way to ship files at scale is to bolt two products together: an object store for the bytes and a CDN in front for delivery. That means two services to provision, two sets of credentials, an origin-access configuration so the CDN can read the store, cache-control and invalidation rules, and two bills that you reconcile separately. files.link collapses all of that into one platform with a single REST API: upload a file and it's immediately reachable through a global CDN, with no distribution to create and no cache policy to tune.
Concretely, the difference shows up the first hour. With S3 + CloudFront you create a bucket, set a bucket policy, create a distribution, configure an Origin Access Control so only CloudFront can read the bucket, pick price classes and cache behaviors, wait for the distribution to deploy, and only then get a delivery URL — and you still own cache invalidation when content changes.
With files.link the three-call upload (POST /v1/files/{folderId} → PUT to the presigned URL → POST /v1/files/confirm-upload with {ids:[id]}) returns a permanent CDN URL that's already edge-served. There's no second product to glue on.
curl -X POST https://api.files.link/v1/files/$FOLDER \
-H "Authorization: $KEY" -H 'Content-Type: application/json' \
-d '{"filesMetadata":[{"name":"hero.jpg"}]}'
# -> { urls: [{ url, id }] }; PUT bytes to url, then confirm-uploadThe consolidation isn't just convenience — it removes whole categories of failure. There's no origin-access misconfiguration that accidentally makes your bucket public, no CDN that 403s because the origin policy drifted, no forgotten invalidation serving stale assets. Billing is one prepaid-credit balance covering storage, delivery, and requests, instead of separate storage, request, and egress lines you have to model.
The honest trade-off versus a hand-rolled S3 + CloudFront stack (or Backblaze B2 + Bunny CDN) is control over knobs you may never want: you don't pick edge price classes or write custom cache behaviors. For most apps that want files online and fast without becoming a part-time CDN operator, that's the right trade. Public files are edge-served by default; private files get signed URLs (10-minute expiry) for controlled access.
Under the hood it's a plain developer file storage API — three REST calls, no SDK — and if you're specifically adding user image uploads, the image upload API page walks the same presigned flow end to end.
Benefits With No Complexity
Global CDN delivery
Edge-cached worldwide
Signed-URL security
What You Get
Unlimited files
Unlimited storage
Public + Private storage
CDN ready links
Prepaid credits
More coming soon
How files.link Works
1. Upload
2. Copy
3. Use Anywhere
Why Developers Choose files.link
A Better Way to Store & Deliver Files
| S3 + CloudFront | Backblaze B2 + Bunny CDN | Google Cloud Storage + Cloud CDN | files.link | |
|---|---|---|---|---|
| Single platform (storage + CDN) | ||||
| One API and one credential set | ||||
| No origin-access / distribution config | ||||
| No separate egress line | ||||
| One prepaid bill, not storage + requests + egress | ||||
| Private files with signed URLs |
Calculate Your Needs
Storage
Egress
CDN Bandwidth
Start Storage with CDN
- Global CDN delivery
- Edge-cached worldwide
- Signed-URL security
- Unlimited files
- Unlimited storage
- Public + Private storage
- No subscription — prepaid credits keep spend predictable