Så självhostar du Shlink 2026: domäner, API-nycklar och statistik

Self-hosting av Shlink blir intressant vid den första redeployen, inte vid den första docker run. Om genererade länkar använder HTTP eller migreringar inte kan nå databasen kan Docker fortfarande rapportera en helt frisk process. Distributionen nedan är organiserad kring observerbart beteende: skapa en kort URL via API:t, följ dess redirect, registrera besök och granska statistik från webbklienten.

Shlinks avsedda uppgift är tydlig: en API-first-länkförkortare med statistik. Den beskrivningen visar vad som måste vara publikt, vad som bör förbli privat och vad en backup måste kunna återskapa.

Vad Shlink är beroende av

Processhälsa och produkthälsa är separata för Shlink. Port 8080 kan svara samtidigt som den användarvända transaktionen fortfarande misslyckas. Shlinks nätverkskontrakt är Postgres eller MariaDB samt valfritt Redis för produktion. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge Shlink en avgränsad service credential.

Använd detta readiness-test efter betydande konfigurationsändringar: skapa en kort URL via API:t, följ dess redirect, registrera besök och granska statistik från webbklienten. Håll kostsamma externa kontroller utanför liveness probes så att ett avbrott hos en leverantör inte orsakar en restart loop. Kapacitetsarbetet bör följa redirect-genomströmning, databasskrivningar, geolokaliseringsnedladdningar och cache-beteende, eftersom det ligger närmare Shlinks verkliga belastning än sidförfrågningar.

Volymer är bara det första återställningslagret

Ingen skrivbar applikationsdata förväntas finnas i standardavbildningen för Shlink. Bevara databasen, API-nycklarna och all importerad besöksdata, inklusive den låsta digesten och den granskade route-konfigurationen, i stället för att säkerhetskopiera ett tomt containerfilsystem.

Skapa Shlink från grunden på en annan värd och verifiera att domäner, short codes, taggar och besöksregister återkommer och att varje testad kort URL redirectar identiskt. Om en separat databas, room server eller autentiseringslösning läggs till ska den komponenten få en egen, uttrycklig recovery owner. Guiden från Git till produktion visar hur en reproducerbar artefakt ersätter en containersäkerhetskopia.

Dokumentera rebuild-kommandot och testet med förväntat resultat tillsammans med releasen. En stateless recovery-plan lyckas genom att återskapa beteendet från betrodda indata; den ska inte vara beroende av att kopiera en ogenomskinlig container i drift.

Skydda den värdefulla delen av Shlink

En säker Shlink-distribution börjar med att minska behörigheterna. Undvik att exponera REST API-nyckeln eller ändra den publika domänen efter att länkarna har publicerats. Håll i stället API-nycklar borta från browserkod, använd HTTPS och begränsa administrationen samtidigt som redirects förblir publika.

DEFAULT_DOMAIN är konfiguration, inte en hemlighet. Håll värdet explicit och skydda de separata credentials som Shlink använder. Begränsa administrativa routes, använd privat DNS för beroenden och granska varje bind mount. När loggar skickas centralt ska hemligheter och privat innehåll filtreras bort innan de lämnar servern.

Gör Shlinks smoke test till en releasekontroll

För Shlink ska du definiera en transaktion med känt korrekt resultat före lanseringen: skapa en kort URL via API:t, följ dess redirect, registrera besök och granska statistik från webbklienten. Lägg dess förutsättningar, förväntade svar och cleanup-steg i versionshantering utan hemliga värden. Lås den image som används för att etablera referensen.

Använd transaktionen för att validera en ersättning och en oberoende restore. Den återställda tjänsten är godkänd först när domäner, short codes, taggar och besöksregister återkommer och varje testad kort URL redirectar identiskt. Observera samtidigt redirect-genomströmning, databasskrivningar, geolokaliseringsnedladdningar och cache-beteende och gör den långsammaste eller mest begränsande delen till en service-level alert.

Kontrollen behöver också ett negativt fall: neka tillfälligt testidentiteten åtkomst till Postgres eller MariaDB samt valfritt Redis för produktion. Bekräfta att Shlink ger ett användbart felmeddelande utan att data går förlorad, återställ det giltiga tillståndet och upprepa transaktionen med känt korrekt resultat. Genom att behålla båda resultaten förhindrar du att en ytlig health endpoint blir det enda produktionsunderlaget.

Starta Shlink utan att dölja de rörliga delarna

Följande kommando gör containergränsen synlig utan att låtsas provisionera alla externa tjänster.

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

Innan du öppnar ingress ska du kontrollera den upplösta miljön, mounts och lyssnaren. Lägg till de granskade anslutningsinställningarna för Postgres eller MariaDB samt valfritt Redis för produktion; använd privata namn för privata tjänster. En lyckad start är klar när du kan skapa en kort URL via API:t, följa dess redirect, registrera besök och granska statistik från webbklienten – inte när docker ps skriver ut Up.

Ge Shlink en enda kanonisk adress

Den publika gränsen för Shlink bör vara ett enda kanoniskt hostname, automatisk TLS och ett internt mål på 8080. Ange DEFAULT_DOMAIN och IS_HTTPS_ENABLED innan du skapar korta URL:er så att klienterna återgår till en adress som tjänsten känner igen.

Om acceptanstestet misslyckas ska du klassificera det första felet. DNS-, certifikat- och 502-problem hör hemma i checklistan för TLS-validering. Tillståndet ”genererade länkar använder HTTP eller migreringar kan inte nå databasen” hör till applikationssidan efter att en request har nått Shlink.

Felsök en Shlink som ser frisk ut

För Shlink ska du övervaka en transaktion i stället för en process: skapa en kort URL via API:t, följ dess redirect, registrera besök och granska statistik från webbklienten. Kombinera dess latency och error rate med redirect-genomströmning, databasskrivningar, geolokaliseringsnedladdningar och cache-beteende så att en alert identifierar den begränsande komponenten.

Upgrade-repetitionen måste täcka att databasmigreringar och API-kompatibilitet bör fasas in, eftersom publicerade korta länkar inte kan vänta på manuell reparation. Återställ, migrera och kör transaktionen före bytet i produktion. Om genererade länkar använder HTTP eller migreringar inte kan nå databasen ska du inte radera data för att få starten grön; jämför version, variabler, mounts och beroendens nåbarhet i den ordningen.

Håll Shlink explicit medan Dockup hanterar routing

Dockups one-click-distribution av Shlink bör göra byten säkra: routen fortsätter att peka mot 8080, hemligheter byggs inte in i imagen och beständiga sökvägar återkommer i den nya containern. Samma distribution kan köras på Dockup compute eller på en ansluten maskin.

Slutför det appspecifika arbetet genom att ansluta och testa Postgres eller MariaDB samt valfritt Redis för produktion, tillämpa den kanoniska publika adressen och köra detta acceptanstest: skapa en kort URL via API:t, följ dess redirect, registrera besök och granska statistik från webbklienten. Lägg till restore-resultatet i runbooken innan riktiga användare anländer.

Vanliga frågor

Vad behöver Shlink för en produktionsdistribution?

Routa Shlink-containern på port 8080 via ett enda HTTPS-origin. Det stödjande nätverkskravet är Postgres eller MariaDB samt valfritt Redis för produktion. Kalla inte Shlink redo förrän du kan skapa en kort URL via API:t, följa dess redirect, registrera besök och granska statistik från webbklienten.

Vilken Shlink-data ska ingå i en backup?

Standardavbildningen för Shlink har ingen obligatorisk mount för applikationsdata. Bevara distributionskonfigurationen och säkerhetskopiera ansluten state separat. Återställningen är godkänd när domäner, short codes, taggar och besöksregister återkommer och varje testad kort URL redirectar identiskt.

Kräver Shlink HTTPS bakom en reverse proxy?

Använd HTTPS för Shlinks publika origin och håll port 8080 på den interna routen. Tillämpa Shlink-inställningen korrekt: ange DEFAULT_DOMAIN och IS_HTTPS_ENABLED innan du skapar korta URL:er. För Shlink skyddar HTTPS credentials eller användarinnehåll under överföring och håller klientbeteende som är känsligt för origin konsekvent.

Hur bör en Shlink-uppgradering testas?

Återställ aktuell Shlink-state till en isolerad deployment, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom databasmigreringar och API-kompatibilitet bör fasas in, eftersom publicerade korta länkar inte kan vänta på manuell reparation. Behåll den tidigare Shlink-imagen tills gränsen för datamigrering och rollback är förstådd.