Sådan self-hoster du Shlink i 2026: Domæner, API-nøgler og statistik

Det bliver interessant at self-hoste Shlink ved den første redeploy – ikke ved den første docker run. Hvis genererede links bruger HTTP, eller migrations ikke kan få forbindelse til databasen, kan Docker stadig rapportere en proces, der ser helt sund ud. Deploymentet nedenfor er struktureret omkring observerbar adfærd: Opret en short URL via API'et, følg dens redirect, registrér besøg, og kontrollér statistik fra webklienten.

Shlinks formål er tydeligt: en API-first link shortener med statistik. Den beskrivelse fortæller os, hvad der skal være offentligt, hvad der bør forblive privat, og hvad en backup skal kunne genskabe.

Hvad Shlink afhænger af

Proceshelbred og produkthelbred er to forskellige ting for Shlink. Port 8080 kan svare, selvom den brugerrettede transaktion stadig fejler. Shlinks netværkskontrakt er Postgres eller MariaDB samt valgfri Redis til produktion. Hold private endpoints på intern DNS, tillad kun nødvendige udgående kald, og giv Shlink en afgrænset service credential.

Brug denne readiness-øvelse efter væsentlige konfigurationsændringer: Opret en short URL via API'et, følg dens redirect, registrér besøg, og kontrollér statistik fra webklienten. Hold dyre eksterne checks ude af liveness probes, så et nedbrud hos en udbyder ikke udløser en restart loop. Kapacitetsarbejde bør følge redirect-gennemløb, databaseskrivninger, geolocation-downloads og cache-adfærd, hvilket ligger tættere på Shlinks reelle belastning end sideforespørgsler.

Volumes er kun det første recovery-lag

Der forventes ingen skrivbar applikationstilstand inde i det standardiserede Shlink-image. Bevar databasen, API-nøglerne og eventuelle importerede besøgsdata, herunder den pinnede digest og den gennemgåede route-konfiguration, i stedet for at tage backup af et tomt container-filsystem.

Opret Shlink fra bunden på en anden host, og verificér, at domæner, short codes, tags og besøgsregistreringer kommer tilbage, og at alle udvalgte short URLs redirecter identisk. Hvis der tilføjes en separat database, room server eller et authentication layer, skal den pågældende komponent have sin egen eksplicitte recovery-ejer. Guiden fra Git til produktion viser, hvordan et reproducerbart artifact erstatter en container-backup.

Registrér rebuild-kommandoen og testen med det forventede output sammen med releasen. En stateless recovery-plan lykkes ved at reproducere adfærd fra pålidelige input; den bør ikke afhænge af at kopiere en uigennemsigtig, kørende container.

Beskyt den værdifulde del af Shlink

Et sikkert Shlink-deployment begynder med at fjerne rettigheder. Undgå at eksponere REST API-nøglen eller ændre det offentlige domæne, efter at links er udgivet. Hold i stedet API-nøgler ude af browserkode, brug HTTPS, og begræns administrationen, mens redirects forbliver offentlige.

DEFAULT_DOMAIN er konfiguration og ikke en secret; hold værdien eksplicit, mens de separate credentials, som Shlink bruger, beskyttes. Begræns administrative routes, brug privat DNS til dependencies, og gennemgå alle bind mounts. Når logs sendes centralt, skal secrets og privat indhold filtreres, før de forlader serveren.

Gør Shlinks smoke test til et release-check

For Shlink skal du definere en kendt-god transaktion før lancering: Opret en short URL via API'et, følg dens redirect, registrér besøg, og kontrollér statistik fra webklienten. Læg dens forudsætninger, forventede response og cleanup-trin i version control uden secret-værdier. Pin det image, der bruges til at etablere denne reference.

Brug transaktionen til at validere en replacement og en uafhængig restore. Den gendannede service er kun acceptabel, når domæner, short codes, tags og besøgsregistreringer kommer tilbage, og alle udvalgte short URLs redirecter identisk. Overvåg samtidig redirect-gennemløb, databaseskrivninger, geolocation-downloads og cache-adfærd, og lav den langsomste eller mest begrænsede del om til en service-level alert.

Gaten skal også indeholde et negativt testtilfælde: Afvis midlertidigt testidentitetens adgang til Postgres eller MariaDB samt valgfri Redis til produktion. Bekræft, at Shlink genererer en handlingsanvisende fejl, samtidig med at data bevares, genskab den gyldige tilstand, og gentag den kendt-gode transaktion. Når begge resultater bevares, forhindrer det, at et overfladisk health endpoint bliver det eneste produktionsbevis.

Start Shlink uden at skjule de bevægelige dele

Følgende kommando synliggør containergrænsen uden at lade som om, at alle eksterne services bliver provisioneret.

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

Før du åbner for ingress, skal du inspicere det evaluerede environment, mounts og listeneren. Tilføj de gennemgåede forbindelsesindstillinger til Postgres eller MariaDB samt valgfri Redis til produktion, og brug private navne til private services. En vellykket opstart er først afsluttet, når du kan oprette en short URL via API'et, følge dens redirect, registrere besøg og kontrollere statistik fra webklienten – ikke når docker ps viser Up.

Giv Shlink én kanonisk adresse

Den offentlige grænse for Shlink bør være ét kanonisk hostname, automatisk TLS og ét internt target på 8080. Angiv DEFAULT_DOMAIN og IS_HTTPS_ENABLED, før du opretter short URLs, så klienter vender tilbage til en adresse, som servicen genkender.

Hvis acceptance-transaktionen fejler, skal du klassificere den første fejl. DNS-, certifikat- og 502-problemer hører til i checklisten til TLS-validering. Betingelsen “genererede links bruger HTTP, eller migrations kan ikke få forbindelse til databasen” hører til på applikationssiden, efter at en request er nået frem til Shlink.

Diagnosticér en Shlink, der ser sund ud

For Shlink skal du overvåge en transaktion i stedet for en proces: Opret en short URL via API'et, følg dens redirect, registrér besøg, og kontrollér statistik fra webklienten. Kombinér dens latency og error rate med redirect-gennemløb, databaseskrivninger, geolocation-downloads og cache-adfærd, så en alert identificerer den begrænsede komponent.

Upgrade-rehearsalen skal dække, at databasemigrations og API-kompatibilitet bør stages, fordi publicerede short links ikke kan vente på manuel reparation. Genskab, migrér, og kør transaktionen før udskiftning i produktion. Hvis genererede links bruger HTTP, eller migrations ikke kan få forbindelse til databasen, må du ikke slette data for at få opstarten til at se grøn ud. Sammenlign version, variabler, mounts og dependency reachability i den rækkefølge.

Hold Shlink eksplicit, mens Dockup håndterer routing

Dockups one-click Shlink-deployment bør gøre udskiftning sikker: Routen fortsætter med at pege på 8080, secrets bygges ikke ind i imaget, og persistente paths kommer tilbage på den nye container. Det samme deployment kan køre på Dockup compute eller på en tilknyttet maskine.

Afslut det applikationsspecifikke arbejde ved at forbinde og teste Postgres eller MariaDB samt valgfri Redis til produktion, anvende den kanoniske offentlige adresse og køre dette acceptance-check: Opret en short URL via API'et, følg dens redirect, registrér besøg, og kontrollér statistik fra webklienten. Tilføj resultatet af restore til runbooken, før de første rigtige brugere ankommer.

Ofte stillede spørgsmål

Hvad skal Shlink bruge til en deployment i produktion?

Route Shlink-containeren på port 8080 gennem én HTTPS-origin. Det understøttende netværkskrav er Postgres eller MariaDB samt valgfri Redis til produktion. Kald ikke Shlink klar, før du kan oprette en short URL via API'et, følge dens redirect, registrere besøg og kontrollere statistik fra webklienten.

Hvilke Shlink-data hører hjemme i en backup?

Standard-Shlink-imaget har ingen nødvendig mount til applikationsdata. Bevar deployment-konfigurationen, og tag backup af tilknyttet state separat. Recovery er godkendt, når domæner, short codes, tags og besøgsregistreringer kommer tilbage, og alle udvalgte short URLs redirecter identisk.

Kræver Shlink HTTPS bag en reverse proxy?

Brug HTTPS for den offentlige Shlink-origin, og behold port 8080 på den interne route. Anvend Shlink-indstillingen korrekt: Angiv DEFAULT_DOMAIN og IS_HTTPS_ENABLED, før du opretter short URLs. For Shlink beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet klientadfærd, der afhænger af origin.

Hvordan bør en Shlink-opgradering testes?

Genskab den aktuelle Shlink-state i et isoleret deployment, anvend kandidatversionen, og gentag acceptance-transaktionen. Vær særligt opmærksom, fordi databasemigrations og API-kompatibilitet bør stages, eftersom publicerede short links ikke kan vente på manuel reparation. Behold det tidligere Shlink-image, indtil grænsen for datamigration og rollback er forstået.