URL-сокращатели с возможностью self-hosted: обзор open-source решений

Self-hosting URL-сокращателя раньше был проектом на выходные. PHP плюс MySQL плюс контроллер перенаправлений — и у вас что-то, напоминающее Bitly образца 2010 года. Категория не стояла на месте: современные open-source решения более функциональны, чем YOURLS, требуют больше усилий в обслуживании, чем «проект на выходные», и все еще значительно отстают от hosted-продуктов в плане аналитики. В этой статье — честный обзор ситуации: что на самом деле предлагают различные open-source варианты, от чего вы отказываетесь по сравнению с hosted-сервисом и в какой момент математика начинает склоняться в пользу оплаты стороннего сервиса для обработки перенаправлений.

Статья предназначена для инженерных команд или технических специалистов, которые задумываются о self-hosting. В статье об альтернативах Bitly приведено более широкое сравнение; здесь же мы подробно остановимся именно на open-source решениях. В руководстве по self-hosting Elido в k3s рассматривается сценарий, когда вы хотите разместить сам Elido, а не стороннюю альтернативу.

Что вы получаете в нагрузку#

URL-сокращатель выглядит обманчиво простым. База данных, процесс перенаправления, дашборд для управления ссылками. В продакшене за этой простой формой скрываются четыре операционных уровня:

Уровень перенаправлений. Это критический путь. Каждый сокращенный URL, на который кликают в интернете, проходит через этот код. Он должен быть быстрым (p95 менее 15 мс, если вас заботит пользовательский опыт), высокодоступным (простой здесь ломает все ссылки, которые вы когда-либо распространяли) и географически распределенным, если ваши пользователи находятся не в одном регионе. В статье о p95 для перенаправлений < 15 мс рассказывается, что на самом деле означает «быстро» и как этого достичь.

Конвейер аналитики кликов. Запись, хранение и запрос событий кликов. При больших объемах это отдельная система, отличная от уровня перенаправлений — обычно Kafka или Redpanda для приема данных, ClickHouse или BigQuery для хранения, отдельный API для запросов. Большинство open-source сокращателей полностью пропускают этот этап и хранят клики в той же реляционной базе данных, где находятся ссылки. Это работает при небольших объемах, но падает, как только вы переходите порог в несколько миллионов кликов в месяц.

Дашборд. Интерфейс для создания, редактирования, организации и анализа ссылок. Это то место, где open-source проекты тратят основную часть работы над функционалом, и где разрыв с hosted-продуктами наименьший — большинство open-source дашбордов вполне приличные.

Механизм пользовательских доменов. Выпуск TLS-сертификатов, проверка DNS, обновление сертификатов, динамическая выдача сертификатов при добавлении нового домена в кластер. Именно здесь операционные расходы возрастают; работа с ACME в масштабе — действительно сложная задача.

Setup с self-hosting означает, что вы обслуживаете все четыре уровня. Hosted-продукт означает, что вы не обслуживаете ни одного из них (в обмен на оплату поставщику и принятие их условий хранения данных). Вопрос в том, какой набор компромиссов лучше подходит для вашей ситуации.

Текущие open-source решения#

Пять проектов, заслуживающих внимания, в примерном порядке активности на 22 мая 2026 года.

YOURLS#

Старичок. PHP, MySQL, односерверная архитектура, плагины. YOURLS существует с 2009 года и остается самым распространенным open-source сокращателем с огромным отрывом. Сильные стороны: простая установка, работает везде, где есть PHP, зрелая экосистема плагинов. Слабые стороны: минимальная аналитика (количество кликов по ссылке, геолокация IP через внешний сервис), отсутствие встроенной поддержки пользовательских доменов (кроме запуска нескольких экземпляров), нет ограничения скорости API, нет понятия команд или ролей.

YOURLS — отличный выбор, если вам нужен персональный инструмент для коротких ссылок с одним владельцем и умеренным трафиком. Это неправильный выбор, если у вас есть команда, пользовательские домены для клиентов или аналитика, которая должна пережить базу данных. В статье Elido против YOURLS подробно рассматривается функциональный разрыв.

Shlink#

Снова PHP, но более современный. Shlink поставляется с REST API, поддержкой нескольких доменов, отдельным веб-интерфейсом и обновлениями в реальном времени на основе Mercure. Аналитика более функциональна, чем у YOURLS — геолокация по посещению, устройство, временные ряды — но данные хранятся в той же базе данных MySQL/Postgres, что и ссылки. Команда Shlink отзывчива, и проект выпускает обновления с 2019 года.

Shlink — разумный выбор, если вы готовы обслуживать связку PHP-FPM + MySQL/Postgres и вам не нужно, чтобы аналитика масштабировалась более чем до нескольких миллионов кликов в месяц. Однопроцессный уровень перенаправлений становится узким местом при больших объемах; горизонтальное масштабирование возможно, но требует установки балансировщика нагрузки и общего кэша.

Polr#

Легковесный PHP. Polr был популярен примерно в 2017–2019 годах, сейчас проект практически заброшен, хотя существуют форки. Функционально похож на YOURLS, но с более чистым API. Если вы начинаете сегодня, отсутствие активной поддержки — серьезный повод для беспокойства: патчи безопасности не выходят по расписанию.

Kutt#

Node.js, Postgres, Redis. Kutt — самый активный сокращатель на «современном стеке». Поставляется с функцией пользовательских доменов, защитой ссылок паролем, сроком действия и базовой аналитикой. Аналитика более пригодна для использования, чем у YOURLS, но все еще опирается на реляционную базу данных.

Операционный профиль Kutt тяжелее, чем у YOURLS — Node + Postgres + Redis означают три сервиса для запуска вместо одного — но современный стек дает лучшую производительность на вложенный доллар при умеренных объемах. Если ваша команда комфортно работает с Node, Kutt на сегодня — самый безопасный выбор, если вы хотите «современный open-source сокращатель».

Dub-self-hosted#

Dub.co публикует self-hosted версию своего hosted-продукта. Dub поставляется в составе стека Next.js + Postgres + Redis + Tinybird с отполированным дашбордом и приличной аналитикой. Операционная сложность — самая высокая из пяти: Tinybird — это hosted-сервис ClickHouse, используемый по умолчанию, и его замена на self-hosted ClickHouse — серьезный проект.

Dub-self-hosted — правильный выбор, если у вашей команды есть опыт работы с современным веб-стеком и вы хотите внешний вид современного hosted-продукта. Это неправильный выбор, если ваш операционный бюджет ограничен или ваша команда не владеет Next.js.

Матрица поставщиков#

Оценка по четырем осям: аналитика, операции, пользовательские домены и запас масштабируемости. Оценки грубые — от A до D — основаны на том, что проект предоставляет «из коробки», а не на том, чего можно добиться с помощью кастомных доработок.

Проект	Аналитика	Операции	Пользовательские домены	Масштабирование	Стек
YOURLS	D	A	C (вручную)	D	PHP + MySQL
Shlink	C	B	B	C	PHP + Postgres
Polr	D	B	C	D	PHP + MySQL
Kutt	C	C	B	C	Node + Postgres + Redis
Dub-self-hosted	B	D	A	B	Next.js + Postgres + Redis + Tinybird
Elido-self-hosted	A	C	A	A	Go + Postgres + Redis + ClickHouse + Redpanda

Два паттерна из матрицы. Во-первых, аналитика улучшается с усложнением стека: проекты, которые хранят клики в реляционной базе данных рядом со ссылками, получают более низкие оценки, чем проекты, предоставляющие специализированный конвейер аналитики. Во-вторых, пользовательские домены хорошо поддерживаются всеми, кроме YOURLS, так как автоматизация ACME стала товаром.

Скрытые расходы: аналитика, которая масштабируется#

События кликов накапливаются быстрее, чем ожидают люди. Одна ссылка со 100 кликами в день генерирует 36 500 кликов в год — это легко обрабатывается любой реляционной базой данных. Одна ссылка со 100 000 кликов в день генерирует 36,5 млн кликов в год, и вот здесь MySQL или Postgres начинают «стонать». Небольшой SaaS-продукт с тысячей активных ссылок, в среднем получающих 1000 кликов в день каждая, — это миллиард кликов в год, и в этот момент любое реляционное хранилище «ложится» без серьезной настройки.

Пять open-source проектов выше (кроме Dub и Elido) хранят клики в той же базе данных, что и ссылки. Паттерны запросов также отличаются от типичных OLTP — «дай мне количество кликов по дням для этой ссылки за последние 30 дней» — это сканирование диапазона с агрегацией, худший случай для базы данных, настроенной под OLTP.

Вы можете решить эту задачу. ClickHouse комфортно справляется с миллиардными нагрузками аналитики событий; статья почему ClickHouse для аналитики кликов объясняет причины. Но добавление ClickHouse в ваш стек означает еще один сервис для обслуживания, еще один конвейер бэкапов, еще одну поверхность для мониторинга. Если ваш объем ссылок невелик (менее 10 млн кликов в месяц), подход с реляционной базой данных будет работать годами; если объем больше, уровень аналитики становится отдельным проектом.

Скрытые расходы: edge POPs и задержки#

Односерверный self-hosted сокращатель обслуживает перенаправления из одного географического расположения. Если ваши пользователи находятся на трех континентах, задержка для пользователей на другой стороне составит 200–300 мс — это заметно с точки зрения пользовательского опыта.

Решения:

• Anycast IP перед несколькими POP. Практично, только если у вас есть собственная AS и настроен BGP. Нереально для большинства self-hosted развертываний.
• Геомаршрутизация на основе DNS. Cloudflare, Route53 или NS1 могут направлять пользователей к ближайшему POP. Работает, но добавляет задержку DNS-запроса поверх перенаправления.
• CDN спереди. Cloudflare или Fastly перед процессом перенаправления. CDN кэширует GET-ответы; перенаправления можно кэшировать, но логика инвалидации кэша при изменении целевой ссылки нетривиальна.
• Один POP на регион. Запуск процесса перенаправления во Франкфурте, Ашберне и Сингапуре с общей базой данных или итоговой согласованностью между ними. Это путь для продакшена. Это также значительно больше работы, чем self-hosting в одном регионе.

В статье Edge POPs против DNS-маршрутизации подробно рассматривается этот выбор. Большинство self-hosted развертываний останавливаются на одном регионе, потому что работа с несколькими регионами — это отдельный проект.

Когда self-hosting имеет смысл#

Три сценария:

Суверенитет данных не подлежит обсуждению. Регулируемая отрасль — здравоохранение, финансы, госсектор — требует, чтобы данные находились на вашей инфраструктуре. Политика hosted-продукта (даже если он размещен в ЕС) недостаточна, потому что данные должны находиться внутри вашего контура безопасности. Self-hosting здесь — правильный ответ. Стоимость обслуживания — это цена соответствия требованиям.

Объем кликов невелик, и вы технический специалист. Команда запускает собственные короткие ссылки для внутреннего использования, с менее чем миллионом кликов в месяц, без пользовательских доменов для внешних клиентов и с разработчиком, который может поддерживать работоспособность одного Docker Compose стека. YOURLS или Shlink отлично подходят. Hosted-продукт для такого объема — избыточное решение.

Вы создаете производный продукт. Если ваши короткие ссылки — это фронтенд более крупного продукта, который вы создаете (например, платформа продажи билетов, где короткий URL ведет на билет), self-hosting позволяет связать уровень перенаправлений с вашей бизнес-логикой так, как hosted-поставщик не может. Большинство пользователей Dub-self-hosted относятся к этой категории.

Когда self-hosting перестает иметь смысл#

Три сценария с другой стороны:

Вам нужна достойная аналитика. Как только ваши стейкхолдеры спрашивают: «Как распределяются клики по странам за последние 90 дней для этих 50 кампаний?», хранение в реляционной базе данных перестает справляться. Вы либо строите конвейер аналитики (проект на несколько месяцев), либо платите hosted-поставщику, который предоставляет это «из коробки».

Вам нужны пользовательские домены для многих клиентов. Запуск ACME для одного домена тривиален. Запуск ACME для 10 000 доменов, предоставленных клиентами, с отзывом, продлением и динамической выдачей — это серьезная инженерная задача. Статья TLS для пользовательских доменов за 5 минут описывает механизм; создание такого решения внутри — это квартал работы, а не один день.

Время вашей команды — узкое место. Self-hosted сокращатель стоит примерно 4–8 инженерных часов в месяц в установившемся режиме после настройки, плюс время на каждый инцидент и каждое обновление. При почасовой ставке разработчика $100 это $400–800 в месяц без учета неизбежных двухнедельных сессий отладки сбоев каждый квартал. Hosted-поставщик за $300–500 в месяц начинает выглядеть дешево.

Расчет безубыточности чувствителен к двум вводным: сколько стоит время вашей команды и как часто вы сталкиваетесь с операционными проблемами. Для команды, которая и так запускает собственный кластер k3s, маржинальная стоимость добавления сокращателя невелика. Для команды, которая в настоящее время не обслуживает никакую инфраструктуру, размещение сокращателя влечет за собой сопутствующие расходы (мониторинг, логирование, бэкапы), которые увеличивают счет.

Прагматичное дерево решений#

Решение в пяти вопросах:

1. Обязаны ли вы по закону или политике хранить данные ссылок на инфраструктуре, которую вы контролируете? Если да, используйте self-hosting. На этом остановитесь.
2. Превышает ли (или ожидается, что превысит в течение 24 месяцев) ваш объем кликов 50 млн в месяц? Если да, планируйте выделенный уровень аналитики — это склоняет выбор либо в сторону Dub-self-hosted, либо Elido-self-hosted, либо hosted-поставщика с аналитикой на основе ClickHouse.
3. Нужны ли вам пользовательские домены более чем для 10 клиентов? Если да, стоимость автоматизации ACME значительна — те же проекты, что выше, или hosted-решение.
4. Обслуживает ли ваша команда другие продакшн-сервисы с дежурствами? Если нет, операционные расходы на self-hosting выше, чем кажутся.
5. Являются ли короткие ссылки стратегической поверхностью вашего продукта (например, вы создаете интеграционную платформу) или вспомогательной утилитой (например, внутренние ссылки команды)? Стратегическая поверхность = self-hosting или hosted с глубокой интеграцией; вспомогательная утилита = то, что дешевле.

Большинство команд после прохождения этого дерева придут к hosted-решению. И это нормально. Self-hosting — правильный ответ, когда ограничения ясны; это неправильный выбор по умолчанию, когда они таковыми не являются.

Дополнительные материалы#

• Альтернативы Bitly — реальный функциональный разрыв — более широкий обзор hosted-поставщиков.
• Self-hosting Elido в k3s — руководство — операционное прохождение для стороны Elido.
• Elido против YOURLS — прямое сравнение с самым распространенным open-source решением.
• Почему ClickHouse для аналитики кликов — обоснование уровня аналитики.
• Edge POPs против DNS-маршрутизации — путь к работе с несколькими регионами.
• Продукт: /solutions/developers и /pricing.
• Архитектура: документация edge-redirect.