Das Self-Hosting eines URL-Shorteners war früher ein Wochenendprojekt. PHP plus MySQL plus ein Redirect-Controller, und schon hatte man etwas, das Bitly um 2010 ähnelte. Die Kategorie ist nicht stehen geblieben; die modernen Open-Source-Optionen sind leistungsfähiger als YOURLS, anspruchsvoller im Betrieb als das Wochenendprojekt und liegen bei der Analytics-Oberfläche immer noch deutlich hinter einem gehosteten Produkt zurück. Dieser Post zeigt die ehrliche Landschaft – was jede Open-Source-Option tatsächlich bietet, was man gegenüber einem gehosteten Anbieter aufgibt und wann sich die Rechnung wieder zugunsten eines bezahlten Dienstes für die Weiterleitungsebene wendet.
Die Zielgruppe sind Engineering-Teams oder technische Betreiber, die abwägen, ob sie selbst hosten sollen. Der Bitly-Alternativen Cornerstone deckt den breiteren Vergleich ab; dieser Post konzentriert sich speziell auf die Open-Source-Seite. Der Self-Hosting Elido k3s Playbook behandelt den Fall, in dem Sie Elido selbst hosten möchten, anstatt eine Alternative eines Drittanbieters zu nutzen.
Worauf Sie sich einlassen#
Ein URL-Shortener sieht täuschend klein aus. Eine Datenbank, ein Weiterleitungsprozess, ein Dashboard zur Verwaltung von Links. In der Produktion verbirgt die einfache Form jedoch vier betriebliche Bereiche:
Die Weiterleitungsebene (Redirect-Tier). Dies ist der Hot Path. Jede Kurz-URL, die irgendwo im Internet angeklickt wird, landet schließlich bei diesem Code. Er muss schnell sein (sub-15ms p95, wenn Ihnen die Benutzererfahrung wichtig ist), hochverfügbar (ein Ausfall hier macht jeden Link kaputt, den Sie jemals verschickt haben) und global verteilt, wenn Ihre Benutzer nicht alle in einer Region sitzen. Der Redirect p95 < 15ms Post erklärt, was „schnell“ eigentlich bedeutet und wie es erreicht wird.
Die Click-Analytics-Pipeline. Das Aufzeichnen, Speichern und Abfragen von Click-Events. Bei hohem Volumen ist dies ein anderes System als die Weiterleitungsebene – typischerweise Kafka oder Redpanda für die Aufnahme, ClickHouse oder BigQuery für die Speicherung und eine separate API für Abfragen. Die meisten Open-Source-Shortener überspringen dies ganz und speichern Clicks in derselben relationalen Datenbank, die auch die Links enthält. Das funktioniert bei geringem Volumen, bricht aber zusammen, sobald Sie die Marke von einigen Millionen Clicks pro Monat überschreiten.
Das Dashboard. UI zum Erstellen, Bearbeiten, Organisieren und Analysieren von Links. Hier investieren die meisten Open-Source-Projekte den Großteil ihrer Feature-Arbeit, und hier ist der Abstand zu gehosteten Produkten am geringsten – die meisten Open-Source-Dashboards sind ordentlich.
Die Custom-Domain-Maschinerie. TLS-Ausstellung, DNS-Validierung, Zertifikatserneuerung, On-Demand-Zertifikatsbereitstellung, wenn eine neue Domain auf den Cluster zeigt. Hier summieren sich die Betriebskosten; ACME in großem Maßstab zu betreiben, ist wirklich schwer.
Ein Self-hosted-Setup bedeutet, dass Sie alle vier Bereiche selbst betreiben. Bei einem gehosteten Produkt betreiben Sie keinen davon (im Austausch gegen die Zahlung an einen Anbieter und die Akzeptanz seiner Data-Residency-Strategie). Die Frage ist, welche Kompromisse für Ihre Situation besser passen.
Die aktuellen Open-Source-Optionen#
Fünf Projekte, die eine Überlegung wert sind, in der ungefähren Reihenfolge ihrer Aktivität zum Stand 22.05.2026.
YOURLS#
Der Urvater. PHP, MySQL, Single-Server, Plugin-Architektur. YOURLS gibt es seit 2009 und es ist nach wie vor der am häufigsten eingesetzte Open-Source-Shortener. Stärken: einfach zu installieren, läuft überall, wo PHP läuft, das Plugin-Ökosystem ist ausgereift. Schwächen: Analytics sind minimal (Click-Zahlen pro Link, Geo-IP über einen externen Dienst), keine integrierte Custom-Domain-Unterstützung außer dem Betrieb mehrerer Instanzen, kein API-Rate-Limiting, kein Konzept für Teams oder Rollen.
YOURLS ist eine gute Wahl, wenn Sie ein persönliches Kurzlink-Tool für einen einzelnen Besitzer und bescheidenen Traffic suchen. Es ist die falsche Wahl, wenn Sie ein Team haben, Custom-Domains für Kunden benötigen oder Analytics brauchen, die länger als die Datenbank leben. Der Elido vs. YOURLS Post deckt die Funktionslücke im Detail ab.
Shlink#
Wieder PHP, aber moderner. Shlink wird mit einer REST API, Multi-Domain-Unterstützung, einer separaten Web-UI und Mercure-basierten Echtzeit-Updates ausgeliefert. Die Analytics sind leistungsfähiger als bei YOURLS – Geo pro Besuch, Gerät, Zeitreihen – werden aber in derselben MySQL/Postgres-Datenbank wie die Links gespeichert. Das Shlink-Team reagiert schnell und das Projekt veröffentlicht seit 2019 konsistente Releases.
Shlink ist eine vernünftige Wahl, wenn Sie bereit sind, ein PHP-FPM + MySQL/Postgres-Setup zu betreiben und Ihre Analytics nicht über einige Millionen Clicks pro Monat hinaus skalieren müssen. Die Single-Process-Weiterleitungsebene wird bei höheren Volumina zum Flaschenhals; horizontales Skalieren ist möglich, erfordert aber einen Load-Balancer und einen gemeinsamen Cache davor.
Polr#
Leichtgewichtiges PHP. Polr war um 2017-2019 beliebt, das Projekt liegt heute weitgehend brach, obwohl Forks existieren. Funktional ähnlich wie YOURLS, aber mit einer saubereren API. Wenn Sie heute neu anfangen, ist der Mangel an aktueller Wartung ein echtes Problem – Sicherheits-Patches erscheinen nicht nach Plan.
Kutt#
Node.js, Postgres, Redis. Kutt ist der aktivste „Modern Stack“ Shortener. Er bietet Custom-Domain-Funktionen, passwortgeschützte Links, Ablaufdaten und Basis-Analytics. Die Analytics-Oberfläche ist brauchbarer als bei YOURLS, basiert aber immer noch auf einer relationalen Datenbank.
Das Betriebsprofil von Kutt ist schwerer als das von YOURLS – Node + Postgres + Redis bedeutet drei Dienste statt einem –, aber der moderne Stack bietet eine bessere Leistung pro Euro bei moderatem Volumen. Wenn Ihr Team mit Node vertraut ist, ist Kutt heute die sicherste Wahl für einen „modernen Open-Source-Shortener“.
Dub-self-hosted#
Dub.co veröffentlicht eine Self-host-Version ihres gehosteten Produkts. Dub nutzt einen Next.js + Postgres + Redis + Tinybird-Stack mit einem polierten Dashboard und ordentlichen Analytics. Die betriebliche Komplexität ist hier am höchsten – Tinybird ist im Standard-Deployment ein gehosteter ClickHouse-Dienst, und diesen durch ein selbst gehostetes ClickHouse zu ersetzen, ist ein bedeutendes Projekt.
Dub-self-hosted ist die richtige Wahl, wenn Sie ein Team haben, das mit einem modernen Web-Stack vertraut ist und das Look-and-Feel eines aktuellen gehosteten Produkts wünscht. Es ist die falsche Wahl, wenn Ihr Budget für den Betrieb begrenzt ist oder Ihr Team nicht Next.js-versiert ist.
Die Anbieter-Matrix#
Eine Bewertung auf vier Achsen: Analytics, Betrieb, Custom-Domains und Skalierungsspielraum. Die Bewertungen sind grob – von A bis D – basierend darauf, was das Projekt von Haus aus bietet, nicht was mit individueller Anpassung möglich ist.
| Projekt | Analytics | Betrieb | Custom-Domains | Skalierung | Stack |
|---|---|---|---|---|---|
| YOURLS | D | A | C (manuell) | 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 |
Zwei Muster ergeben sich aus der Matrix. Erstens: Die Analytics verbessern sich mit der Komplexität des Stacks – Projekte, die Clicks in einer relationalen Datenbank neben den Links speichern, schneiden schlechter ab als Projekte, die eine dedizierte Analytics-Pipeline mitbringen. Zweitens: Custom-Domains werden von fast allen außer YOURLS gut bedient, da die ACME-Automatisierung zum Standard geworden ist.
Die versteckten Kosten: Analytics, die skalieren#
Click-Events häufen sich schneller an, als man erwartet. Ein einzelner Link mit 100 Clicks pro Tag erzeugt 36.500 Clicks pro Jahr – in jeder relationalen Datenbank handhabbar. Ein einzelner Link mit 100.000 Clicks pro Tag erzeugt 36,5 Mio. Clicks pro Jahr, und hier fangen MySQL oder Postgres an zu ächzen. Ein kleines SaaS-Produkt mit tausend aktiven Links und durchschnittlich 1.000 Clicks pro Tag pro Link bedeutet eine Milliarde Clicks pro Jahr. An diesem Punkt bricht jeder relationale Speicher ohne massives Tuning zusammen.
Die fünf oben genannten Open-Source-Projekte (außer Dub und Elido) speichern Clicks in derselben Datenbank wie die Links. Auch die Abfragemuster unterscheiden sich von typischem OLTP – „Zeige mir die Click-Zahlen pro Tag für diesen Link über die letzten 30 Tage“ ist ein Range-Scan mit Aggregation, der Worst Case für eine auf OLTP optimierte Datenbank.
Man kann das lösen. ClickHouse bewältigt Workloads mit Milliarden von Events mühelos; der Warum ClickHouse für Click-Analytics Post erläutert die Gründe. Aber die Integration von ClickHouse in Ihren Stack bedeutet einen weiteren Dienst, den Sie betreiben müssen, eine weitere Backup-Pipeline, eine weitere Monitoring-Oberfläche. Wenn Ihr Link-Volumen gering ist (unter 10 Mio. Clicks pro Monat), ist der relationale Ansatz über Jahre hinweg völlig in Ordnung. Wenn Ihr Volumen größer ist, wird der Analytics-Tier zu einem eigenständigen Projekt.
Die versteckten Kosten: Edge POPs und Latenz#
Ein Single-Server Self-hosted-Shortener bedient Weiterleitungen von einem einzigen geografischen Standort aus. Wenn Ihre Benutzer über drei Kontinente verteilt sind, beträgt die Latenz von der anderen Seite der Welt 200–300ms – was sich in der Benutzererfahrung deutlich bemerkbar macht.
Die Lösungen:
- Anycast-IPs vor mehreren POPs. Praktisch nur umsetzbar, wenn Sie Ihr eigenes AS- und BGP-Setup haben. Für die meisten Self-hosted-Deployments nicht realistisch.
- DNS-basiertes Geo-Routing. Cloudflare, Route53 oder NS1 können Benutzer zum nächstgelegenen POP leiten. Das funktioniert, fügt aber eine DNS-Lookup-Latenz oben auf die Weiterleitung hinzu.
- CDN davor. Cloudflare oder Fastly vor dem Weiterleitungsprozess. Das CDN cacht GET-Antworten; Weiterleitungen sind cachbar, aber die Cache-Invalidierungslogik bei Zieländerungen ist nicht trivial.
- Ein POP pro Region. Den Weiterleitungsprozess in Frankfurt, Ashburn und Singapur betreiben, mit einer gemeinsamen Datenbank oder Eventual Consistency zwischen ihnen. Das ist der professionelle Weg. Es bedeutet aber auch deutlich mehr Arbeit, als in einer einzigen Region zu hosten.
Der Edge POPs vs. DNS-only Routing Post behandelt diese Wahl im Detail. Die meisten Self-hosted-Deployments bleiben bei einer Region, da der Multi-Region-Aufwand ein separates Projekt darstellt.
Wann Self-Hosting sinnvoll ist#
Drei Szenarien:
Datensouveränität ist nicht verhandelbar. In einer regulierten Branche – Gesundheitswesen, Finanzen, Regierung – müssen die Daten auf Ihrer eigenen Infrastruktur liegen. Das Angebot eines gehosteten Produkts (selbst eines mit Sitz in der EU) reicht nicht aus, da die Daten innerhalb Ihrer Sicherheitsgrenzen bleiben müssen. Hier ist Self-Hosting die richtige Antwort. Die Wartungskosten sind der Preis für Compliance.
Das Volumen ist gering und Sie sind technisch versiert. Ein Team, das seine eigenen Kurzlinks für den internen Gebrauch betreibt, mit weniger als einer Million Clicks pro Monat, ohne Custom-Domains für externe Kunden und mit einem Entwickler, der einen Docker Compose-Stack am Laufen halten kann. YOURLS oder Shlink passen hier perfekt. Ein gehostetes Produkt wäre hierfür überdimensioniert.
Sie bauen ein derivatives Produkt. Wenn Ihre Kurzlinks das Frontend eines größeren Produkts sind, das Sie entwickeln – zum Beispiel eine Event-Ticketing-Plattform, bei der die Kurz-URL zum Ticket führt –, ermöglicht Ihnen Self-Hosting, die Weiterleitungsebene so eng mit Ihrer Geschäftslogik zu verknüpfen, wie es ein gehosteter Anbieter nicht könnte. Die meisten Nutzer von Dub-self-hosted fallen in diese Kategorie.
Wann Self-Hosting nicht mehr sinnvoll ist#
Drei Szenarien auf der anderen Seite:
Sie benötigen ordentliche Analytics. Sobald Ihre Stakeholder fragen: „Wie verteilen sich die Clicks der letzten 90 Tage für diese 50 Kampagnen nach Ländern?“, stößt die relationale Speicherung an ihre Grenzen. Entweder bauen Sie die Analytics-Pipeline selbst (ein mehrmonatiges Projekt) oder Sie bezahlen einen Anbieter, der sie standardmäßig mitliefert.
Sie benötigen Custom-Domains für viele Kunden. ACME für eine Domain zu betreiben, ist trivial. ACME für 10.000 vom Kunden bereitgestellte Domains mit Widerruf, Erneuerung und On-Demand-Ausstellung zu betreiben, ist eine ernsthafte technische Herausforderung. Der Custom-Domain TLS Post behandelt den Mechanismus; dies intern zu bauen, ist eine Aufgabe für ein Quartal, nicht für einen Nachmittag.
Die Zeit Ihres Teams ist der Flaschenhals. Ein selbst gehosteter Shortener kostet im laufenden Betrieb etwa 4–8 Engineering-Stunden pro Monat, plus die Zeit für jeden Ausfall und jedes Upgrade. Bei einem Stundensatz von 100 $ sind das 400–800 $/Monat – noch bevor man die unvermeidliche zweiwöchige Debugging-Session pro Quartal einrechnet. Ein gehosteter Anbieter für 300–500 $/Monat wirkt dagegen plötzlich günstig.
Die Break-Even-Rechnung hängt von zwei Faktoren ab: Wie viel die Zeit Ihres Teams wert ist und wie oft betriebliche Probleme auftreten. Für ein Team, das ohnehin ein k3s-Cluster betreibt, sind die Grenzkosten für einen Shortener gering. Für ein Team, das derzeit keine Infrastruktur betreibt, bringt das Hosting eines Shorteners Folgekosten mit sich (Monitoring, Logging, Backups), die die Rechnung in die Höhe treiben.
Ein pragmatischer Entscheidungsbaum#
Die Entscheidung in fünf Fragen:
- Sind Sie durch Vorschriften oder Richtlinien verpflichtet, Link-Daten auf einer von Ihnen kontrollierten Infrastruktur zu speichern? Wenn ja, hosten Sie selbst. Hier aufhören.
- Erwarten Sie, dass Ihr Click-Volumen innerhalb der nächsten 24 Monate 50 Mio. Clicks pro Monat übersteigt? Wenn ja, planen Sie einen dedizierten Analytics-Tier ein – was für Dub-self-hosted, Elido-self-hosted oder einen Anbieter mit ClickHouse-Analytics spricht.
- Benötigen Sie Custom-Domains für mehr als 10 Kunden? Wenn ja, ist der Aufwand für die ACME-Automatisierung erheblich – nutzen Sie die oben genannten Projekte oder einen gehosteten Dienst.
- Betreibt Ihr Team derzeit andere Produktionsdienste mit Rufbereitschaft? Wenn nein, sind die Betriebskosten für Self-Hosting höher, als es zunächst scheint.
- Sind Kurzlinks ein strategischer Teil Ihres Produkts (z. B. Sie bauen eine Integrationsplattform) oder ein unterstützendes Hilfsmittel (z. B. interne Team-Links)? Strategisch = Self-host oder gehostet mit tiefer Integration; Hilfsmittel = was auch immer günstiger ist.
Die meisten Teams werden nach diesem Baum bei einer gehosteten Lösung landen. Das ist völlig in Ordnung. Self-Hosting ist die richtige Antwort, wenn die Anforderungen klar sind; es ist die falsche Standardeinstellung, wenn sie es nicht sind.
Weiterführende Lektüre#
- Bitly-Alternativen — die tatsächliche Funktionslücke — der breitere Anbieter-Vergleich.
- Self-hosting Elido auf k3s — das Playbook — die Anleitung für die Elido-Seite.
- Elido vs. YOURLS — der direkte Vergleich mit der am häufigsten genutzten Open-Source-Option.
- Warum ClickHouse für Click-Analytics — die Hintergründe zum Analytics-Tier.
- Edge POPs vs. DNS-only Routing — der Weg zur Multi-Region-Lösung.
- Produktbereiche:
/solutions/developersund/pricing. - Architektur: edge-redirect Dokumentation.