White-Label веб-приложение: кастомные домены и брендинг

White-Label веб-приложение

Представьте: ваш SaaS-продукт хотят продавать крупные клиенты, но им нужен собственный бренд — свой домен, логотип, цвета и даже email-шаблоны. Без white-label вы бы писали отдельную копию для каждого клиента, что не масштабируется. Мы реализовали white-label для 20+ проектов; наши инженеры имеют опыт в multi-tenant архитектуре. Реализуем white-label версию вашего веб-приложения с полной изоляцией тенантов, кастомными доменами и автоматическим выпуском SSL через Cloudflare. Свяжитесь с нами для аудита — и мы подготовим план внедрения за 2 дня.

Проблемы, которые решаем

Изоляция данных между клиентами. Если данные двух клиентов окажутся в одной таблице без фильтра по tenant_id — это катастрофа. Используем middleware, который на основе домена определяет тенанта и прокидывает его ID во все запросы. Для ключевых сущностей в Prisma добавляем @@index([tenantId]) и всегда фильтруем по нему. Так мы обрабатываем до 10 000 запросов в день без ошибок изоляции.

Кастомные домены и SSL. Клиент хочет app.acmecorp.com, но вам нужно выпустить SSL-сертификат для каждого домена. Ручной выпуск через Let's Encrypt — это тысячи запросов в день. Решение — Cloudflare Custom Hostnames: они сами выпускают и продлевают сертификаты, а мы только верифицируем CNAME-запись. Процесс полностью автоматизирован и занимает пару минут.

Брендинг без переписывания UI. Каждый клиент хочет свои цвета, логотип, шрифты и даже кастомный CSS. Хранить это в CSS-переменных недостаточно: нужно динамически генерировать стили и подключать шрифты. Мы используем компонент TenantStylesheet, который вставляет CSS-переменные и опциональный кастомный CSS на основе настроек тенанта.

Как мы это делаем: кейс реализации

Из нашей практики: один из проектов — white-label для платформы управления проектами. Наш клиент — крупная компания с 50+ брендами. Стек: Next.js 14 (App Router), Prisma, PostgreSQL, Cloudflare и Resend для email.

Middleware для определения тенанта. В Next.js мы создали middleware, который перехватывает запросы и по заголовку host определяет тенанта. Если домен не найден — редирект на 404. Пробрасываем tenantId и tenantSlug в заголовки ответа, чтобы серверные компоненты могли их прочитать. Это решает проблему изоляции на уровне маршрутизации.

Custom Domain верификация. Когда клиент добавляет кастомный домен, мы проверяем, что CNAME указывает на нашу платформу. Используем Node.js dns/promises для поиска CNAME. Если запись верна, сохраняем домен в БД и через Cloudflare API добавляем custom hostname. Сертификат выпускается автоматически за пару минут.

Email с брендингом. Все транзакционные письма (приглашения, уведомления) отправляются через Resend с брендингом тенанта: логотип, цвет, имя отправителя. Если клиент скрыл watermark, мы не показываем плашку "Powered by".

Процесс работы

Сравнение подходов к изоляции

Сроки ориентировочно

Минимальная white-label конфигурация (субдомены + брендинг) — от 5 рабочих дней. Полное решение с кастомными доменами, SSL и email — до 10 рабочих дней. Если требуется изоляция данных на уровне отдельных БД — до 15 дней. Стоимость рассчитывается индивидуально после аудита вашего стека. Закажите консультацию — мы подготовим точную оценку.

Что входит в работу

• Исходный код middleware, компонентов брендинга и модуля custom domain
• Документация по добавлению нового клиента (API-эндпоинты, админка)
• Пример CI/CD для деплоя на Vercel или собственный сервер
• 30 дней технической поддержки после запуска

Когда стоит выбрать white-label?

Сравните: кастомное решение — копирование кода, отдельные репозитории, двойные доработки. White-label — один код, одна инфраструктура, тысяча клиентов. По нашим данным, поддержка white-label обходится в 3–5 раз дешевле, чем обслуживание отдельных инстансов. А скорость внедрения нового клиента сокращается с недель до часов, что снижает операционные расходы. Если в вашем продукте более 10 клиентов, white-label почти всегда выгоднее.

Как реализовать изоляцию данных между тенантами?

Мы используем подход shared database, per-tenant rows: все записи в таблицах помечены tenantId, а в Prisma — глобальный middleware, который автоматически добавляет фильтр по текущему тенанту. Это проще, чем отдельные схемы, и не требует сложной оркестровки. Если нужна чистая изоляция — можем перейти на отдельные базы данных с автоматическим созданием при регистрации клиента. Проверяем корректность фильтрации нагрузочными тестами: симулируем 1000 одновременных запросов от разных тенантов.

Типичные ошибки и как их избежать

• Не проверить CNAME после верификации. Клиент может удалить DNS-запись — тогда домен перестанет работать. Мы добавляем cron-задачу, которая раз в час проверяет CNAME для всех активных доменов.
• Игнорировать watermark. Некоторые клиенты не хотят видеть "Powered by". Дайте им возможность отключить это через настройки брендинга.
• Забыть про SEO. На кастомном домене должны быть уникальные title и description. Используйте generateMetadata в Next.js, чтобы подставлять appName и favicon из настроек тенанта.

Используем Cloudflare Custom Hostnames для автоматизации SSL и Next.js Middleware для определения тенанта. Получите консультацию по архитектуре white-label уже сегодня. Свяжитесь с нами — мы бесплатно оценим ваш проект и предложим план внедрения.

Разработка SaaS-платформ

Мы знаем эту боль наизусть. Запускаешь MVP с авторизацией и подпиской, а через полгода упираешься в архитектурные решения, которые нельзя откатить без переписывания половины кода. Multi-tenancy, биллинг, аудит логов, feature flags — каждый блок требует предварительного проектирования, иначе цена ошибки при масштабировании уходит в десятки человеко-месяцев, а в деньгах — от 3–5 млн ₽ на рефакторинг.

За 8 лет работы над SaaS-продуктами мы проверили на практике, какие решения работают, а какие превращают поддержку в ад. Ниже — архитектурные подходы, которые используем сами и рекомендуем клиентам.

Как мы строим multi-tenancy: изоляция без оверхеда

Первое, что решаем — схема разделения данных. Shared schema (tenant_id на каждой таблице) — наш стандартный выбор для большинства проектов. Все арендаторы в одной базе, миграции применяются разом, операционная сложность минимальна. В Laravel реализуем через Global Scope:

protected static function booted(): void
{
    static::addGlobalScope('tenant', function (Builder $builder) {
        $builder->where('tenant_id', TenantContext::current()->id);
    });
}

Глобальный скоуп — только первый уровень защиты. Обязательно добавляем Row-Level Security в PostgreSQL — она сработает, если приложение пропустит WHERE tenant_id = ?:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON orders
    USING (tenant_id = current_setting('app.tenant_id')::uuid);

Для enterprise-клиентов, которым нужна физическая изоляция, выделяем отдельную базу. Такой гибридный подход (shared + dedicated) используется в 80% зрелых SaaS: базовый продукт на shared schema, премиум — на отдельной инстанции. Мы внедряем его с первого спринта, чтобы не переписывать логику позже.

Модель multi-tenancy описана в Wikipedia: Multitenancy — рекомендуем ознакомиться для понимания trade-off'ов.

Почему биллинг — самый недооценённый блок

Upgrade посреди расчётного периода, downgrade с отложенным вступлением, истёкший trial, failed payment с grace period — Stripe Billing закрывает 90% сценариев из коробки. Обязательно обрабатываем вебхуки (customer.subscription.updated, invoice.payment_failed) с идемпотентным ключом — без него retry на клиенте приведёт к двойному списанию.

Для рынка СНГ — ЮKassa или Tinkoff recurring. API менее удобны, но покрывают требования 54-ФЗ.

Сравнение: переход с самописного биллинга на Stripe сокращает время разработки подписочной логики на 60%, а количество багов — на 80% (данные наших проектов). Экономия в деньгах для проекта среднего размера — до 2–3 млн ₽ на этапе разработки.

Onboarding: как не потерять пользователя до aha-moment

Технически onboarding — это wizard с persistent состоянием, который нельзя случайно пропустить. Таблица onboarding_steps с чек-листом, middleware редиректит на незавершённый шаг. После завершения — флаг в user settings, middleware отключается.

Критический нюанс: показывайте прогресс реального продукта, не абстрактные шаги. «Создайте первый отчёт» вместо «Завершите шаг 3 из 5». Мы используем drip-кампании через Customer.io или собственную очередь с отложенными jobs — если пользователь выполнил ключевое действие, следующее письмо не отправляется.

Feature flags и управление доступом

SaaS с тарифами требует гранулярного контроля. Не делайте if ($user->plan === 'pro') по всему коду — через месяц он станет неподдерживаемым. Вместо этого:

• Backend: Gate + Policy с проверкой через таблицу features, связанную с планами.
• Frontend: контекст с флагами, загружаемый при инициализации приложения.
• Open-source инструменты: Unleash или Growthbook — UI для A/B-тестов и rollout.

Как защитить API от агрессивных клиентов

Rate limiting — must-have для публичного API. Один клиент может положить всех остальных. В Laravel используем Redis с sliding window counter:

Каждый ответ содержит X-RateLimit-Remaining и X-RateLimit-Reset — клиенты рассчитывают на эти заголовки.

Аудит-логи и мониторинг: что, кто и когда

Без аудит-лога невозможно узнать, кто удалил проект или когда изменились настройки биллинга. Таблица audit_logs с индексами по (tenant_id, created_at) и (subject_type, subject_id). В Laravel — Observer'ы на ключевых моделях.

class OrderObserver
{
    public function created(Order $order): void
    {
        AuditLog::create([
            'tenant_id' => $order->tenant_id,
            'user_id' => auth()->id(),
            'action' => 'created',
            'subject_type' => Order::class,
            'subject_id' => $order->id,
        ]);
    }
}

Мониторинг: Sentry для exception tracking, Grafana + Prometheus для метрик. Алерты на error rate > 5% и response time p95 > 2s.

Опыт нашей команды и гарантии

Над SaaS-платформами работают инженеры с 8+ летним опытом, за плечами — 50+ проектов, от стартапов до enterprise с миллионными нагрузками. Мы даём гарантию на архитектурные решения: если выбранный подход не масштабируется — перепроектируем за свой счёт.

Deliverables и гарантии

• Документация архитектуры: схемы, ERD, sequence diagrams.
• Настройка CI/CD (GitHub Actions / GitLab CI).
• Доступы к репозиторию, стейджингу и продакшену.
• Обучение команды: 2–3 сессии по код-ревью и runbook.
• Post-launch поддержка 1 месяц.
• Гарантия на архитектуру: бесплатный рефакторинг, если решение не проходит по нагрузке.

Процесс работы

1. Discovery (1–2 недели) — аудит текущей архитектуры, скоуп MVP, приоритеты фич.
2. Проектирование (1 неделя) — выбор стека, схема multi-tenancy, план биллинга.
3. Разработка (4–12 недель) — спринты по 2 недели, демо после каждого.
4. Тестирование (1 неделя) — нагрузочные тесты под target нагрузки, security audit.
5. Деплой и обучение (1 неделя) — rollout, настройка мониторинга, передача документации.

Ориентиры по срокам

Стоимость рассчитывается индивидуально — свяжитесь с нами, мы оценим проект за 2 дня. Закажите разработку под ключ: от проектирования до деплоя с гарантией архитектуры. Получите консультацию по архитектуре вашего продукта — первый час бесплатно.