Open the CDN zone → Origins tab in my.cubepath.com.
Origins are the backends the CDN pulls content from on a cache miss: your web server, an API, or an S3-compatible bucket. A zone needs at least one before it can serve anything.
Add an origin
Click Add Origin and fill in:
| Field | What it does |
|---|---|
| Name | A label to recognize this backend |
| Address | The hostname or IP of your backend |
| Protocol / Port | How the edge connects to it |
| Host Header | The Host header sent upstream. Leave empty to use the origin address — set it only when your backend does name-based virtual hosting |
| Verify SSL | Validate the origin's certificate. Keep it on unless the backend uses a self-signed cert |
| Weight | Share of traffic when several origins are active |
| Priority | Which origin the edge prefers |
| Backup Origin | Only used when the primary origins are unavailable |
| Health Check + path | Periodically probe the origin so a dead backend is taken out of rotation |
Each origin in the list shows a live health status, and can be enabled or disabled without deleting it — which is the clean way to drain a backend before maintenance.
TipTurn health checks on and point them at a cheap, honest endpoint (something like
/healthzthat touches your database), not at your heaviest page. A check that only proves the web server is listening will keep routing traffic to a backend whose application is broken.
Private S3 buckets (SigV4)
If your origin is an object store and the bucket is private, every unauthenticated fetch gets a 403. S3 Origin Authentication solves this: you give the CDN the bucket credentials once, and each cache miss is signed with AWS Signature Version 4 transparently. Visitors never see the credentials and the bucket stays private.
| Your origin | Do you need this? |
|---|---|
| Your own web server (Nginx, Apache, custom API) | No — plain HTTPS, no signing required |
| Public S3-compatible bucket | No — anyone can fetch with a plain GET |
| Private S3-compatible bucket | Yes — without it every fetch gets 403 |
Supported providers
Any object store that speaks AWS SigV4 over an S3 API works:
| Provider | Endpoint |
|---|---|
| AWS S3 | s3.<region>.amazonaws.com |
| Cloudflare R2 | <account_id>.r2.cloudflarestorage.com (or <account_id>.eu.r2.cloudflarestorage.com for the EU jurisdiction) |
| Wasabi | s3.<region>.wasabisys.com |
| Backblaze B2 | s3.<region>.backblazeb2.com |
| MinIO (self-hosted) | Your own endpoint |
Configure it
Set up the origin as usual — Origin URL is https://<your-endpoint> with no trailing path, and Host Header stays blank (it's auto-filled with the endpoint hostname; never set it to your CDN domain). Then expand Private bucket (S3 SigV4) and fill in:
| Field | Value |
|---|---|
| Enable SigV4 signing | Toggle on |
| Access key ID | The S3-style access key |
| Secret access key | The S3-style secret. Write-only — once saved it's never displayed again |
| Region | Leave blank for R2 (defaults to auto). For AWS / Wasabi / Backblaze use the bucket's region (us-east-1, eu-central-1…) |
| Service | s3 (the default, correct for every supported provider) |
Save. The credentials propagate to every PoP within a few seconds.
Path mapping, the usual first mistake
S3 treats the first segment of the URL path as the bucket name. So a request for:
https://your-zone.cubecdn.io/videos/clip.mp4
is read by S3 as bucket videos, key clip.mp4. If your files actually live in a bucket called my-media, that bucket doesn't exist and you get a 403, 404 or InvalidBucketName.
Two ways to fix it:
- Put the bucket name in your URLs. Leave Base path empty and have customers request
https://your-zone.cubecdn.io/my-media/path/to/file.mp4. Simplest, but the bucket name is visible. - Hide it with Base path. Set Base path to
/my-media, and customers requesthttps://your-zone.cubecdn.io/path/to/file.mp4— the CDN rewrites the path before forwarding. The bucket name never appears publicly.
Credential permissions
Give the credentials the minimum permission needed — Object Read is enough for delivery, which is the normal case. Avoid admin keys.
Scope them to only the bucket(s) this zone serves: on R2 use Specify bucket, on AWS write an IAM policy with Resource: "arn:aws:s3:::my-media/*". Don't hand over account-wide access.
Rotating credentials
Regenerate at the provider, then edit the origin, expand Private bucket (S3 SigV4), paste the new Access key ID and Secret access key, and save. Leaving the secret field blank keeps the current one, so only fill it when you're actually rotating.
New credentials propagate in about 30 seconds. Content already cached keeps being served until its TTL expires; only fresh fetches use the new keys.
Cloudflare R2 jurisdictions
R2 buckets live in either the default or the EU jurisdiction, and each has its own endpoint. Point the CDN at the wrong one and R2 returns 421 Misdirected Request even with perfectly valid credentials. Check the bucket's jurisdiction in the Cloudflare dashboard (R2 → bucket → Settings → Location) and match the endpoint.
WarningR2 API tokens are also scoped to a jurisdiction. A token minted from the default view won't work against EU buckets. If you migrate a bucket between jurisdictions, regenerate the token too.
Error reference
| Status / Code | Meaning | Fix |
|---|---|---|
403 AccessDenied | Valid signature, but the credentials lack permission on this bucket/object | Check the token's bucket scope and resource permissions |
403 SignatureDoesNotMatch | The signature itself is wrong | Re-enter the secret; verify the region matches the bucket |
400 InvalidArgument: Authorization | The request reached S3 with no auth at all | Re-save the origin; confirm the SigV4 toggle is on |
404 NoSuchBucket | The first path segment matches no bucket | See Path mapping above |
404 NoSuchKey | Right bucket, wrong object path | Verify the exact key — case matters |
421 Misdirected Request | Wrong R2 jurisdiction endpoint or account ID | See Cloudflare R2 jurisdictions |
503 Service Unavailable | Origin unreachable from the edge | Check the provider's status page and the endpoint URL |
The XML body usually names the exact <Code>. An HTML error body instead means the failure happened in front of S3 — typically the routing/SNI mismatch behind the 421 case.
Constraints
- All S3-authenticated origins in one zone share the same credentials. The edge signs per backend, not per server. For separate buckets with separate keys, use separate zones.
- The secret is write-only. If you lose it, regenerate at the provider and re-enter.
- GET and HEAD only. The CDN doesn't sign PUT/POST/DELETE — it's a delivery network, not an upload pipeline.