What "CDN file storage" means
Most CDNs work in Pull mode: the edge keeps your existing origin server and fetches (pulls) content from it as visitors ask for it. That is great when you already run a website. But if you just have files to serve — a logo, a PDF, a download, a video, the built assets of an app — standing up and maintaining an origin server for them is overkill.
CDN file storage is the other way round. Instead of pointing the CDN at your server, you store the files on the CDN itself and serve them straight from the edge. The CDN is the origin. There is no server for you to run, patch or scale: you upload a file, you get a URL, and every visitor is served the file from a nearby edge location over HTTPS. This is what people mean by "serve files from a CDN" or "CDN origin storage" — the CDN holds the file and delivers it.
Option A — upload from the panel (no CLI)
The simplest way is straight from the cdn.com.tr panel. Open the Files area of your account, upload the files you want to serve, and organize them into folders just like a normal file manager. Nothing to install and nothing to configure — the upload lands in your account's CDN storage.
Once a file is uploaded it is served through the CDN over its URL, cached at the edge, and covered by automatic SSL so the link is HTTPS from the start. This is the right path when you have a handful of files, when you want to see and manage them visually, or when you are not the kind of person who lives in a terminal. For bulk uploads, repeatable steps or automation, the CLI below is faster.
Option B — the cdnctl CLI (works like scp)
cdnctl is the operator command-line tool for cdn.com.tr, and it makes uploading files feel like scp. First, sign in once and pick your account so every command knows where to put things: run cdnctl login --email you@example.com --password ... (or cdnctl configure --endpoint https://cdn.com.tr --token <token> if you use an API token), then cdnctl accounts use <account_uuid> to set the default account. After that, account-scoped commands just work.
To upload, use cp exactly like scp — local path first, remote path second: cdnctl cp ./logo.png images/logo.png puts a single file at images/logo.png in your CDN storage. Add -r to send a whole directory: cdnctl cp -r ./dist assets/ uploads every file under ./dist into assets/. Pass --force to overwrite files that already exist. You can also target a specific account inline with account_uuid:remotepath if you have not set a default.
If you prefer explicit sub-commands, the files group does the same jobs and prints JSON you can parse in scripts: cdnctl files put --file ./logo.png --target-path images/logo.png [--force] uploads a file, cdnctl files ls [--path <path>] lists what is stored, cdnctl files mkdir --path <path> creates a folder, and cdnctl files rm --path <path> --yes removes something. Same storage as the panel — just driven from your terminal.
When to use S3-compatible object storage instead
File storage is the simplest way to host and serve static files and media over the CDN. When you need more — buckets, access keys, or to drive uploads programmatically with existing S3 tooling — reach for S3-compatible object storage, which is backed by Ceph RGW.
With cdnctl you create a bucket with cdnctl object-storage buckets create --account <uuid> --name <bucket>, list them with cdnctl object-storage buckets list --account <uuid>, and mint S3 access and secret keys with cdnctl object-storage access-keys create --bucket <bucket_uuid>. From there any S3-compatible client or SDK can read and write the bucket. You can also bind a bucket straight into a container app so it arrives as environment variables — cdnctl object-storage bindings create ... --env-prefix S3 — which is the clean way to give an app its own storage. Rule of thumb: file storage to host and serve files over the CDN; object storage when you want buckets, keys, programmatic/S3 access, or storage that backs an app.
Serving, caching and purge
Files you store on the CDN are served from the edge and cached there, so repeat requests are answered from a location near the visitor instead of travelling back to a single origin. Every served URL gets automatic HTTPS, so your links are secure without you managing certificates.
One thing to remember with edge caching: when you overwrite a file with a new version, the old copy can still be cached at the edge for a while. If you replace a file and need the change to be live immediately, purge it (from the panel or the API) so the edge fetches the fresh copy. A common pattern to sidestep this entirely is to include a version in the filename or path — logo.v2.png, or assets under a build hash — so a new file has a new URL and never collides with a cached one.
CI and automation with cdnctl
Because cdnctl is a single command-line tool that authenticates with a token, it fits neatly into CI/CD. A typical build step authenticates once (cdnctl configure --endpoint https://cdn.com.tr --token <token> and cdnctl accounts use <uuid>), then pushes the freshly built assets: cdnctl cp -r ./dist assets/ --force. Your pipeline uploads the artifacts, the edge serves them, and you never hand-copy files again.
The same approach covers publishing a new download, rotating a marketing asset, or shipping a static site's output on every commit — all scriptable, all repeatable, no origin server to keep alive.
What people serve from CDN storage
Host logos, product photos, video and audio on the CDN and serve them fast from the edge — no media server to run.
Put installers, PDFs and release files in storage and hand out fast, HTTPS download links that scale under demand.
Push a build's JS, CSS and images from CI with cdnctl cp -r and serve the whole static bundle from the edge.
CDN file storage FAQ
Do I need my own server to serve files from the CDN?
No. With CDN file storage the CDN itself is the origin — you upload files to your account and they are served from the edge. There is no origin server for you to run, patch or scale.
How do I upload files — panel or command line?
Both work on the same storage. Use the Files area of the panel for a visual, no-code upload, or the cdnctl CLI when you want to script it. cdnctl cp works like scp: cdnctl cp ./logo.png images/logo.png for one file, or cdnctl cp -r ./dist assets/ for a whole folder.
What is the difference between file storage and object storage?
File storage is the simplest way to host and serve static files and media over the CDN. Object storage is S3-compatible: you get buckets and access keys and can use standard S3 tools or bind a bucket to an app. Use file storage to serve files; use object storage when you need buckets, keys or programmatic access.
I replaced a file but the old one still shows — why?
Served files are cached at the edge, so an overwritten file can serve the old copy until the cache updates. Purge the file after you overwrite it, or include a version in the filename or path so a new version has a new URL.
Are the file URLs served over HTTPS?
Yes. Files served through the CDN get automatic SSL, so their URLs are HTTPS with no certificate for you to manage.