Як викласти сторінку на Cloudflare Workers

Тека з готовою сторінкою є, посилання немає. Викладемо її на Cloudflare Workers, а процедуру доручимо Claude Code: створимо skill, з яким публікація й оновлення зводяться до короткого прохання.

1. Що таке Cloudflare Workers для статики

Слово Workers звучить як "програми, які крутяться на сервері", і це правда. Але не вся: до воркера можна додати теку файлів, і тоді сервер просто віддає їх, як звичайний хостинг. Жодного рядка коду писати не доводиться.

Для сторінки з HTML, CSS і зображень такого режиму достатньо. У документації ця тека називається static assets, статичні асети, і в налаштуваннях проєкту вона займає лише одне поле зі шляхом.

Cloudflare роздає файли через свою мережу серверів і кешує їх ближче до відвідувачів.

2. Скільки це коштує

Запити до статичних файлів безкоштовні й не обмежені за кількістю. Це умова тарифу, а не обіцянка, що статистики відвідувань не буде.

Тоді звідки взялося відоме число - 100 000 запитів на добу? Це ліміт на виклики Worker-скрипта, тієї самої програми на сервері. Сторінка, до якої додали тільки теку, скрипта не має, і в цей лічильник вона не потрапляє.

Верхній шлях на схемі підходить нашій сторінці: файл віддається без виклику серверної програми. Нижній знадобиться, якщо пізніше додати Worker-скрипт.

Безкоштовний тариф усе-таки має ліміти, але вони про інше - про розмір того, що ви викладаєте:

Для сторінки з десятком зображень цих лімітів зазвичай достатньо. Перед великим проєктом перевірте актуальні умови Cloudflare: обмеження можуть змінитися. 25 MB на файл, до речі, здаються щедрими лише до першого відео.

3. Акаунт

Реєстрація на cloudflare.com звичайна: email і пароль, слідом лист з підтвердженням. Картка для безкоштовного тарифу не потрібна. Свій домен додавати теж не потрібно - сервіс це запропонує, але пропозиція стосується іншої половини продукту, захисту і прискорення наявних сайтів.

Після входу потрібний розділ називається "Workers & Pages", і лежить він не на видноті: у лівому меню спочатку група Build, у ній Compute, і вже всередині - "Workers & Pages". Панель з часом перебудовують, тож якщо цим шляхом розділу не знайти, шукайте за назвою: пошук угорі ліворуч відкривається комбінацією Ctrl + K. Два слова в назві - це два продукти Cloudflare; вам потрібна перша половина, Workers, і потрапите ви туди самі, нічого спеціально не обираючи.

Ще одна річ спливе під час першого деплою: Cloudflare попросить обрати ім'я піддомену для акаунта. Усі ваші проєкти житимуть на ньому, а адреса складається з двох частин - ім'я проєкту плюс ваш піддомен:

my-landing.example-account.workers.dev
|          |               |
|          |               спільний домен Cloudflare
|          піддомен вашого акаунта
ім'я проєкту

змінити це ім'я потім важко, тож перше, що спало на думку, краще не вписувати.

4. Перший деплой

Спочатку коротко подивимося, який вигляд має публікація в панелі. Це необов'язкове знайомство з сервісом: якщо хочете одразу налаштувати деплой агентом і зберегти одну адресу, переходьте до підготовки нижче.

landing/          <- цю теку віддаємо
  index.html      <- головна сторінка, ім'я обов'язкове
  wrangler.jsonc  <- агент створить перед першим деплоєм
  style.css
  img/
    hero.png

Перед публікацією перевірте вміст обраної теки: файли в ній стануть публічними. Приберіть з неї особисті файли і чернетки, які не збиралися показувати.

Вручну через панель

У розділі з проєктами є кнопка, яка створює новий проєкт. Далі вам запропонують віддати файли: можна обрати один файл, можна теку цілком. Завантажили, підтвердили - Cloudflare розклав їх у себе і повернув посилання. Назви кнопок і порядок екранів тут змінюються частіше, ніж виходять статті, тож тримайтеся суті, а не підписів: створити проєкт, віддати файли, отримати адресу.

Відкрийте отриману адресу https://…workers.dev і перевірте сторінку та зображення. Це можна зробити з того самого комп'ютера. Телефон знадобиться для додаткової перевірки доступності й мобільного вигляду.

Після публікації через панель локального конфіга не з'являється. Skill з нашого прикладу сам не пов'язує теку з таким проєктом: без конфіга він створить нове ім'я і другу адресу. Cloudflare дозволяє оновлювати наявний Worker через Wrangler, але для цього треба окремо налаштувати конфіг на його ім'я.

Що потрібно, щоб це робив агент

Для подальших публікацій налаштуємо skill. Підготовка потрібна один раз на вашому комп'ютері.

Програм знадобиться небагато. Акаунт у вас уже є, потрібен ще Node.js - перевіряється командою node -v, і якщо її не знайшли, спочатку доведеться його встановити. Сам wrangler встановлювати не треба: npx завантажить свіжий сам, коли до нього дійде справа.

Другий крок на схемі - вхід, і його варто пройти прямо зараз, до всього іншого:

npx wrangler login    # відкриється браузер, там кнопка підтвердження

Команду виконати в терміналі. Якщо цього кроку немає, уся процедура впреться в нього на першому ж прогоні, і скидатиметься це на зламаний skill, хоча річ зовсім не в ньому. Перевірити, що все вийшло, можна командою npx wrangler whoami - вона покаже, під яким акаунтом ви увійшли.

Для цього маршруту достатньо входу через браузер. API-токен розібрано в необов'язковому продовженні наприкінці.

Третій крок схеми, npx wrangler deploy, запускатиме агент з теки сторінки. Спочатку дамо йому правила підготовки конфіга і публікації.

5. Свій skill для деплою

Поки сторінка одна, вистачить і прохання в чат. Але щойно заведете другу, третю, десяту - і щоразу доведеться пояснювати агенту одне й те саме: яку теку беремо, як назвати проєкт, що робити з файлом налаштувань. На третій раз це набридає.

Що skill має вміти

П'ять кроків, і кожен вирішує конкретну проблему, а не стоїть для повноти:

1. Взяти теку, яку назвали, і переконатися, що index.html лежить у її корені. Дешева перевірка, яка ловить найчастішу помилку до деплою, а не після.
2. Визначити ім'я проєкту - вивести його з імені теки, а не питати щоразу.
3. Подивитися, чи лежить усередині теки, поряд з index.html, файл wrangler.jsonc. Немає - створити; є - взяти ім'я звідти і нічого в ньому не переписувати.
4. Запустити деплой з цієї теки і показати команду до запуску.
5. Повернути публічну адресу і нагадати перевірити за нею сторінку та зображення.

Ім'я проєкту виводиться з теки

Це головне рішення всієї процедури, і саме його не можна залишати агенту на імпровізацію. Якщо ім'я не задано правилом, агент вигадає його сам - і наступного разу вигадає інше. Вийде другий проєкт з іншою адресою, а перший залишиться висіти.

Правило просте: ім'я теки і є ім'я проєкту. В імені воркера можуть бути тільки малі латинські літери, цифри і дефіс, тому все інше - крапки, пробіли, підкреслення - замінюємо на дефіс і додаємо короткий суфікс, чотири випадкові символи:

landing/                 ->  landing-42c2
my.first.page/           ->  my-first-page-8e10
portfolio-2026/          ->  portfolio-2026-b7a3

Суфікс потрібен, щоб дві теки з однаковим іменем у різних проєктах не зайняли одну адресу. Генерується він один раз, під час створення файлу налаштувань, і обов'язково командою, а не з голови агента: інакше він візьме суфікс з прикладу, і у всіх, хто читав ту саму статтю, він виявиться однаковим. Далі суфікс завжди читається з конфіга. Саме тому skill спочатку дивиться на наявний конфіг і лише потім щось пише.

Файл налаштувань пише агент

У wrangler.jsonc агент записує ім'я проєкту і налаштування публікації, щоб запускати деплой без запитань у терміналі. Конфіг лежить поряд з index.html, тому шлях до файлів у ньому - крапка, "ця сама тека":

{
  "name": "landing-42c2",
  "compatibility_date": "2026-09-07",
  "assets": { "directory": "." }
}

Поле compatibility_date вибирає сумісну поведінку платформи на вказану дату. Для нового конфіга агент ставить поточну дату, як рекомендує документація Cloudflare; під час повторної публікації зберігає попередню.

Класти конфіг рівнем вище, поряд з текою, не варто: ім'я файлу фіксоване, в одному каталозі такий файл може бути тільки один, і друга тека або перезапише конфіг першої, або викладеться під її іменем. Усередині теки кожен проєкт самодостатній, і деплой запускається прямо з неї.

Побічний ефект такого розташування: конфіг лежить у тій самій теці, що й сторінка, тому поїде на хостинг разом з нею і відкриватиметься за посиланням. Секретів у ньому немає - ім'я, дата і крапка, - а кому заважає, той кладе поряд файл .assetsignore і перелічує в ньому, що не викладати.

Три правила, які варто явно прописати в завданні, інакше агент їх не вгадає:

• файлу немає - створити, показавши, що записав;
• файл є - ім'я і дату залишити як є, навіть якщо сьогоднішня дата інша;
• переписувати файл тільки тоді, коли вміст справді змінюється.

Чотири прохання, які варто тримати під рукою

Перше - власне завдання на skill. Воно довше за інші, бо це єдиний раз, коли ви описуєте процедуру цілком:

Збери skill для деплою статичних сторінок на Cloudflare Workers.
Поклади його в .claude/skills/ цього проєкту.
Наприкінці покажи шлях до створеного SKILL.md і як явно викликати skill.

Спочатку прочитай актуальну документацію Cloudflare про Workers
і static assets: команди та поля конфіга могли змінитися.
Якщо щось в описі нижче розійдеться з документацією - скажи мені,
мовчки не переписуй.

В описі skill перелічи фрази, за якими він має спрацьовувати,
щонайменше: "виклади теку", "виклади заново", "задеплой на Cloudflare".

Процедура: беру теку, перевіряю, що в корені є index.html.
Ім'я проєкту виводжу з імені цієї теки: у ньому лишаються тільки
малі латинські літери, цифри і дефіс, усе інше (пробіли,
підкреслення, великі літери, кирилиця) замінюю на дефіс.
У кінець додаю через дефіс суфікс із чотирьох символів.
Суфікс не вигадую, а отримую командою:
node -e "console.log(crypto.randomUUID().slice(0,4))"
Конфіг wrangler.jsonc лежить усередині теки, яку публікую, поряд
з index.html, і assets.directory у ньому дорівнює ".".
Якщо конфіга немає - створюю його: name, compatibility_date,
assets.directory. Для нового compatibility_date беру поточну дату
у форматі YYYY-MM-DD. Показую, що записав.
Якщо конфіг є - ім'я і дату беру звідти і не переписую.
Переписую файл тільки тоді, коли вміст справді змінюється.
Якщо конфіг є, але assets.directory вказує не на цю теку
або в конфігу є поле main - зупиняюся і кажу, деплой не запускаю.
Якщо просять викласти заново, а конфіга в теці немає - зупиняюся
і питаю, новий проєкт не створюю.
Деплой: npx wrangler deploy з теки проєкту. Команду показую до запуску.
У відповіді повертаю публічну адресу і нагадую перевірити за нею
сторінку та зображення. Під час оновлення адреса має лишитися тією самою.
Якщо немає Node.js або авторизацію не пройдено - кажу про це,
а не намагаюся обійти.
Якщо акаунт ще не має піддомену workers.dev - кажу про це:
неінтерактивний деплой на цьому падає.

Після створення відкрийте показаний агентом файл .claude/skills/<ім'я>/SKILL.md: у ньому мають бути правила вище. Перед другим проханням явно викличте створений skill способом, який показав агент. Якщо skill не вдається знайти, попросіть перевірити шлях і його доступність у поточному проєкті.

Друге - перевірка перед справою. Корисне перед першим деплоєм теки, коли хочеться побачити план до того, як щось поїде назовні; якщо тек кілька, його задають для кожної:

Файли не створюй і не змінюй, wrangler не запускай. Тільки покажи,
що ти збираєшся зробити з текою landing: яке ім'я проєкту,
який конфіг запишеш, яку команду запустиш.

Одне застереження: суфікс з'являється в момент запису конфіга, тож для теки, де конфіга ще немає, ім'я в плані та ім'я на реальному прогоні можуть не збігтися. Збіжиться все інше.

Третє і четверте - робочі, заради них усе й затівалося:

Виклади теку landing на Cloudflare Workers.

Я поправив index.html у landing. Виклади заново на Cloudflare Workers.

Після першої публікації відкрийте отримане посилання, перевірте текст і зображення. Потім змініть одну помітну фразу в landing/index.html і надішліть четверте прохання. Оновіть сторінку за попередньою адресою: має з'явитися нова фраза. Якщо адреса змінилася, попросіть агента перевірити ім'я в конфігу до наступного деплою.

На цьому основний маршрут завершено: skill створено, сторінку опубліковано, оновлення перевірено за тим самим посиланням. Перед кожною публікацією лишається обрати потрібну теку і подивитися команду агента.

6. Додаткові сценарії

Далі можна не читати, поки у вас немає завдання готувати багато тек разом або запускати деплой без входу через браузер.

Коли процедури стає мало

Skill-інструкція добре працює, поки тек одиниці або десятки. Далі починає заважати те, що агент щоразу перечитує процедуру і виконує її вручну: на півсотні тек це довго і не завжди однаково.

Тоді процедуру переписують у скрипт: він обходить теки сам, пише конфіги, пропускає ті, де нічого не змінилося, і друкує зведення. А skill нікуди не дівається - він просто викликає скрипт замість того, щоб писати конфіги самому, а деплой і далі запускає сам.

Писати його теж не вам. Агент уже має докладний опис процедури - ваш skill, - тож прохання виходить коротким:

Напиши на Python скрипт, який робить те саме, що описано в моєму skill
для деплою, тільки одразу для всіх тек проєкту.

Бере теки, де в корені є index.html;
у node_modules, .git і dist не зазирає.
Для кожної збирає ім'я за нашим правилом і пише wrangler.jsonc
усередину теки.
Якщо конфіг уже є - ім'я і compatibility_date бере звідти,
а файл перезаписує тільки тоді, коли вміст реально змінився.
Якщо конфіг не читається - не чіпає його, каже про це
і пропускає теку.
За замовчуванням тільки показує план і нічого не пише;
запис - за явним прапорцем.
Потрібен фільтр, щоб прогнати тільки обрані теки.
Скрипт тільки готує конфіги, деплой не запускає.
Наприкінці друкує таблицю: тека, ім'я проєкту, що зроблено.
Якщо щось у цьому описі неоднозначно - спитай, мовчки не додумуй.

Показ плану дозволяє перевірити список тек до запису. Збереження імені й дати захищає наявні конфіги від випадкових змін. Сам скрипт тільки готує налаштування; публікацію й далі виконує skill.

Токен доступу

На своєму комп'ютері ви вже увійшли через npx wrangler login. Wrangler зберігає авторизацію, якою користуються і команди агента.

Якщо потрібен автоматичний запуск без входу через браузер або вужчі права, використовують API-токен. Його можна створити в профілі: аватарка, профіль, розділ з API-токенами. Пряма адреса - dash.cloudflare.com/profile/api-tokens.

Форма створення має лячний вигляд: групи прав, ресурси, якісь фільтри. Насправді рішень там чотири, і половину полів можна не чіпати зовсім.

1. Ім'я токена. Через півроку ви не згадаєте, навіщо він, тому пишіть конкретно: "деплой сторінок з ноутбука", а не "token 2".
2. Права. Збирати їх по одному не потрібно і не варто. У списку готових наборів є Edit Cloudflare Workers - у ньому вже зібрано все, що потрібне для публікації.
3. Ресурси. Обмежте токен одним акаунтом, тим самим, куди викладаєте. Навіть якщо акаунт у вас єдиний, оберіть його явно: акаунтів може стати більше, а токен залишиться тим самим.
4. Термін життя і фільтр за IP. Поля необов'язкові. Термін має сенс поставити, коли токен потрібен на один вечір або для чужої машини; у звичайній роботі їх залишають як є.

Далі токен кладуть у змінну середовища CLOUDFLARE_API_TOKEN, а акаунт вказують у CLOUDFLARE_ACCOUNT_ID. Змінна середовища - це налаштування вашої машини, яке програми читають самі; wrangler знайде обидві без вашої участі. Як змінні влаштовані і де їх правильно тримати - окрема розмова, тут достатньо того, що це місце, а не рядок у листуванні.