От установки до продакшена: быстрый старт, все команды CLI, HTTP API с примерами и тонкости настройки кэша. Начните с быстрого старта — через десять минут сайт будет в сети.
Цель — опубликовать директорию со статикой и получить живой URL: запросы посетителей будут уходить на ближайший edge-сервер (узел сети рядом с пользователем). Четыре команды, около десяти минут.
Шаг 1. Установите CLI — это основной инструмент: через него делается и ручная работа, и CI. Скрипт подберёт бинарник под вашу систему и напечатает, куда его положил:
curl -sSL https://cdn.srwx.app/install | sh
→ установлен srwx 1.4.2 в ~/.local/binШаг 2. Войдите токеном аккаунта. Токен (ключ доступа) виден в личном кабинете сразу после регистрации; CLI сохранит его локально и больше не спросит:
srwx login --token "$SRWX_TOKEN"
→ готово, токен сохранён в ~/.config/srwx/authШаг 3. Создайте зону — изолированное пространство для одного сайта: файлы, домены и кэш живут внутри зоны и не мешают соседним. Имя зоны попадёт в итоговый URL:
srwx zone create --name my-site
→ зона my-site созданаШаг 4. Опубликуйте директорию — CLI зальёт файлы на edge и сразу включит раздачу. Отдельной команды на активацию нет:
srwx deploy ./dist --zone my-site
→ опубликовано 42 файла, 1.3 МБ
→ live at https://my-site.cdn.srwx.appГотово — сайт раздаётся со всех 14 edge-серверов. Дальше по желанию: подключите свой домен, настройте публикацию и purge (сброс кэша) из CI или займитесь тонкой настройкой кэша.
CLI делает то же, что и HTTP API, но удобнее для ручной работы и скриптов. Под капотом — те же запросы, поэтому возможности совпадают один в один.
srwx login --token <token> войти один раз — токен сохранится локально
srwx zone create --name <zone> создать новую зону
srwx zone list показать зоны и занятое место
srwx deploy <path> --zone <zone> залить директорию на edge и получить URL
srwx purge --zone <zone> --url <url> сбросить кэш одного URL
srwx purge --zone <zone> --tag <tag> сбросить кэш всех файлов с тегом
srwx purge --zone <zone> --all сбросить весь кэш зоны разом
srwx stats --zone <zone> --since 24h трафик и число запросов за период
srwx domain add <host> --zone <zone> подключить свой домен к зонеБазовый адрес: https://api.cdn.srwx.app/v1. Каждый запрос несёт заголовок Authorization: Bearer <токен>, все ответы — JSON.
Тело запроса — содержимое файла, а путь в URL становится путём файла в зоне. В ответе replicated — на скольких edge-серверах уже лежит копия.
# заливаем файл — путь в URL станет путём файла в зоне
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 }"Ответ:
{
"status": "uploaded",
"path": "css/app.css",
"size": 15,
"replicated": 14
}Три режима: один URL, тег или вся зона. Тег (surrogate key) — метка группы файлов: пометьте релиз и обновляйте его одним запросом. В одном запросе можно передать и URL, и теги.
# сброс по URL — зона плюс точный адрес
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"}'
# сброс по тегу — например, по версии релиза
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"]}'В ответе два счётчика: purged — сколько записей сброшено, servers — на скольких серверах. Как только servers дошёл до 14, кэш чист во всей сети.
{
"purged": 1,
"servers": 14,
"ms": 4200
}Возвращает все зоны аккаунта: имя, занятое место и исходящий трафик за 30 дней. Удобно для ревизии перед чисткой старых зон.
# все зоны аккаунта: имя, место, трафик за 30 дней
curl https://api.cdn.srwx.app/v1/zones \
-H "Authorization: Bearer $SRWX_TOKEN"Ответ:
{
"zones": [
{
"name": "my-site",
"storage_mb": 1.3,
"egress_gb_30d": 12.4,
"domains": 1
}
]
}По умолчанию ключ кэша — путь плюс вся query-строка. Если файлы не зависят от UTM-меток и прочих трекинговых параметров, исключите их из ключа: попаданий в кэш станет больше, а лишних запросов к origin (серверу, где лежит сайт) — меньше.
# убираем UTM-метки из ключа кэша — hit-ratio вырастет
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"]}'Ответ:
{
"status": "updated",
"ignore_query": ["utm_*", "fbclid"]
}Файлы могут открываться с вашего домена — например, static.example.com/app.css вместо my-site.cdn.srwx.app/app.css. Для этого нужны два шага: запись у DNS-провайдера и одна команда CLI.
1. Добавьте у своего DNS-провайдера CNAME-запись (DNS-псевдоним) — она направит поддомен на нашу сеть. Выглядит так:
static.example.com. CNAME cdn.srwx.app.2. Подключите домен к зоне — с этого момента edge отвечает на него вашим контентом. Одна команда:
srwx domain add static.example.com --zone my-siteСертификат Let’s Encrypt выпустится автоматически, обычно в течение двух минут. До выпуска домен отвечает редиректом на служебный домен зоны.
Edge-сервер сначала ищет файл у себя: сперва в памяти, потом на NVMe. Не нашёл — спрашивает origin, сохраняет копию и дальше раздаёт именно её. Первый посетитель «прогревает» файл, остальные получают его мгновенно.
Типовой workflow для GitHub Actions: публикация при релизе и purge кэша по тегу релиза. Токен хранится в секретах репозитория под именем SRWX_TOKEN.
- name: Публикация на SRWX Edge
run: |
# ставим CLI и логинимся токеном из секретов репозитория
curl -sSL https://cdn.srwx.app/install | sh
srwx login --token "$SRWX_TOKEN"
# заливаем свежую сборку и сбрасываем кэш по тегу релиза
srwx deploy ./dist --zone my-site
srwx purge --zone my-site --tag "${GITHUB_REF_NAME}"