From install to production: the quickstart, every CLI command, the HTTP API with worked examples, and cache fine-tuning. Start with the quickstart — your site is live in about ten minutes.
The goal: publish a static directory and get a live URL — visitor requests land on the nearest edge server (a node close to the user). Four commands, about ten minutes.
Step 1. Install the CLI — it’s the tool you’ll use everywhere, from manual work to CI. The installer picks the right binary for your system and prints where it landed:
curl -sSL https://cdn.srwx.app/install | sh
→ installed srwx 1.4.2 to ~/.local/binStep 2. Log in with your account token. The token (an API key) is visible in the dashboard right after sign-up; the CLI stores it locally and never asks again:
srwx login --token "$SRWX_TOKEN"
→ ok, token saved to ~/.config/srwx/authStep 3. Create a zone — an isolated space for a single site: files, domains, and cache live inside the zone and never mix with neighbors. The zone name becomes part of the final URL:
srwx zone create --name my-site
→ zone my-site createdStep 4. Deploy the directory — the CLI uploads the files to the edge, and serving starts the moment the upload finishes. No separate activation command:
srwx deploy ./dist --zone my-site
→ deployed 42 files, 1.3 MB
→ live at https://my-site.cdn.srwx.appDone — the site is served from all 14 edge servers. From here, optionally attach your own domain, wire up CI publishing with purge (cache invalidation), or fine-tune caching.
The CLI mirrors the HTTP API and is handier for manual work and scripts. Under the hood it makes the same requests, so the capabilities match one to one.
srwx login --token <token> log in once — the token is cached locally
srwx zone create --name <zone> create a new zone
srwx zone list list zones and their storage usage
srwx deploy <path> --zone <zone> upload a directory to the edge and get a URL
srwx purge --zone <zone> --url <url> purge a single URL
srwx purge --zone <zone> --tag <tag> purge every file sharing a tag
srwx purge --zone <zone> --all purge the whole zone at once
srwx stats --zone <zone> --since 24h traffic and request counts over a period
srwx domain add <host> --zone <zone> attach a custom domain to a zoneBase URL: https://api.cdn.srwx.app/v1. Send Authorization: Bearer <token> with every request; responses are JSON.
The request body is the file content; the URL path becomes the object path in the zone. In the response, replicated is the number of edge servers already holding a copy.
# upload a file — the URL path becomes the object path
curl -X PUT https://api.cdn.srwx.app/v1/zones/my-site/objects/css/app.css \
-H "Authorization: Bearer $SRWX_TOKEN" \
-H "Content-Type: text/css" \
--data-binary "body { margin: 0 }"Response:
{
"status": "uploaded",
"path": "css/app.css",
"size": 15,
"replicated": 14
}Three modes: a single URL, a tag, or the whole zone. A tag (a surrogate key) is a label on a group of files: mark a release and refresh it with one request. One request may carry both a URL and tags.
# purge by URL — the zone plus an exact address
curl -X POST https://api.cdn.srwx.app/v1/purge \
-H "Authorization: Bearer $SRWX_TOKEN" \
-H "Content-Type: application/json" \
-d '{"zone":"my-site","url":"https://my-site.cdn.srwx.app/index.html"}'
# purge by tag — the release version, for example
curl -X POST https://api.cdn.srwx.app/v1/purge \
-H "Authorization: Bearer $SRWX_TOKEN" \
-H "Content-Type: application/json" \
-d '{"zone":"my-site","tags":["v2.4.0"]}'The response carries two counters: purged — entries dropped, and servers — servers touched. Once servers reaches 14, the cache is clean across the network.
{
"purged": 1,
"servers": 14,
"ms": 4200
}Returns every zone in the account: name, storage used, and egress over the last 30 days. Handy for an audit before cleaning up old zones.
# every zone in the account: name, storage, 30-day egress
curl https://api.cdn.srwx.app/v1/zones \
-H "Authorization: Bearer $SRWX_TOKEN"Response:
{
"zones": [
{
"name": "my-site",
"storage_mb": 1.3,
"egress_gb_30d": 12.4,
"domains": 1
}
]
}By default the cache key is the path plus the full query string. If your files don’t depend on UTM tags and other tracking parameters, drop them from the key: cache hits go up and needless requests to the origin (the server your site lives on) go down.
# drop UTM tags from the cache key — the hit ratio goes up
curl -X POST https://api.cdn.srwx.app/v1/zones/my-site/cache-key \
-H "Authorization: Bearer $SRWX_TOKEN" \
-H "Content-Type: application/json" \
-d '{"ignore_query":["utm_*","fbclid"]}'Response:
{
"status": "updated",
"ignore_query": ["utm_*", "fbclid"]
}Files can be served from your own domain — say, static.example.com/app.css instead of my-site.cdn.srwx.app/app.css. It takes two steps: a DNS record and one CLI command.
1. Add a CNAME record (a DNS alias) at your DNS provider — it points the subdomain at our network. It looks like this:
static.example.com. CNAME cdn.srwx.app.2. Attach the domain to the zone — the edge starts serving your content on it. One command:
srwx domain add static.example.com --zone my-siteA Let’s Encrypt certificate is issued automatically, usually within two minutes. Until it’s issued, the domain redirects to the zone’s built-in domain.
An edge server looks for the file locally first: RAM, then NVMe. On a miss it asks the origin, stores a copy, and serves that copy from then on. The first visitor warms the file; everyone else gets it instantly.
A typical GitHub Actions workflow: deploy on release, then purge the release tag. The token lives in the repository secrets as SRWX_TOKEN.
- name: Deploy to SRWX Edge
run: |
# install the CLI and log in with the repository secret
curl -sSL https://cdn.srwx.app/install | sh
srwx login --token "$SRWX_TOKEN"
# upload the fresh build and purge the release tag
srwx deploy ./dist --zone my-site
srwx purge --zone my-site --tag "${GITHUB_REF_NAME}"