Slik selvhoster du Shlink i 2026: domener, API-nøkler og statistikk

Det er ved første redeploy at det blir interessant å selvhoste Shlink, ikke ved første docker run. Hvis genererte lenker bruker HTTP, eller migreringer ikke får kontakt med databasen, kan Docker fortsatt rapportere en helt frisk prosess. Distribusjonen nedenfor er bygget rundt observerbar atferd: Opprett en kort URL via API-et, følg videresendingen, registrer besøk og inspiser statistikken fra webklienten.

Formålet med Shlink er tydelig: en API-first-lenke­forkorter med statistikk. Denne beskrivelsen forteller oss hva som må være offentlig, hva som bør forbli privat, og hva en sikkerhetskopi må kunne gjenopprette.

Hva Shlink er avhengig av

Prosesshelse og produkthelse er to forskjellige ting for Shlink. Port 8080 kan svare selv om transaksjonen mot brukeren fortsatt mislykkes. Nettverkskontrakten for Shlink er Postgres eller MariaDB, samt valgfri Redis for produksjon. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall, og gi Shlink en tjenestekredential med begrenset omfang.

Bruk denne beredskapsøvelsen etter betydelige konfigurasjonsendringer: Opprett en kort URL via API-et, følg videresendingen, registrer besøk og inspiser statistikken fra webklienten. Hold kostbare eksterne kontroller utenfor liveness-prober, slik at et leverandørutfall ikke fører til en omstartsloop. Kapasitetsarbeidet bør følge med på videresendingsgjennomstrømning, databaseskrivinger, geolokaliseringsnedlastinger og cache-atferd. Dette gir et mer realistisk bilde av belastningen på Shlink enn sideforespørsler.

Volumer er bare det første laget i gjenopprettingen

Det forventes ingen skrivbar applikasjonstilstand i standardbildet for Shlink. Ta vare på databasen, API-nøklene og alle importerte besøksdata, inkludert den låste digest-en og den gjennomgåtte rutekonfigurasjonen, i stedet for å sikkerhetskopiere et tomt containerfilsystem.

Opprett Shlink fra bunnen av på en annen vert, og kontroller at domener, kortkoder, tagger og besøksdata kommer tilbake, og at alle utvalgte korte URL-er videresendes identisk. Hvis du legger til en separat database, romserver eller et autentiseringslag, skal denne komponenten ha sin egen tydelig definerte eier for gjenoppretting. Veiledningen fra Git til produksjon viser hvordan et reproduserbart artefakt erstatter en containersikkerhetskopi.

Dokumenter gjenoppbyggingskommandoen og testen med kjent resultat sammen med releasen. En tilstandsløs gjenopprettingsplan lykkes ved å gjenskape atferd fra pålitelige inngangsdata. Den bør ikke være avhengig av å kopiere en ugjennomsiktig container som kjører.

Beskytt det verdifulle i Shlink

En sikker Shlink-distribusjon begynner med å fjerne rettigheter. Unngå å eksponere REST API-nøkkelen eller endre det offentlige domenet etter at lenkene er publisert. Hold i stedet API-nøkler ute av nettleserkode, bruk HTTPS og begrens administrasjonen samtidig som videresendinger forblir offentlige.

DEFAULT_DOMAIN er konfigurasjon, ikke en hemmelighet. Hold verdien eksplisitt, samtidig som du beskytter de separate legitimasjonene Shlink bruker. Begrens administrative ruter, bruk privat DNS for avhengigheter og gjennomgå alle bind mounts. Når logger sendes til en sentral løsning, må du filtrere ut hemmeligheter og privat innhold før de forlater serveren.

Gjør Shlinks smoke-test til en release-kontroll

For Shlink bør du definere en transaksjon som fungerer, før lansering: Opprett en kort URL via API-et, følg videresendingen, registrer besøk og inspiser statistikken fra webklienten. Legg forutsetningene, forventet respons og trinnene for opprydding i versjonskontroll, uten hemmelige verdier. Lås image-versjonen som brukes til å etablere denne referansen.

Bruk transaksjonen til å validere en erstatning og en uavhengig gjenoppretting. Den gjenopprettede tjenesten er bare godkjent når domener, kortkoder, tagger og besøksdata kommer tilbake, og alle utvalgte korte URL-er videresendes identisk. Følg samtidig med på videresendingsgjennomstrømning, databaseskrivinger, geolokaliseringsnedlastinger og cache-atferd, og gjør den tregeste eller mest begrensede delen om til et tjenestenivåvarsel.

Kontrollen trenger også et negativt tilfelle: Nekt testidentiteten midlertidig tilgang til Postgres eller MariaDB, samt valgfri Redis for produksjon. Bekreft at Shlink gir en handlingsrettet feil uten å ødelegge data, gjenopprett den gyldige tilstanden og kjør transaksjonen som fungerer på nytt. Når du tar vare på begge resultatene, hindrer du at et overfladisk helseendepunkt blir det eneste produksjonsbeviset.

Start Shlink uten å skjule de bevegelige delene

Følgende kommando synliggjør containergrensen uten å late som om alle eksterne tjenester blir satt opp.

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 åpner for innkommende trafikk, må du kontrollere det ferdig evaluerte miljøet, mountene og lytteren. Legg til de gjennomgåtte tilkoblingsinnstillingene for Postgres eller MariaDB, samt valgfri Redis for produksjon. Bruk private navn for private tjenester. En vellykket oppstart er først fullført når du kan opprette en kort URL via API-et, følge videresendingen, registrere besøk og inspisere statistikken fra webklienten – ikke når docker ps skriver ut Up.

Gi Shlink én kanonisk adresse

Den offentlige grensen for Shlink bør være ett kanonisk vertsnavn, automatisk TLS og ett internt mål på 8080. Angi DEFAULT_DOMAIN og IS_HTTPS_ENABLED før du oppretter korte URL-er, slik at klientene returnerer til en adresse tjenesten kjenner igjen.

Hvis akseptansetesten mislykkes, må du klassifisere den første feilen. DNS-, sertifikat- og 502-problemer hører hjemme i sjekklisten for TLS-validering. Tilstanden «genererte lenker bruker HTTP, eller migreringer får ikke kontakt med databasen» tilhører applikasjonssiden etter at en forespørsel har nådd Shlink.

Feilsøk en Shlink som ser frisk ut

For Shlink bør du overvåke en transaksjon, ikke en prosess: Opprett en kort URL via API-et, følg videresendingen, registrer besøk og inspiser statistikken fra webklienten. Kombiner latenstid og feilrate med videresendingsgjennomstrømning, databaseskrivinger, geolokaliseringsnedlastinger og cache-atferd, slik at et varsel identifiserer den begrensede komponenten.

Oppgraderingsøvelsen må dekke at databasemigreringer og API-kompatibilitet bør fases inn, fordi publiserte korte lenker ikke kan vente på manuell reparasjon. Gjenopprett, migrer og kjør transaksjonen før du erstatter produksjonstjenesten. Hvis genererte lenker bruker HTTP, eller migreringer ikke får kontakt med databasen, må du ikke slette data for å få en grønn oppstart. Sammenlign versjon, variabler, mounts og tilgjengelighet til avhengigheter – i den rekkefølgen.

Hold Shlink eksplisitt mens Dockup håndterer rutingen

Dockups ettklikksdistribusjon av Shlink bør gjøre det trygt å erstatte tjenesten: Ruten fortsetter å peke mot 8080, hemmeligheter bygges ikke inn i imaget, og persistente stier kommer tilbake i den nye containeren. Den samme distribusjonen kan kjøre på Dockup compute eller på en tilkoblet maskin.

Fullfør det applikasjonsspesifikke arbeidet ved å koble til og teste Postgres eller MariaDB, samt valgfri Redis for produksjon. Bruk den kanoniske offentlige adressen og kjør denne akseptansetesten: Opprett en kort URL via API-et, følg videresendingen, registrer besøk og inspiser statistikken fra webklienten. Legg resultatet av gjenopprettingen i driftsveiledningen før de faktiske brukerne kommer.

Vanlige spørsmål

Hva trenger Shlink for en produksjonsdistribusjon?

Rout Shlink-containeren på port 8080 gjennom én HTTPS-opprinnelse. Det nødvendige nettverkskravet er Postgres eller MariaDB, samt valgfri Redis for produksjon. Ikke erklær Shlink klar før du kan opprette en kort URL via API-et, følge videresendingen, registrere besøk og inspisere statistikken fra webklienten.

Hvilke Shlink-data bør inngå i en sikkerhetskopi?

Standardbildet for Shlink har ingen nødvendig mount for applikasjonsdata. Ta vare på distribusjonskonfigurasjonen og sikkerhetskopier alle tilkoblede tilstander separat. Gjenopprettingen er godkjent når domener, kortkoder, tagger og besøksdata kommer tilbake, og alle utvalgte korte URL-er videresendes identisk.

Krever Shlink HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Shlink-opprinnelsen, og hold port 8080 på den interne ruten. Bruk Shlink-innstillingen riktig: Angi DEFAULT_DOMAIN og IS_HTTPS_ENABLED før du oppretter korte URL-er. For Shlink beskytter HTTPS legitimasjon eller brukerinnhold under overføring og sørger for at klientatferd som er avhengig av opprinnelsen, forblir konsistent.

Hvordan bør en Shlink-oppgradering testes?

Gjenopprett den nåværende Shlink-tilstanden i en isolert distribusjon, bruk kandidatversjonen og kjør akseptansetransaksjonen på nytt. Vær spesielt oppmerksom på dette: Databasemigreringer og API-kompatibilitet bør fases inn, fordi publiserte korte lenker ikke kan vente på manuell reparasjon. Behold det forrige Shlink-imaget til grensene for datamigrering og tilbakerulling er forstått.