Самостійний хостинг URL-скорочувача раніше був проєктом вихідного дня. PHP плюс MySQL плюс контролер перенаправлень, і у вас було щось схоже на Bitly зразка 2010 року. Ця категорія не стояла на місці; сучасні open-source опції функціональніші за YOURLS, потребують більше зусиль для експлуатації, ніж проєкт вихідного дня, і все ще суттєво поступаються SaaS-продуктам у плані аналітики. Цей допис — чесний огляд ситуації: що насправді пропонує кожна open-source опція, чим ви жертвуєте порівняно з SaaS-вендором, і коли розрахунки свідчать на користь того, щоб платити комусь іншому за обслуговування рівня перенаправлень.
Аудиторія — інженерні команди або технічні спеціалісти, які розглядають можливість самостійного хостингу. Cornerstone-стаття про альтернативи Bitly охоплює ширше порівняння; цей допис детально розглядає саме open-source сегмент. Посібник із самостійного хостингу Elido на k3s охоплює випадок, коли ви хочете розгорнути саме Elido, а не сторонню альтернативу.
Що ви отримуєте, підписуючись на це#
URL-скорочувач виглядає оманливо простим. База даних, процес перенаправлення, дашборд для керування посиланнями. У продакшені ця проста форма приховує чотири операційні площини:
Рівень перенаправлень. Це "гарячий" шлях. Кожне коротке посилання, на яке клікають будь-де в інтернеті, врешті-решт потрапляє в цей код. Він має бути швидким (менше 15 мс p95, якщо ви дбаєте про користувацький досвід), високонадійним (простій тут ламає всі посилання, які ви коли-небудь публікували) та глобально розподіленим, якщо ваші користувачі знаходяться не в одній географічній зоні. Стаття про p95 < 15 мс для перенаправлень пояснює, що насправді означає "швидко" і як цього досягти.
Конвеєр аналітики кліків. Запис, зберігання та запити подій кліків. При великих обсягах це інша система, відмінна від рівня перенаправлень — зазвичай Kafka або Redpanda для отримання даних, ClickHouse або BigQuery для зберігання, окремий API для запитів. Більшість open-source скорочувачів взагалі пропускають це і зберігають кліки в тій самій реляційній базі даних, де знаходяться посилання, що працює при малих обсягах і "лягає", як тільки ви перетинаєте позначку в кілька мільйонів кліків на місяць.
Дашборд. Інтерфейс для створення, редагування, організації та аналізу посилань. Це те, на що більшість open-source проєктів витрачає основну частину роботи над функціоналом, і де розрив між ними та SaaS-продуктами найменший — більшість open-source дашбордів цілком пристойні.
Механізм роботи з власними доменами. Випуск TLS, перевірка DNS, оновлення сертифікатів, надання сертифікатів за запитом, коли новий домен вказує на кластер. Саме тут операційні витрати зростають; запуск ACME у великих масштабах — це дійсно складно.
Самостійно розгорнута інсталяція означає, що ви керуєте всіма чотирма площинами. SaaS-продукт означає, що ви не керуєте жодною з них (в обмін на оплату вендору та прийняття їхньої політики щодо зберігання даних). Питання в тому, який набір компромісів краще підходить для вашої ситуації.
Поточні open-source опції#
П'ять проєктів, вартих уваги, у приблизному порядку їхньої активності станом на 2026-05-22.
YOURLS#
Патріарх. PHP, MySQL, односерверна архітектура, плагін-система. YOURLS існує з 2009 року і залишається найбільш розгорнутим open-source скорочувачем з величезним відривом. Переваги: простота встановлення, працює всюди, де є PHP, розвинена екосистема плагінів. Недоліки: мінімальна аналітика (кількість кліків на посилання, Geo IP через зовнішній сервіс), відсутність вбудованої підтримки власних доменів (крім запуску кількох екземплярів), немає обмеження швидкості API (rate limiting), немає концепції команд чи ролей.
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 публікує версію свого SaaS-продукту для самостійного хостингу. Dub поставляється зі стеком Next.js + Postgres + Redis + Tinybird з полірованим дашбордом і пристойною аналітикою. Операційна складність — найвища з п'яти представлених: Tinybird є керованим сервісом ClickHouse за замовчуванням у розгортанні, і його заміна на self-hosted ClickHouse — це значний проєкт.
Dub-self-hosted — правильний вибір, якщо у вас є команда, яка впевнено працює з сучасним веб-стеком і хоче отримати вигляд і функціонал сучасного SaaS-продукту. Це неправильний вибір, якщо ваш операційний бюджет обмежений або ваша команда не володіє стеком 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 кліків на день кожне, — це мільярд кліків на рік, і на цьому рівні будь-яке реляційне сховище "лягає" без серйозного налаштування.
Ви можете вирішити це. ClickHouse легко справляється з аналітичними навантаженнями в мільярди подій; стаття про використання ClickHouse пояснює причини цього. Але додавання ClickHouse до вашого стека означає ще один сервіс для підтримки, ще один конвеєр резервного копіювання, ще одну площину моніторингу. Якщо обсяг ваших посилань невеликий (до 10 млн кліків на місяць), підхід із реляційною базою даних буде працювати роками; якщо обсяг більший, рівень аналітики перетворюється на окремий проєкт.
Приховані витрати: граничні POP-вузли та затримки#
Односерверний self-hosted скорочувач обслуговує перенаправлення з однієї географічної точки. Якщо ваші користувачі знаходяться на трьох континентах, затримка з віддаленої сторони становить 200-300 мс — це помітно для користувацького досвіду.
Рішення:
- Anycast IP перед декількома POP-вузлами. Реально лише за наявності власної AS та налаштування BGP. Не реалістично для більшості self-hosted розгортань.
- DNS-базова гео-маршрутизація. Cloudflare, Route53 або NS1 можуть спрямовувати користувачів до найближчого POP-вузла. Це працює, але додає затримку DNS-запиту поверх перенаправлення.
- CDN перед сервісом. Cloudflare або Fastly перед процесом перенаправлення. CDN кешує GET-відповіді; перенаправлення можна кешувати, але логіка інвалідації кешу при зміні цільового URL є нетривіальною.
- Один POP-вузол на регіон. Запуск процесу перенаправлення у Франкфурті, Ашберні та Сінгапурі зі спільною базою даних або кінцевою узгодженістю між ними. Це шлях до продакшену. Це також значно більше роботи, ніж самостійний хостинг в одному регіоні.
Стаття про вибір між POP-вузлами та лише DNS-маршрутизацією детально розглядає цей вибір. Більшість self-hosted розгортань зупиняються на одному регіоні, тому що мультирегіональна робота — це окремий проєкт.
Коли самостійний хостинг має сенс#
Три сценарії:
Суверенітет даних є обов'язковим. Регульована галузь — охорона здоров'я, фінанси, державний сектор — вимагає, щоб дані зберігалися на вашій інфраструктурі. Позиція SaaS-продукту (навіть якщо вони знаходяться в ЄС) недостатня, оскільки дані мають жити у вашому контурі безпеки. Самостійний хостинг — правильна відповідь у цьому випадку. Витрати на підтримку — це ціна відповідності вимогам.
Обсяг невеликий, і ви технічний спеціаліст. Команда, що використовує власні короткі посилання для внутрішніх цілей, з обсягом менше мільйона кліків на місяць, без власних доменів для зовнішніх клієнтів, і девелопер, який може підтримувати роботу одного стека Docker Compose. YOURLS або Shlink ідеально підходять. SaaS-продукт для такого масштабу є надмірним.
Ви будуєте похідний продукт. Якщо ваші короткі посилання є фронтендом більшого продукту, який ви розробляєте — наприклад, платформа для продажу квитків на заходи, де коротка URL-адреса вказує на квиток — self-hosting дозволяє пов'язати рівень перенаправлень з вашою бізнес-логікою способами, які не може надати SaaS-вендор. Більшість тих, хто використовує Dub-self-hosted, належать до цієї категорії.
Коли самостійний хостинг втрачає сенс#
Три сценарії на протилежному боці:
Вам потрібна пристойна аналітика. Як тільки зацікавлені особи запитують: "як кліки розподіляються за країнами за останні 90 днів для цих 50 кампаній?", реляційна база даних перестає справлятися. Ви або будуєте конвеєр аналітики (проєкт на багато місяців), або платите SaaS-вендору, який надає це "з коробки".
Вам потрібні власні домени для багатьох клієнтів. Запуск ACME для одного домену тривіальний. Запуск ACME для 10 000 доменів, наданих клієнтами, з відкликанням, оновленням і випуском за запитом — це серйозна інженерна задача. Стаття про TLS для власних доменів розкриває механізм; створення цього самотужки — це чверть року роботи, а не пів дня.
Час вашої команди є "вузьким місцем". Self-hosted скорочувач коштує приблизно 4-8 інженерних годин на місяць у стабільному стані після налаштування, плюс час на кожний збій та кожне оновлення. При погодинній ставці розробника в $100 це $400-800 на місяць без урахування неминучої двотижневої сесії налагодження збоїв щоквартально. SaaS-вендор за $300-500 на місяць починає виглядати дешево.
Розрахунок беззбитковості чутливий до двох факторів: скільки коштує час вашої команди і як часто ви стикаєтеся з операційними проблемами. Для команди, яка в будь-якому випадку підтримує власний k3s кластер, гранична вартість додавання скорочувача низька. Для команди, яка наразі не обслуговує жодних продакшен-сервісів, хостинг скорочувача тягне за собою суміжні витрати (моніторинг, логування, бекапи), що збільшує рахунок.
Прагматичне дерево рішень#
Рішення у п'яти запитаннях:
- Чи вимагається регуляціями або політикою компанії зберігати дані посилань на інфраструктурі, яку ви контролюєте? Якщо так, використовуйте self-hosting. На цьому зупиніться.
- Чи перевищує ваш обсяг кліків зараз або чи очікується, що він перевищить 50 млн кліків на місяць протягом 24 місяців? Якщо так, плануйте виділений рівень аналітики — це схиляє вибір на користь Dub-self-hosted, Elido-self-hosted або SaaS-вендора з аналітикою на базі ClickHouse.
- Чи потрібні вам власні домени для більш ніж 10 клієнтів? Якщо так, вартість автоматизації ACME є суттєвою — обирайте ті самі проєкти, що й вище, або SaaS-рішення.
- Чи підтримує ваша команда зараз інші продакшен-сервіси з чергуванням (on-call rotation)? Якщо ні, операційні витрати на self-hosting вищі, ніж здається.
- Чи є короткі посилання стратегічною частиною вашого продукту (наприклад, ви будуєте інтеграційну платформу) чи допоміжною утилітою (наприклад, внутрішні посилання для команди)? Стратегічна частина = self-hosting або SaaS з глибокою інтеграцією; допоміжна утиліта = що дешевше.
Більшість команд після проходження цього дерева зупиняться на SaaS. Це нормально. Self-hosting — правильна відповідь, коли обмеження чіткі; це неправильний вибір за замовчуванням, коли вони не визначені.
Пов'язані матеріали#
- Альтернативи Bitly — фактичний функціональний розрив — ширший cornerstone про SaaS-вендорів.
- Самостійний хостинг Elido на k3s — посібник — операційний покроковий гайд для сторони Elido.
- Elido проти YOURLS — порівняння з найбільш розгорнутим open-source варіантом.
- Чому ClickHouse для аналітики кліків — обґрунтування вибору аналітичного рівня.
- Граничні POP-вузли проти DNS-маршрутизації — мультирегіональний шлях.
- Product surface:
/solutions/developersта/pricing. - Architecture: edge-redirect docs.