Shlink zelf hosten in 2026: domeinen, API-sleutels en statistieken

Shlink zelf hosten wordt interessant bij de eerste redeploy, niet bij de eerste docker run. Als gegenereerde links HTTP gebruiken of migrations de database niet kunnen bereiken, kan Docker nog steeds een perfect healthy proces rapporteren. De onderstaande deployment is opgebouwd rond observeerbaar gedrag: maak via de API een korte URL aan, volg de redirect, registreer bezoeken en bekijk statistieken vanuit de webclient.

De beoogde taak van Shlink is duidelijk: een API-first link shortener met statistieken. Die omschrijving laat zien wat publiek toegankelijk moet blijven, wat privé moet blijven en wat een back-up moet kunnen reconstrueren.

Waar Shlink van afhankelijk is

Procesgezondheid en productgezondheid zijn bij Shlink twee verschillende zaken. Poort 8080 kan reageren terwijl de transactie aan de gebruikerskant nog steeds mislukt. Het netwerkcontract voor Shlink bestaat uit Postgres of MariaDB, plus optioneel Redis voor productie. Houd private endpoints op interne DNS, sta alleen noodzakelijke uitgaande verbindingen toe en geef Shlink een servicecredential met beperkte scope.

Gebruik deze readiness-oefening na betekenisvolle configuratiewijzigingen: maak via de API een korte URL aan, volg de redirect, registreer bezoeken en bekijk statistieken vanuit de webclient. Houd dure externe checks buiten liveness probes, zodat een storing bij een provider geen restart loop veroorzaakt. Bij capaciteitswerk moeten redirect throughput, database writes, geolocation downloads en cachegedrag worden gevolgd. Dat sluit beter aan bij de werkelijke belasting van Shlink dan page requests.

Volumes zijn alleen de eerste herstel-laag

In de standaard Shlink-image wordt geen schrijfbare applicatiestatus verwacht. Bewaar de database, API-sleutels en eventueel geïmporteerde bezoekgegevens, inclusief de vastgezette digest en gecontroleerde routeconfiguratie, in plaats van een lege containerfilesystem te back-uppen.

Maak Shlink op een andere host vanaf nul aan en controleer of domeinen, short codes, tags en bezoekregistraties terugkomen en elke geteste korte URL op identieke wijze redirect. Als er een aparte database, room server of authenticatielaag wordt toegevoegd, wijs dat component een eigen expliciete recovery owner toe. De handleiding van Git-repository naar productie laat zien hoe een reproduceerbaar artifact een containerback-up vervangt.

Leg het rebuild-commando en de test met bekende output vast bij de release. Een stateless recoveryplan slaagt door gedrag te reproduceren uit vertrouwde inputs; het mag niet afhankelijk zijn van het kopiëren van een ondoorzichtige draaiende container.

Bescherm het waardevolle deel van Shlink

Een veilige Shlink-deployment begint met het beperken van authority. Vermijd het blootstellen van de REST API-key en wijzig het publieke domein niet nadat links zijn gepubliceerd. Houd API-sleutels in plaats daarvan buiten browsercode, gebruik HTTPS en beperk administratie terwijl redirects publiek toegankelijk blijven.

DEFAULT_DOMAIN is configuratie en geen secret; houd de waarde expliciet en bescherm de afzonderlijke credentials die door Shlink worden gebruikt. Beperk administratieve routes, gebruik private DNS voor dependencies en controleer elke bind mount. Wanneer logs centraal worden verzameld, filter secrets en private content voordat ze de server verlaten.

Maak van de Shlink smoke test een releasecheck

Definieer voor Shlink vóór de lancering een transactie die als goed geldt: maak via de API een korte URL aan, volg de redirect, registreer bezoeken en bekijk statistieken vanuit de webclient. Zet de prerequisites, verwachte response en cleanupstappen zonder secret values in version control. Pin de image die wordt gebruikt om die referentie vast te leggen.

Gebruik de transactie om een vervanging en een onafhankelijke restore te valideren. De herstelde service is alleen acceptabel wanneer domeinen, short codes, tags en bezoekregistraties terugkomen en elke geteste korte URL op identieke wijze redirect. Observeer tegelijkertijd redirect throughput, database writes, geolocation downloads en cachegedrag en maak van het traagste of meest beperkte onderdeel een service-level alert.

De gate heeft ook een negatief geval nodig: ontzeg de testidentiteit tijdelijk toegang tot Postgres of MariaDB, plus optioneel Redis voor productie. Controleer of Shlink een bruikbare foutmelding produceert en de data behoudt, herstel de geldige toestand en herhaal de transactie die als goed geldt. Door beide resultaten te bewaren voorkom je dat een oppervlakkig health endpoint het enige bewijs voor productie wordt.

Start Shlink zonder de bewegende delen te verbergen

Met het volgende commando wordt de containergrens zichtbaar gemaakt, zonder te doen alsof elke externe service wordt geprovisioned.

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

Controleer voordat je ingress opent de opgeloste environment, mounts en listener. Voeg de gecontroleerde connection settings toe voor Postgres of MariaDB, plus optioneel Redis voor productie; gebruik private namen voor private services. Een succesvolle start is pas voltooid wanneer je via de API een korte URL kunt aanmaken, de redirect kunt volgen, bezoeken kunt registreren en statistieken vanuit de webclient kunt bekijken — niet wanneer docker ps Up afdrukt.

Geef Shlink één canoniek adres

De publieke grens voor Shlink moet bestaan uit één canonieke hostname, automatische TLS en één intern doel op 8080. Stel DEFAULT_DOMAIN en IS_HTTPS_ENABLED in voordat je short URLs aanmaakt, zodat clients verwijzen naar een adres dat de service herkent.

Als de acceptatietransactie mislukt, classificeer dan de eerste fout. Problemen met DNS, certificaten en 502 horen thuis in de TLS-validatiechecklist. De voorwaarde “gegenereerde links gebruiken HTTP of migrations kunnen de database niet bereiken” hoort bij de applicatielaag, nadat een request Shlink succesvol heeft bereikt.

Diagnose van een gezond ogende Shlink

Monitor voor Shlink een transactie in plaats van een proces: maak via de API een korte URL aan, volg de redirect, registreer bezoeken en bekijk statistieken vanuit de webclient. Combineer de latency en error rate ervan met redirect throughput, database writes, geolocation downloads en cachegedrag, zodat een alert het beperkte component identificeert.

De upgrade rehearsal moet rekening houden met het feit dat database migrations en API-compatibiliteit gefaseerd moeten worden uitgerold, omdat gepubliceerde short links niet op handmatige reparatie kunnen wachten. Restore, migrate en voer de transactie uit vóór de productievervanging. Als gegenereerde links HTTP gebruiken of migrations de database niet kunnen bereiken, wis dan geen data om de startup groen te maken; vergelijk in deze volgorde de versie, variabelen, mounts en bereikbaarheid van dependencies.

Houd Shlink expliciet terwijl Dockup de routing afhandelt

De one-click Shlink-deployment van Dockup moet een veilige vervanging mogelijk maken: de route blijft naar 8080 verwijzen, secrets worden niet in de image ingebakken en persistente paden komen terug op de nieuwe container. Dezelfde deployment kan draaien op Dockup compute of op een aangesloten machine.

Rond het app-specifieke werk af door verbinding te maken met Postgres of MariaDB, plus optioneel Redis voor productie, en deze te testen. Pas vervolgens het canonieke publieke adres toe en voer deze acceptatiecheck uit: maak via de API een korte URL aan, volg de redirect, registreer bezoeken en bekijk statistieken vanuit de webclient. Voeg het restore-resultaat aan het runbook toe voordat echte gebruikers arriveren.

Veelgestelde vragen

Wat heeft Shlink nodig voor een productiedeployment?

Routeer de Shlink-container op poort 8080 via één HTTPS-origin. De vereiste ondersteunende netwerkcomponent is Postgres of MariaDB, plus optioneel Redis voor productie. Markeer Shlink pas als klaar wanneer je via de API een korte URL kunt aanmaken, de redirect kunt volgen, bezoeken kunt registreren en statistieken vanuit de webclient kunt bekijken.

Welke Shlink-data hoort in een back-up?

De standaard Shlink-image heeft geen vereiste mount voor applicatiedata. Bewaar de deploymentconfiguratie en back-up verbonden state afzonderlijk; recovery is geslaagd wanneer domeinen, short codes, tags en bezoekregistraties terugkomen en elke geteste korte URL op identieke wijze redirect.

Heeft Shlink HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Shlink-origin en houd poort 8080 op de interne route. Pas de Shlink-instelling correct toe: stel DEFAULT_DOMAIN en IS_HTTPS_ENABLED in voordat je short URLs aanmaakt. Voor Shlink beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het ervoor dat origingevoelig clientgedrag consistent blijft.

Hoe moet een Shlink-upgrade worden getest?

Restore de huidige Shlink-state naar een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat database migrations en API-compatibiliteit gefaseerd moeten worden uitgerold en gepubliceerde short links niet op handmatige reparatie kunnen wachten. Bewaar de vorige Shlink-image totdat de grenzen voor datamigratie en rollback duidelijk zijn.