Shlink 2026 selbst hosten: Domains, API-Schlüssel und Statistiken

Self-Hosting von Shlink wird beim ersten erneuten Deployment interessant, nicht beim ersten docker run. Wenn generierte Links HTTP verwenden oder Migrationen die Datenbank nicht erreichen, kann Docker weiterhin einen vollkommen gesunden Prozess melden. Das folgende Deployment orientiert sich an beobachtbarem Verhalten: Über die API eine Kurz-URL erstellen, ihre Weiterleitung aufrufen, Besuche erfassen und Statistiken im Web-Client prüfen.

Die vorgesehene Aufgabe von Shlink ist klar definiert: ein API-first-Link-Shortener mit Statistiken. Diese Beschreibung zeigt, was öffentlich erreichbar sein muss, was privat bleiben sollte und welche Komponenten ein Backup wiederherstellen muss.

Wovon Shlink abhängt

Prozessgesundheit und Produktgesundheit sind bei Shlink zwei verschiedene Dinge. Port 8080 kann antworten, während die für Benutzer sichtbare Transaktion weiterhin fehlschlägt. Der Netzwerkvertrag für Shlink umfasst Postgres oder MariaDB sowie optional Redis für den Produktionseinsatz. Halte private Endpoints im internen DNS, erlaube nur erforderliche ausgehende Verbindungen und statte Shlink mit einem eingeschränkten Service-Credential aus.

Verwende diese Readiness-Prüfung nach relevanten Konfigurationsänderungen: Über die API eine Kurz-URL erstellen, ihre Weiterleitung aufrufen, Besuche erfassen und Statistiken im Web-Client prüfen. Halte aufwendige externe Prüfungen aus Liveness-Probes heraus, damit der Ausfall eines Providers keine Restart-Schleife auslöst. Bei der Kapazitätsplanung sollten Weiterleitungsdurchsatz, Datenbankschreibvorgänge, Geolocation-Downloads und das Cache-Verhalten erfasst werden. Diese Werte bilden die tatsächliche Belastung von Shlink besser ab als Seitenanfragen.

Volumes sind nur die erste Wiederherstellungsebene

Im Standard-Image von Shlink wird kein beschreibbarer Anwendungsstatus innerhalb des Containers erwartet. Sichere die Datenbank, API-Schlüssel und alle importierten Besuchsdaten – einschließlich des festgelegten Digests und der geprüften Routen-Konfiguration – statt ein leeres Container-Dateisystem zu sichern.

Erstelle Shlink auf einem anderen Host von Grund auf neu und überprüfe, dass Domains, Shortcodes, Tags und Besuchsdatensätze wieder vorhanden sind und jede getestete Kurz-URL identisch weiterleitet. Wenn eine separate Datenbank, ein Room-Server oder eine Authentifizierungsschicht hinzugefügt wird, sollte diese Komponente einen eigenen, klar benannten Verantwortlichen für die Wiederherstellung haben. Der Leitfaden vom Git-Repository bis zur Produktion zeigt, wie ein reproduzierbares Artefakt ein Container-Backup ersetzt.

Dokumentiere den Rebuild-Befehl und den Test mit bekanntem Ergebnis zusammen mit dem Release. Ein zustandsloser Wiederherstellungsplan ist erfolgreich, wenn er das Verhalten aus vertrauenswürdigen Eingaben reproduziert; er sollte nicht davon abhängen, einen undurchsichtigen laufenden Container zu kopieren.

Schütze den wertvollen Teil von Shlink

Ein sicheres Shlink-Deployment beginnt damit, Berechtigungen zu reduzieren. Vermeide es, den REST-API-Schlüssel offenzulegen oder die öffentliche Domain zu ändern, nachdem Links veröffentlicht wurden. Halte API-Schlüssel stattdessen aus Browser-Code heraus, verwende HTTPS und schränke die Administration ein, während Weiterleitungen öffentlich bleiben.

DEFAULT_DOMAIN ist eine Konfiguration und kein Secret. Halte seinen Wert explizit fest und schütze gleichzeitig die separaten Credentials, die von Shlink verwendet werden. Beschränke administrative Routen, verwende private DNS-Namen für Abhängigkeiten und prüfe jeden Bind-Mount. Wenn Logs zentral gesammelt werden, filtere Secrets und private Inhalte heraus, bevor sie den Server verlassen.

Mache den Shlink-Smoke-Test zu einem Release-Check

Definiere für Shlink vor dem Launch eine Transaktion mit bekanntem Erfolg: Über die API eine Kurz-URL erstellen, ihre Weiterleitung aufrufen, Besuche erfassen und Statistiken im Web-Client prüfen. Lege die Voraussetzungen, die erwartete Antwort und die Aufräumschritte ohne Secret-Werte in der Versionsverwaltung ab. Pinne das Image, mit dem diese Referenz etabliert wird.

Verwende die Transaktion, um einen Ersatz und eine unabhängige Wiederherstellung zu validieren. Der wiederhergestellte Service ist nur dann akzeptabel, wenn Domains, Shortcodes, Tags und Besuchsdatensätze wieder vorhanden sind und jede getestete Kurz-URL identisch weiterleitet. Beobachte dabei Weiterleitungsdurchsatz, Datenbankschreibvorgänge, Geolocation-Downloads und das Cache-Verhalten und mache den langsamsten oder am stärksten begrenzten Teil zu einem Service-Level-Alert.

Der Gate-Test benötigt außerdem einen Negativfall: Verweigere der Testidentität vorübergehend den Zugriff auf Postgres oder MariaDB sowie optional Redis für den Produktionseinsatz. Bestätige, dass Shlink einen verwertbaren Fehler ausgibt und dabei die Daten erhält, stelle den gültigen Zustand wieder her und wiederhole die Transaktion mit bekanntem Erfolg. Wenn beide Ergebnisse festgehalten werden, verhindert das, dass ein oberflächlicher Health-Endpoint zum einzigen Produktionsnachweis wird.

Starte Shlink, ohne die beweglichen Teile zu verbergen

Der folgende Befehl macht die Container-Grenze sichtbar, ohne vorzugeben, alle externen Services bereitzustellen.

docker run -d \
  --name shlink \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -e DEFAULT_DOMAIN=go.example.com \
  shlinkio/shlink:stable

Bevor du den Ingress öffnest, prüfe die aufgelöste Umgebung, Mounts und den Listener. Ergänze die geprüften Verbindungsdaten für Postgres oder MariaDB sowie optional Redis für den Produktionseinsatz und verwende private Namen für private Services. Ein erfolgreicher Start ist erst abgeschlossen, wenn du über die API eine Kurz-URL erstellen, ihre Weiterleitung aufrufen, Besuche erfassen und Statistiken im Web-Client prüfen kannst – nicht schon dann, wenn docker ps Up ausgibt.

Gib Shlink eine kanonische Adresse

Die öffentliche Grenze von Shlink sollte aus einem einzigen kanonischen Hostnamen, automatischem TLS und einem internen Ziel auf Port 8080 bestehen. Setze DEFAULT_DOMAIN und IS_HTTPS_ENABLED, bevor du Kurz-URLs erstellst, damit Clients zu einer Adresse zurückkehren, die der Service kennt.

Wenn die Abnahmetransaktion fehlschlägt, ordne den ersten Fehler ein. DNS-, Zertifikats- und 502-Probleme gehören in die TLS-Validierungs-Checkliste. Die Bedingung „generierte Links verwenden HTTP oder Migrationen können die Datenbank nicht erreichen“ gehört zur Anwendungsebene, nachdem eine Anfrage Shlink erfolgreich erreicht hat.

Diagnostiziere ein scheinbar gesundes Shlink

Überwache bei Shlink eine Transaktion statt eines Prozesses: Über die API eine Kurz-URL erstellen, ihre Weiterleitung aufrufen, Besuche erfassen und Statistiken im Web-Client prüfen. Kombiniere Latenz und Fehlerrate mit Weiterleitungsdurchsatz, Datenbankschreibvorgängen, Geolocation-Downloads und Cache-Verhalten, damit ein Alert die begrenzende Komponente identifiziert.

Die Upgrade-Probe muss berücksichtigen, dass Datenbankmigrationen und API-Kompatibilität stufenweise eingeführt werden sollten, da veröffentlichte Kurz-Links nicht auf eine manuelle Reparatur warten können. Stelle den Zustand wieder her, führe die Migration durch und starte die Transaktion vor dem Austausch in der Produktion. Wenn generierte Links HTTP verwenden oder Migrationen die Datenbank nicht erreichen, lösche keine Daten, um den Start grün erscheinen zu lassen. Vergleiche stattdessen in dieser Reihenfolge Version, Variablen, Mounts und die Erreichbarkeit der Abhängigkeiten.

Halte Shlink explizit, während Dockup das Routing übernimmt

Das One-Click-Shlink-Deployment von Dockup sollte einen sicheren Austausch ermöglichen: Die Route zeigt weiterhin auf Port 8080, Secrets werden nicht in das Image eingebaut und persistente Pfade werden im neuen Container wieder eingebunden. Dasselbe Deployment kann auf Dockup Compute oder einer verbundenen Maschine laufen.

Schließe die anwendungsspezifischen Arbeiten ab, indem du Postgres oder MariaDB sowie optional Redis für den Produktionseinsatz verbindest und testest, die kanonische öffentliche Adresse festlegst und diese Abnahmeprüfung ausführst: Über die API eine Kurz-URL erstellen, ihre Weiterleitung aufrufen, Besuche erfassen und Statistiken im Web-Client prüfen. Ergänze das Ergebnis der Wiederherstellung im Runbook, bevor echte Benutzer den Service verwenden.

Häufig gestellte Fragen

Was benötigt Shlink für ein Deployment in der Produktion?

Route den Shlink-Container über eine HTTPS-Origin auf Port 8080. Die unterstützende Netzwerkanforderung besteht aus Postgres oder MariaDB sowie optional Redis für den Produktionseinsatz. Betrachte Shlink erst dann als bereit, wenn du über die API eine Kurz-URL erstellen, ihre Weiterleitung aufrufen, Besuche erfassen und Statistiken im Web-Client prüfen kannst.

Welche Shlink-Daten gehören in ein Backup?

Das Standard-Image von Shlink benötigt keinen Mount für Anwendungsdaten. Bewahre die Deployment-Konfiguration auf und sichere jeden verbundenen Zustand separat. Die Wiederherstellung ist erfolgreich, wenn Domains, Shortcodes, Tags und Besuchsdatensätze wieder vorhanden sind und jede getestete Kurz-URL identisch weiterleitet.

Benötigt Shlink HTTPS hinter einem Reverse Proxy?

Verwende HTTPS für die öffentliche Shlink-Origin und halte Port 8080 in der internen Route. Setze die Shlink-Konfiguration korrekt: Setze DEFAULT_DOMAIN und IS_HTTPS_ENABLED, bevor du Kurz-URLs erstellst. Bei Shlink schützt HTTPS Credentials oder Benutzerinhalte bei der Übertragung und sorgt für ein konsistentes, von der Origin abhängiges Client-Verhalten.

Wie sollte ein Shlink-Upgrade getestet werden?

Stelle den aktuellen Shlink-Zustand in einem isolierten Deployment wieder her, wende die Kandidatenversion an und wiederhole die Abnahmetransaktion. Gehe dabei besonders sorgfältig vor, da Datenbankmigrationen und API-Kompatibilität stufenweise eingeführt werden sollten, weil veröffentlichte Kurz-Links nicht auf eine manuelle Reparatur warten können. Behalte das vorherige Shlink-Image, bis die Grenzen der Datenmigration und des Rollbacks verstanden sind.