Samodzielnie hostowane skracacze URL: krajobraz open-source

Samodzielne hostowanie skracacza URL było kiedyś projektem na weekend. PHP plus MySQL plus kontroler przekierowań i miałeś coś przypominającego Bitly z okolic 2010 roku. Kategoria ta nie stała w miejscu; nowoczesne opcje open-source są bardziej zdolne niż YOURLS, trudniejsze w obsłudze niż projekt na weekend i wciąż znacząco w tyle za hostowanym produktem pod względem powierzchni analitycznej. Ten wpis to szczery krajobraz — co tak naprawdę dostarcza każda z opcji open-source, z czego rezygnujesz w porównaniu z hostowanym dostawcą i gdzie matematyka przechyla się na korzyść płacenia komuś innemu za obsługę warstwy przekierowań.

Docelową grupą odbiorców są zespoły inżynierskie lub operatorzy techniczni rozważający samodzielne hostowanie. Artykuł bitly alternatives cornerstone obejmuje szersze porównanie; ten wpis skupia się konkretnie na stronie open-source. Elido k3s playbook opisuje przypadek, w którym chcesz samodzielnie hostować samego Elido, zamiast alternatywy strony trzeciej.

Na co się piszesz#

Skracacz URL wygląda niepozornie. Baza danych, proces przekierowań, pulpit nawigacyjny do zarządzania linkami. W środowisku produkcyjnym ten prosty kształt skrywa cztery powierzchnie operacyjne:

Warstwa przekierowań. To gorąca ścieżka (hot path). Każdy skrócony URL kliknięty gdziekolwiek w internecie ostatecznie trafia do tego kodu. Musi być szybki (p95 poniżej 15 ms, jeśli zależy Ci na doświadczeniu użytkownika), wysoce dostępny (przestój tutaj psuje każdy link, który kiedykolwiek wysłałeś) i rozproszony globalnie, jeśli Twoi użytkownicy nie znajdują się w jednej lokalizacji. Post redirect p95 < 15ms opisuje, co faktycznie oznacza szybkość i jak ją osiągnąć.

Potok analityki kliknięć. Rejestrowanie, przechowywanie i odpytywanie zdarzeń kliknięć. Przy dużej skali to inny system niż warstwa przekierowań — zazwyczaj Kafka lub Redpanda do inżestii, ClickHouse lub BigQuery do przechowywania, oddzielne API do zapytań. Większość skracaczy open-source pomija to całkowicie i przechowuje kliknięcia w tej samej relacyjnej bazie danych, która przechowuje linki, co działa przy małej skali, ale pada, gdy przekroczysz kilka milionów kliknięć miesięcznie.

Pulpit nawigacyjny (dashboard). UI do tworzenia, edycji, organizowania i analizowania linków. To tutaj większość projektów open-source wkłada większość pracy nad funkcjami i tutaj luka w stosunku do produktów hostowanych jest najmniejsza — większość dashboardów open-source jest przyzwoita.

Mechanizm własnych domen. Wydawanie certyfikatów TLS, walidacja DNS, odnawianie certyfikatów, obsługa certyfikatów na żądanie, gdy nowa domena wskazuje na klaster. To tutaj koszt operacyjny rośnie; uruchamianie ACME na dużą skalę jest naprawdę trudne.

Samodzielna konfiguracja oznacza, że obsługujesz wszystkie cztery powierzchnie. Produkt hostowany oznacza, że nie obsługujesz żadnej z nich (w zamian za płacenie dostawcy i akceptację jego polityki przechowywania danych). Pytanie brzmi, który zestaw kompromisów lepiej pasuje do Twojej sytuacji.

Obecne opcje open-source#

Pięć projektów wartych rozważenia, w przybliżonej kolejności aktywności na dzień 2026-05-22.

YOURLS#

Dziadek całego nurtu. PHP, MySQL, serwer typu single-server, architektura wtyczek. YOURLS istnieje od 2009 roku i pozostaje najczęściej wdrażanym skracaczem open-source z dużą przewagą. Zalety: łatwy w instalacji, działa wszędzie tam, gdzie działa PHP, ekosystem wtyczek jest dojrzały. Wady: analityka jest minimalna (liczba kliknięć na link, geo IP za pośrednictwem zewnętrznej usługi), brak wbudowanej obsługi własnych domen poza uruchamianiem wielu instancji, brak ograniczania szybkości API (rate limiting), brak koncepcji zespołów lub ról.

YOURLS to dobry wybór, jeśli chcesz narzędzia do osobistych krótkich linków z jednym właścicielem i umiarkowanym ruchem. To zły wybór, jeśli masz zespół, własne domeny dla klientów lub analitykę, która musi przetrwać dłużej niż baza danych. Post Elido vs YOURLS szczegółowo opisuje lukę funkcjonalną.

Shlink#

Znów PHP, ale bardziej nowoczesne. Shlink dostarczany jest z API REST, obsługą wielu domen, oddzielnym web UI i aktualizacjami w czasie rzeczywistym opartymi na Mercure. Analityka jest bardziej zaawansowana niż w YOURLS — geo na wizytę, urządzenie, szeregi czasowe — ale przechowywana w tej samej bazie danych MySQL/Postgres co linki. Zespół Shlink jest responsywny, a projekt wydaje spójne wersje od 2019 roku.

Shlink to rozsądny wybór, jeśli chcesz obsługiwać konfigurację PHP-FPM + MySQL/Postgres i nie potrzebujesz, aby analityka skalowała się powyżej kilku milionów kliknięć miesięcznie. Jednoprocesowa warstwa przekierowań staje się wąskim gardłem przy wyższych wolumenach; skalowanie poziome jest możliwe, ale wymaga postawienia przed nim load balancera i współdzielonej pamięci podręcznej (cache).

Polr#

Lekkie PHP. Polr był popularny w okolicach 2017-2019 roku, a projekt jest obecnie w dużej mierze uśpiony, choć istnieją fork-i. Funkcjonalnie podobny do YOURLS, ale z czystszym API. Jeśli zaczynasz dzisiaj, brak bieżącej konserwacji jest istotnym powodem do niepokoju — poprawki bezpieczeństwa nie pojawiają się regularnie.

Kutt#

Node.js, Postgres, Redis. Kutt to najaktywniejszy skracacz z "nowoczesnego stacku". Dostarczany z funkcją własnych domen, linkami chronionymi hasłem, wygasaniem i podstawową analityką. Powierzchnia analityczna jest bardziej użyteczna niż w YOURLS, ale nadal oparta na relacyjnej bazie danych.

Profil operacyjny Kutt jest cięższy niż YOURLS — Node + Postgres + Redis oznacza trzy usługi do uruchomienia, a nie jedną — ale nowoczesny stack zapewnia lepszą wydajność za dolara przy umiarkowanych wolumenach. Jeśli Twój zespół czuje się komfortowo z Node, Kutt jest dzisiaj najbezpieczniejszym wyborem typu "chcemy nowoczesny skracacz open-source".

Dub-self-hosted#

Dub.co publikuje wersję self-host swojego hostowanego produktu. Dub dostarcza stack Next.js + Postgres + Redis + Tinybird z dopracowanym pulpitem nawigacyjnym i przyzwoitą analityką. Złożoność operacyjna jest najwyższa z tej piątki — Tinybird to hostowana usługa ClickHouse w domyślnym wdrożeniu, a zastąpienie jej samodzielnie hostowanym ClickHouse jest znaczącym projektem.

Dub-self-hosted to właściwy wybór, jeśli masz zespół, który czuje się komfortowo obsługując nowoczesny stack internetowy i chce wyglądu i działania obecnego produktu hostowanego. To zły wybór, jeśli Twój budżet operacyjny jest ograniczony lub Twój zespół nie jest biegły w Next.js.

Macierz dostawców#

Czteroosiowa ocena obejmująca analitykę, operacje, własne domeny i potencjał skalowania. Oceny są zgrubne — od A do D — w oparciu o to, co projekt dostarcza "z pudełka", a nie co jest możliwe do osiągnięcia dzięki własnej pracy.

Projekt	Analityka	Operacje	Własne domeny	Skalowanie	Stack
YOURLS	D	A	C (ręcznie)	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

Dwa wzorce z macierzy. Po pierwsze, analityka poprawia się wraz ze złożonością stacku — projekty, które przechowują kliknięcia w relacyjnej bazie danych obok linków, oceniają się niżej niż projekty, które dostarczają dedykowany potok analityczny. Po drugie, własne domeny są całkiem dobrze obsługiwane przez wszystko poza YOURLS, ponieważ automatyzacja ACME stała się powszechna.

Ukryty koszt: analityka, która się skaluje#

Zdarzenia kliknięć gromadzą się szybciej, niż ludzie się spodziewają. Pojedynczy link ze 100 kliknięciami dziennie generuje 36 500 kliknięć rocznie — co jest wykonalne w każdej relacyjnej bazie danych. Pojedynczy link ze 100 000 kliknięć dziennie generuje 36,5 mln kliknięć rocznie i to jest moment, w którym MySQL lub Postgres zaczynają jęczeć. Mały produkt SaaS z tysiącem aktywnych linków średnio po 1 000 kliknięć dziennie każdy to miliard kliknięć rocznie, a w tym punkcie każda relacyjna baza danych pada bez znaczącej optymalizacji.

Pięć powyższych projektów open-source (z wyjątkiem Dub i Elido) przechowuje kliknięcia w tej samej bazie danych co linki. Wzorce zapytań również różnią się od typowych OLTP — "podaj mi liczbę kliknięć dziennie dla tego linku z ostatnich 30 dni" to skanowanie zakresu z agregacją, czyli najgorszy przypadek dla bazy danych dostrojonej pod OLTP.

Możesz to rozwiązać. ClickHouse radzi sobie z analitycznymi obciążeniami rzędu miliarda zdarzeń bez problemu; post dlaczego ClickHouse wyjaśnia powody. Ale dodanie ClickHouse do swojego stacku oznacza kolejną usługę do obsługi, kolejny potok kopii zapasowych, kolejną powierzchnię monitorowania. Jeśli Twój wolumen linków jest mały (poniżej 10 mln kliknięć miesięcznie), podejście oparte na relacyjnej bazie danych będzie działać latami; jeśli wolumen jest większy, warstwa analityczna staje się projektem samym w sobie.

Ukryty koszt: punkty brzegowe (Edge POPs) i opóźnienia#

Samodzielnie hostowany skracacz działający na jednym serwerze obsługuje przekierowania z jednej lokalizacji geograficznej. Jeśli Twoi użytkownicy są na trzech kontynentach, opóźnienie z odległej strony wynosi 200-300 ms — co jest widoczne w kategoriach doświadczenia użytkownika.

Rozwiązania:

Anycast IP przed wieloma punktami POP. Praktyczne tylko wtedy, gdy masz własny AS i konfigurację BGP. Nierealistyczne dla większości wdrożeń self-hosted.
Routing geograficzny oparty na DNS. Cloudflare, Route53 lub NS1 mogą kierować użytkowników do najbliższego POP. Działa, ale dodaje opóźnienie wyszukiwania DNS na szczycie przekierowania.
CDN z przodu. Cloudflare lub Fastly przed procesem przekierowania. CDN buforuje odpowiedzi GET; przekierowania można buforować, ale logika unieważniania pamięci podręcznej (cache invalidation), gdy zmienia się miejsce docelowe linku, nie jest trywialna.
Jeden POP na region. Uruchom proces przekierowania we Frankfurcie, Ashburn i Singapurze, ze współdzieloną bazą danych lub spójnością ostateczną (eventual consistency) między nimi. To jest ścieżka produkcyjna. Jest to również znacznie więcej pracy niż samodzielne hostowanie w jednym regionie.

Post edge POPs vs DNS-only routing szczegółowo omawia ten wybór. Większość wdrożeń self-hosted kończy się na jednym regionie, ponieważ praca wieloregionalna to oddzielny projekt.

Kiedy samodzielne hostowanie ma sens#

Trzy scenariusze:

Suwerenność danych nie podlega negocjacjom. Regulowana branża — zdrowie, finanse, rząd — wymaga, aby dane znajdowały się na Twojej infrastrukturze. Postawa hostowanego produktu (nawet tego z rezydencją w UE) nie jest wystarczająca, ponieważ dane muszą znajdować się wewnątrz Twojej granicy bezpieczeństwa. Samodzielne hostowanie jest tutaj poprawną odpowiedzią. Koszt utrzymania jest ceną za zgodność (compliance).

Wolumen jest mały, a Ty jesteś techniczny. Zespół obsługujący własne krótkie linki do użytku wewnętrznego, z poniżej milionem kliknięć miesięcznie, bez własnych domen dla klientów zewnętrznych i z programistą, który potrafi utrzymać przy życiu jeden stack Docker Compose. YOURLS lub Shlink pasuje idealnie. Produkt hostowany to w tym zakresie przesada.

Budujesz produkt pochodny. Jeśli Twoje krótkie linki są front-endem większego produktu, który budujesz — powiedzmy, platformy sprzedaży biletów na wydarzenia, gdzie krótki URL prowadzi do biletu — samodzielne hostowanie pozwala połączyć warstwę przekierowań z logiką biznesową w sposób, którego hostowany dostawca nie jest w stanie dopasować. Większość użytkowników Dub-self-hosted znajduje się w tej kategorii.

Kiedy samodzielne hostowanie przestaje mieć sens#

Trzy scenariusze po drugiej stronie:

Potrzebujesz przyzwoitej analityki. Gdy Twoi interesariusze zapytają: "jak rozkładają się kliknięcia według kraju w ciągu ostatnich 90 dni dla tych 50 kampanii?", przechowywanie w relacyjnej bazie danych zawodzi. Albo budujesz potok analityczny (wielomiesięczny projekt), albo płacisz hostowanemu dostawcy, który dostarcza go z pudełka.

Potrzebujesz własnych domen dla wielu klientów. Uruchomienie ACME dla jednej domeny jest trywialne. Uruchomienie ACME dla 10 000 domen dostarczonych przez klientów, z odwoływaniem, odnawianiem i wystawianiem na żądanie, to poważna powierzchnia inżynieryjna. Post custom domain TLS opisuje mechanizm; budowanie tego wewnętrznie to kwartał pracy, a nie popołudnie.

Czas Twojego zespołu jest wąskim gardłem. Samodzielnie hostowany skracacz kosztuje około 4-8 roboczogodzin inżyniera miesięcznie w stanie ustalonym, po jego skonfigurowaniu, plus czas każdego przestoju i każdej aktualizacji. Przy stawce godzinowej programisty wynoszącej 100 USD, jest to 400-800 USD/miesiąc przed uwzględnieniem nieuniknionej dwutygodniowej sesji debugowania przestojów co kwartał. Hostowany dostawca za 300-500 USD/miesiąc zaczyna wyglądać tanio.

Obliczenie progu rentowności jest wrażliwe na dwa czynniki: ile wart jest czas Twojego zespołu i jak często napotykasz problemy operacyjne. Dla zespołu, który i tak obsługuje własny klaster k3s, koszt krańcowy dodania skracacza jest niski. Dla zespołu, który obecnie nie obsługuje żadnych usług produkcyjnych, hostowanie skracacza pociąga za sobą koszty przyległe (monitorowanie, logowanie, kopie zapasowe), które zwiększają rachunek.

Pragmatyczne drzewo decyzyjne#

Decyzja w pięciu pytaniach:

Czy jesteś zobowiązany przepisami lub polityką do przechowywania danych linków na infrastrukturze, którą kontrolujesz? Jeśli tak, hostuj samodzielnie. Tutaj zakończ.
Czy Twój wolumen kliknięć wynosi obecnie lub ma przekroczyć 50 mln kliknięć miesięcznie w ciągu 24 miesięcy? Jeśli tak, zaplanuj dedykowaną warstwę analityczną — co skłania do wyboru Dub-self-hosted lub Elido-self-hosted, lub hostowanego dostawcy z analityką opartą na ClickHouse.
Czy potrzebujesz własnych domen dla więcej niż 10 klientów? Jeśli tak, koszt automatyzacji ACME jest znaczący — te same projekty co powyżej lub produkt hostowany.
Czy Twój zespół obsługuje obecnie inne usługi produkcyjne z rotacją on-call? Jeśli nie, koszt operacyjny samodzielnego hostowania jest wyższy, niż się wydaje.
Czy krótkie linki są strategiczną powierzchnią Twojego produktu (np. budujesz platformę integracyjną), czy wspierającym narzędziem (np. linki wewnętrzne dla zespołu)? Powierzchnia strategiczna = samodzielny host lub hostowany z głęboką integracją; wspierające narzędzie = to, co jest tańsze.

Większość zespołów po przeprowadzeniu tego drzewa zdecyduje się na rozwiązanie hostowane. To w porządku. Samodzielne hostowanie jest właściwą odpowiedzią, gdy ograniczenia są jasne; jest złym wyborem domyślnym, gdy takie nie są.

Powiązane artykuły#

Bitly alternatives — the actual feature gap — szerszy artykuł na temat hostowanych dostawców.
Self-hosting Elido on k3s — the playbook — przewodnik operacyjny po stronie Elido.
Elido vs YOURLS — bezpośrednie porównanie z najczęściej wdrażaną opcją open-source.
Why ClickHouse for click analytics — rozumowanie stojące za warstwą analityczną.
Edge POPs vs DNS-only routing — ścieżka wieloregionalna.
Powierzchnia produktu: /solutions/developers oraz /pricing.
Architektura: edge-redirect docs.