Власні домени для SaaS: дозвольте клієнтам використовувати свій домен із Cloudflare for SaaS

Коротка відповідь

Щоб клієнт міг відкривати ваш застосунок на власному домені, наприклад portal.customer.com, зареєструйте цей домен як custom hostname у вашій зоні Cloudflare. Клієнт додає один CNAME-запис, що вказує на вас, Cloudflare перевіряє, що він контролює цей хостнейм, центр сертифікації видає сертифікати, і запити починають надходити до вашого застосунку.

Станом на жовтень 2026 року на сторінці тарифів Cloudflare for SaaS зазначено, що тарифи Free, Pro і Business включають 100 власних хостнеймів, кожен додатковий коштує $0.10, а максимум для цих тарифів становить 50 000 хостнеймів.

Будь-яку архітектуру визначають два обмеження. Клієнти не можуть спрямувати на вас кореневий (apex) домен (customer.com) без платного додатка Enterprise. А wildcard-хостнейми, власні сертифікати та вибір центру сертифікації доступні лише в Enterprise. Налаштування Cloudflare займає кілька кроків. Робота над продуктом навколо нього триває довше, і саме їй присвячена більша частина цього посібника.

Що таке custom hostname

Custom hostname — це домен, яким володіє ваш клієнт і який Cloudflare спрямовує у вашу зону. Посібник із налаштування описує чотири складники:

• SaaS-зона. Ваш власний домен у Cloudflare з увімкненим Cloudflare for SaaS. Для початку достатньо зони на тарифі Free.
• Fallback origin. Проксований DNS-запис, наприклад proxy-fallback.yourapp.com, куди надходить трафік власних хостнеймів.
• CNAME-ціль. Необов’язкова, зручніша назва, на яку клієнти спрямовують свій домен, наприклад customers.yourapp.com.
• Custom hostname. Домен клієнта, створений через API або панель керування, зі своїм станом валідації. Для кожного Cloudflare випускає два сертифікати: основний ECDSA P-256 і резервний RSA 2048 біт для старіших клієнтів.

Якщо ваш застосунок працює на Cloudflare Workers, платформі, на якій Dardo будує свої проєкти, Worker може бути fallback origin. Маршрут */* перехоплює запити для всіх власних хостнеймів, а ваш код читає заголовок Host, щоб визначити тенанта. Cloudflare також пропонує власні метадані для кожного хостнейму, але це платний додаток Enterprise, тож на інших тарифах такий пошук виконується у вашій базі даних, наприклад D1.

Як працює процес

1. Клієнт вводить домен у налаштуваннях вашого застосунку. Ваш бекенд нормалізує його та викликає endpoint Create Custom Hostname із вибраним методом валідації сертифіката.
2. Клієнт додає DNS-запис, який ви йому показуєте, наприклад portal.customer.com CNAME customers.yourapp.com.
3. Cloudflare перевіряє право власності на хостнейм. Валідація в реальному часі запускається, коли з’являється CNAME, і це може означати короткий простій. Попередня валідація використовує TXT-запис або HTTP-токен до зміни DNS, для доменів, які вже працюють. Попередня валідація не підтримується, якщо зона самого клієнта теж у Cloudflare (конфігурація «Orange-to-Orange»).
4. Центр сертифікації перевіряє контроль над доменом і видає сертифікати.
5. Хостнейм готовий, коли його status і ssl.status мають значення active, а DNS вказує на вашу ціль. Cloudflare попереджає, що TLS-рукостискання може пройти ще до того, як ssl.status стане active, тому вважайте джерелом істини endpoint з відомостями про custom hostname.

Методи валідації сертифіката

Посібник Cloudflare з валідації пропонує такі варіанти:

Валідація не чекає вічно. Cloudflare повторює перевірку хостнейму 75 разів протягом семи днів, і, згідно з його графіком повторних спроб, «якщо валідація не вдається, custom hostname буде видалено». Токени сертифікатів теж спливають: через 7 днів із Let's Encrypt і через 14 днів із Google Trust Services або SSL.com.

Скільки це коштує станом на жовтень 2026 року

На сторінці тарифів $0.10 вказано без періоду. У анонсі 2022 року Cloudflare описала це як зниження ціни «з $2 до $0.10 на місяць». За такою щомісячною ставкою 1000 доменів клієнтів означають 900 понад включені 100, тобто $90 на місяць.

Два правила тарифікації важливі для дизайну продукту. Згідно зі сторінкою квот і тарифікації Cloudflare, кожен хостнейм враховується в користуванні, доки ви його не видалите, зокрема «хостнейми, що очікують валідації або активації». А для тарифів, окрім Enterprise, діє поріг застосування в API, після якого нові хостнейми відхиляються.

Де це ламається

Apex-домени

Посібник Cloudflare з налаштування категоричний: «За замовчуванням використання A-запису для вказування на цільовий домен не підтримується». Більшість DNS-провайдерів не дозволяють CNAME в корені домену, тож клієнтам потрібен піддомен, наприклад www.customer.com або app.customer.com. Apex proxying призначає вашому акаунту статичні префікси IP-адрес, щоб клієнти могли використовувати A-запис, але це платне додаткове рішення для Enterprise з окремою вартістю. Без нього просіть клієнтів використати піддомен і поясніть, як у свого DNS-провайдера налаштувати переадресацію з кореневого домену на нього.

Центри сертифікації та CAA-записи

У довіднику Cloudflare щодо центрів сертифікації для custom hostnames названо Let's Encrypt (сертифікати на 90 днів), Google Trust Services та SSL.com (14, 30 або 90 днів). Обирати центр сертифікації можна лише в Enterprise; в інших випадках Cloudflare використовує свій центр за замовчуванням і спершу перевіряє CAA-записи. Якщо CAA-записи клієнта не дозволяють цей центр, випуск завершується помилкою «CAA records block issuance», і виправити це може лише клієнт. CAA-запити проходять по ланцюжках CNAME, тож CAA-записи вашого власного цільового домену теж враховуються. Посібник з усунення несправностей описує інші збої на боці клієнта: некоректний DNSSEC і DNS-сервери, що відповідають SERVFAIL.

Поновлення

Сертифікати custom hostname діють 90 днів і можуть поновлюватися за 30 днів до завершення терміну. Активні хости без wildcard поновлюються автоматично через HTTP. Якщо хост більше не активний, наприклад через зміну DNS клієнтом, клієнт має розмістити новий токен, а надіслати його йому маєте ви. Wildcard-сертифікати можна поновлювати лише через TXT, і саме це автоматизує Delegated DCV.

Клієнти з іншою CDN або з Cloudflare

Cloudflare зазначає, що custom hostnames, які використовують іншу CDN, несумісні, якщо ця CDN приховує DNS-записи. Клієнти, чиї домени вже на Cloudflare, створюють протилежну проблему: якщо вони йдуть, а ви не видаляєте їхній хост, він може й надалі вести на ваш сервіс навіть після зміни DNS.

Workers перед шляхами валідації

Якщо ваш запасний origin — це Worker, він має пропускати /.well-known/pki-validation/* і /.well-known/acme-challenge/* без змін. Універсальний маршрут, що відповідає сторінкою 404 вашого застосунку, ламає HTTP-валідацію.

Продуктова робота навколо цього

• Контроль тарифів. Визначте, які з ваших тарифів включають власні домени і скільки саме, та перевіряйте це до звернення до Cloudflare. Його квота й поріг — це стелі, а не ваша цінова політика.
• Екран підключення. Одне поле введення. Переводьте текст у нижній регістр, прибирайте протокол і шлях, відхиляйте кореневі домени, якщо ви не купили apex proxying, і відхиляйте назву вашої власної зони, яку, за словами Cloudflare, ніколи не слід створювати як custom hostname. Потім покажіть точний запис, який треба додати, з кнопкою копіювання.
• Два статуси простою мовою. Хост і сертифікат валідуються окремо, тож показуйте обидва. Перетворюйте ssl.validation_errors на інструкції: «CAA-записи вашого домену не дозволяють наш центр сертифікації; додайте цей запис» краще, ніж «pending_validation». Відповідь на створення може ще не містити записів валідації, тож запитайте хост повторно після короткої затримки. Вебхук-сповіщення Cloudflare повідомляють про події валідації та випуску, що краще за опитування.
• Моніторинг поновлень. Щоденне завдання, яке позначає хости, чий сертифікат неактивний або чий DNS більше не вказує на вас, щоб ваша команда дізналася про це раніше за клієнта.
• Прибирання. Видаляйте хости, які так і не пройшли валідацію, і хости клієнтів, що пішли. За обидва стягується плата, доки їх не видалено.
• Ізоляція тенантів. Визначайте тенанта лише за активними хостами у вашій базі даних. Якщо тенанти також отримують піддомени вашого домену, у документації Vercel щодо доменів зазначено, що cookie, встановлений одним тенантом для батьківського домену, потрапляє до інших, тому тримайте панель керування й вхід на окремому домені.
• Інструкція для підтримки. Коротка сторінка для вашої команди, що зіставляє кожну помилку з тим, хто її виправляє: відсутній CNAME, CAA, DNSSEC і SERVFAIL — на клієнті; токени, ліміти центру сертифікації й маршрути Worker — на вас.

Саме такою роботою Dardo займається в галузі розробки вебзастосунків, а white-label клієнтські портали — це місце, де власні домени просять найчастіше.

Альтернативи: Vercel і Netlify

Якщо ваш застосунок уже працює деінде, обидва хостинги підтримують клієнтські домени з власними задокументованими обмеженнями станом на жовтень 2026 року.

Підтримка кореневих доменів у Vercel — найочевидніша відмінність: клієнти можуть спрямувати кореневий домен на нього за допомогою A-запису. Зверніть увагу, що тариф Hobby за правилами добросовісного використання Vercel обмежений «лише некомерційним особистим використанням», тож SaaS, що приносить дохід, починає з Pro. Рекомендація Netlify щодо 50 аліасів робить його поганим вибором для одного розгортання, яке обслуговує сотні клієнтських доменів.

Коли це варто будувати

Якщо просять двоє-троє клієнтів, додайте їхні хости в панелі Cloudflare й ведіть чекліст. Створюйте самообслуговування, коли власні домени стають частиною тарифу, який ви продаєте, або white-label пропозиції. Якщо клієнтам у великому масштабі потрібні кореневі домени чи wildcard-домени, поговоріть із Cloudflare про Enterprise, перш ніж проєктувати систему під обмеження.

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