Slik selvhoster du Vikunja i 2026: offentlig URL, database og fillagring

Hvis du allerede har prøvd å selvhoste Vikunja, kjenner du sannsynligvis den frustrerende situasjonen: Grensesnittet vises, men API-ens offentlige URL er feil, eller opplastede filer ligger ikke på et volume. Det løser sjelden problemet å opprette containeren på nytt når URL-er, tilstand og avhengigheter ikke samsvarer.

Denne gjennomgangen bruker ett konkret kriterium for at løsningen er komplett — opprett et prosjekt, en oppgave, et vedlegg og en påminnelse, flytt oppgaven på et board og bekreft kalenderhendelsen og varslingen. Hvert konfigurasjonsvalg vurderes opp mot dette kriteriet, ikke mot et grønt containermerke.

Hva Vikunja er avhengig av

Trekk opp tre grenser rundt Vikunja: ingress til port 3456, persistent tilstand og støttende krav. Containeren kan erstattes, men de to andre trenger tydelige eiere. Nettverkskontrakten for Vikunja er Postgres eller MySQL samt SMTP for produksjonsteam. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi Vikunja en avgrenset servicekonto.

Diagrammet er komplett når en ren klient kan opprette et prosjekt, en oppgave, et vedlegg og en påminnelse, flytte oppgaven på et board og bekrefte kalenderhendelsen og varslingen. Samle inn tids- og ressursdata for vedleggstrafikk, databasekall, bakgrunnsjobber og utgående e-post, ikke bare for den lille API-prosessen. Hvis transaksjonen mislykkes, viser den første grensen som ikke oppfører seg som dokumentert om du bør undersøke ruting, lokal kapasitet eller en støttetjeneste.

Volumes er bare det første laget for gjenoppretting

Kartlegg tilstanden før den første virkelige posten opprettes: database, opplastede filer og konfigurasjon. Monter /app/vikunja/files før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er persistent. Bekreft monteringen ved å skrive ufarlige data, erstatte Vikunja og lese dataene tilbake.

Snapshots er nyttige for rask tilbakerulling, men du trenger en uavhengig sikkerhetskopi hvis verten eller volumet forsvinner. Gjenopprett til et tomt miljø med det fastlåste imaget, og bekreft at prosjekter, oppgavehistorikk, vedlegg, påminnelser og brukere kommer tilbake, og at en planlagt varsling fortsatt utløses. Bruk persistente volumes og snapshots for å holde disse to gjenopprettingsmekanismene atskilt.

Beskytt den verdifulle delen av Vikunja

Etter første innlogging bør du gjennomgå hva en anonym besøkende, en vanlig bruker og en administrator kan gjøre. Feilen i Vikunja du bør unngå, er å bruke en uendret JWT-secret eller å la registrering være åpen ved et uhell. Den tiltenkte policyen er å bruke en stabil JWT-secret, stenge registreringen når brukeropptaket er ferdig og skille vanlige medlemmer fra prosjektadministratorer.

Generer VIKUNJA_SERVICE_JWTSECRET som en lang, tilfeldig verdi. Hvis du roterer den, blir økter eller tokens normalt ugyldige, så planlegg konsekvensene for brukerne i stedet for å omtale det som en krypteringsmigrering. Hold kontoer for avhengigheter atskilt fra menneskelige brukerkontoer, nekt ubrukt egress der det er praktisk mulig, og sett grenser for arbeid som påvirkes av vedleggstrafikk, databasekall, bakgrunnsjobber og utgående e-post, ikke bare for den lille API-prosessen.

Gjør Vikunjas smoke test til en release-kontroll

En releasekandidat for Vikunja får trafikk ved å fullføre et fast scenario: opprett et prosjekt, en oppgave, et vedlegg og en påminnelse, flytt oppgaven på et board og bekreft kalenderhendelsen og varslingen. Registrer image-digesten, den effektive konfigurasjonen uten secrets, den offentlige origin-en og tidsstemplene for scenarioet. Testdataene bør kunne kastes, men være realistiske nok til å utøve den samme banen som brukerne.

Kjør testen etter at runtime-miljøet er erstattet, og bygg deretter tjenesten på nytt fra database, opplastede filer og konfigurasjon. Gjenopprettingen er godkjent når prosjekter, oppgavehistorikk, vedlegg, påminnelser og brukere kommer tilbake, og en planlagt varsling fortsatt utløses. Sammenlign ressursmålinger for vedleggstrafikk, databasekall, bakgrunnsjobber og utgående e-post med forrige release, ikke bare målinger fra den lille API-prosessen, og undersøk vesentlige avvik før utrulling.

Til slutt bør du utøve denne kontrollerte feilen: nekt testidentiteten midlertidig tilgang til Postgres eller MySQL samt SMTP for produksjonsteam. Bekreft at Vikunja forklarer feilen, ikke skader eksisterende tilstand og gjenopptar driften når den gyldige tilstanden er tilbake. Lagre et redigert utdrag fra loggen og gjenopprettingstiden. Til sammen dekker disse kontrollene funksjonalitet, varighet og drift, ikke bare at prosessen er oppe.

Bygg en Vikunja-container som kan erstattes

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

docker run -d \
  --name vikunja \
  --restart unless-stopped \
  -p 127.0.0.1:3456:3456 \
  -v vikunja-data:/app/vikunja/files \
  -e VIKUNJA_SERVICE_JWTSECRET=replace-with-a-long-random-value \
  vikunja/vikunja:latest

Før du åpner ingress, bør du inspisere det løste miljøet, monteringer og listeneren. Legg til de gjennomgåtte tilkoblingsinnstillingene for Postgres eller MySQL samt SMTP for produksjonsteam, og bruk private navn for private tjenester. En vellykket oppstart er først fullført når du kan opprette et prosjekt, en oppgave, et vedlegg og en påminnelse, flytte oppgaven på et board og bekrefte kalenderhendelsen og varslingen — ikke når docker ps skriver ut Up.

Rute Vikunja uten å gi feil informasjon om HTTPS

Unngå midlertidige og permanente offentlige origin-er for Vikunja. Sett i stedet VIKUNJA_SERVICE_PUBLICURL til den nøyaktige HTTPS-origin-en, pek det valgte DNS-navnet mot plattformruten og prox videre kun til port 3456.

Test dette utenfra verten: opprett et prosjekt, en oppgave, et vedlegg og en påminnelse, flytt oppgaven på et board og bekreft kalenderhendelsen og varslingen. Hvis ingress mislykkes, dekker feilsøkingsveiledningen for 502 feil med port og listener. Hvis Vikunja mottar forespørselen, men API-ens offentlige URL er feil eller opplastede filer ikke ligger på et volume, peker bevisene nå på noe utenfor proxien.

Feilsøk en Vikunja-instans som ser frisk ut

For Vikunja bør du overvåke en transaksjon, ikke en prosess: opprett et prosjekt, en oppgave, et vedlegg og en påminnelse, flytt oppgaven på et board og bekreft kalenderhendelsen og varslingen. Kombiner responstid og feilrate med vedleggstrafikk, databasekall, bakgrunnsjobber og utgående e-post, ikke bare med den lille API-prosessen, slik at et alarmvarsel identifiserer hvilken komponent som er begrenset.

Oppgraderingsøvelsen må dekke at databasemigreringer og kompatibilitet mellom frontend og API bør testes før du endrer Vikunja-versjoner. Gjenopprett, migrer og kjør transaksjonen før du erstatter produksjonsinstansen. Hvis API-ens offentlige URL er feil eller opplastede filer ikke ligger på et volume, må du ikke slette data for å få en grønn oppstart. Sammenlign versjon, variabler, monteringer og tilgjengelighet til avhengigheter i den rekkefølgen.

Distribuer Vikunja på Dockup uten å miste grensene

Dockup kan eie de erstattbare plattformdelene: rute trafikk til port 3456, utstede domenet og sertifikatet, injisere secrets, koble til persistent lagring og koble Vikunja til administrerte eller privat tilkoblede tjenester. Dette kan gjøres på Dockup-infrastruktur eller på en server du kobler til.

Akseptansearbeidet for Vikunja må fortsatt være eksplisitt. Etter ettklikksdistribueringen setter du VIKUNJA_SERVICE_PUBLICURL til den nøyaktige HTTPS-origin-en, kobler til og tester Postgres eller MySQL samt SMTP for produksjonsteam, og kjører dette scenarioet: opprett et prosjekt, en oppgave, et vedlegg og en påminnelse, flytt oppgaven på et board og bekreft kalenderhendelsen og varslingen. Denne oppdelingen er bevisst: Dockup fjerner repetitivt infrastrukturarbeid uten å late som om applikasjonsroller, leverandørlegitimasjon eller policy for gjenoppretting velger seg selv.

Vanlige spørsmål

Hva trenger Vikunja for en produksjonsdistribuering?

Rout Vikunja-containeren på port 3456 gjennom én HTTPS-origin. Nettverkskravet til støttetjenester er Postgres eller MySQL samt SMTP for produksjonsteam. Ikke kall Vikunja klar før du kan opprette et prosjekt, en oppgave, et vedlegg og en påminnelse, flytte oppgaven på et board og bekrefte kalenderhendelsen og varslingen.

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

Gjør /app/vikunja/files persistent, og inkluder database, opplastede filer og konfigurasjon i samme gjenopprettingsmanifest. En ren Vikunja-gjenoppretting er bare godkjent når prosjekter, oppgavehistorikk, vedlegg, påminnelser og brukere kommer tilbake, og en planlagt varsling fortsatt utløses.

Krever Vikunja HTTPS bak en reverse proxy?

Bruk HTTPS for Vikunjas offentlige origin, og behold port 3456 på den interne ruten. Bruk Vikunja-innstillingen riktig: sett VIKUNJA_SERVICE_PUBLICURL til den nøyaktige HTTPS-origin-en. For Vikunja beskytter HTTPS legitimasjon eller brukerinnhold under overføring og sørger for konsistent klientatferd som er avhengig av origin.

Hvordan bør en Vikunja-oppgradering testes?

Gjenopprett gjeldende Vikunja-tilstand i en isolert distribusjon, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at databasemigreringer og kompatibilitet mellom frontend og API bør testes før du endrer Vikunja-versjoner. Behold det forrige Vikunja-imaget til grensene for datamigrering og tilbakerulling er forstått.