Sådan selvhoster du Vikunja i 2026: offentlig URL, database og fillagring

Hvis du allerede har prøvet at selvhoste Vikunja, kender du sikkert den frustrerende situation: UI'et vises, men den offentlige API-URL er forkert, eller uploadede filer ligger ikke på et volume. Det løser sjældent problemet at oprette containeren igen, hvis der er uoverensstemmelse mellem URL'er, state og afhængigheder.

Denne gennemgang bruger ét konkret succeskriterium — opret et projekt, en opgave, en vedhæftet fil og en påmindelse, flyt opgaven på et board, og verificer dens kalenderbegivenhed og notifikation. Alle konfigurationsvalg vurderes ud fra dette kriterium i stedet for ud fra et grønt container-badge.

Hvad Vikunja afhænger af

Tegn tre grænser omkring Vikunja: ingress til port 3456, persistent state og understøttende krav. Containeren kan udskiftes, men de to andre kræver tydelige ejere. Netværkskontrakten for Vikunja er Postgres eller MySQL samt SMTP til produktionsteams. Hold private endpoints på intern DNS, tillad kun nødvendige udgående forbindelser, og giv Vikunja en afgrænset service credential.

Diagrammet er komplet, når en ren klient kan oprette et projekt, en opgave, en vedhæftet fil og en påmindelse, flytte opgaven på et board og verificere dens kalenderbegivenhed og notifikation. Indsaml tids- og resourcedata for trafik med vedhæftede filer, databaseforespørgsler, background jobs og udgående e-mail i stedet for kun at måle den lille API-proces. Hvis transaktionen fejler, viser den første grænse, der ikke opfører sig som dokumenteret, om du skal undersøge routing, lokal kapacitet eller en understøttende service.

Volumes er kun det første recovery-lag

Kortlæg state, før den første rigtige post oprettes: database, uploadede filer og konfiguration. Mount /app/vikunja/files før bootstrap, skriv ufarlige eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Bekræft mountet ved at skrive ufarlige data, udskifte Vikunja og læse dataene tilbage.

Snapshots er værdifulde til hurtig rollback, men der er brug for en uafhængig backup, hvis hosten eller dit volume forsvinder. Gendan i et tomt miljø med det fastlåste image, og verificer, at projekter, opgavehistorik, vedhæftede filer, påmindelser og brugere kommer tilbage, og at en planlagt notifikation stadig udløses. Brug persistent volumes og snapshots til at holde de to recovery-mekanismer adskilt.

Beskyt den værdifulde del af Vikunja

Efter det første login skal du gennemgå, hvad en anonym besøgende, en almindelig bruger og en administrator hver især kan gøre. Den Vikunja-fejl, du skal undgå, er at bruge en uændret JWT-secret eller ved et uheld lade registrering være åben. Den tilsigtede politik er at bruge en stabil JWT-secret, lukke for registrering, når oprettelsen af brugere er afsluttet, og adskille almindelige medlemmer fra projektadministratorer.

Generér VIKUNJA_SERVICE_JWTSECRET som en lang, tilfældig værdi. En rotation ugyldiggør normalt sessioner eller tokens, så planlæg konsekvenserne for brugerne i stedet for at kalde det en krypteringsmigration. Hold dependency-konti adskilt fra menneskelige konti, afvis unødvendig egress, hvor det er praktisk, og sæt grænser for arbejde, der påvirkes af trafik med vedhæftede filer, databaseforespørgsler, background jobs og udgående e-mail i stedet for kun at fokusere på den lille API-proces.

Gør Vikunjas smoke test til et release-tjek

En releasekandidat for Vikunja får lov til at modtage trafik ved at gennemføre et fast scenarie: opret et projekt, en opgave, en vedhæftet fil og en påmindelse, flyt opgaven på et board, og verificer dens kalenderbegivenhed og notifikation. Registrér image-digest, den effektive konfiguration uden secrets, den offentlige origin og tidsstemplerne for scenariet. Testdataene skal kunne bortskaffes, men være realistiske nok til at teste den samme sti som brugerne.

Kør testen efter at have udskiftet runtime, og rebuild derefter servicen ud fra database, uploadede filer og konfiguration. Recovery er godkendt, når projekter, opgavehistorik, vedhæftede filer, påmindelser og brugere kommer tilbage, og en planlagt notifikation stadig udløses. Sammenlign resourcemålinger for trafik med vedhæftede filer, databaseforespørgsler, background jobs og udgående e-mail — i stedet for kun den lille API-proces — med den tidligere release, og undersøg betydelig afvigelse, før du promoverer releasen.

Afslut med at afprøve denne kontrollerede fejl: Nægt midlertidigt testidentiteten adgang til Postgres eller MySQL samt SMTP til produktionsteams. Verificér, at Vikunja forklarer fejlen, ikke beskadiger eksisterende state og genoptager arbejdet, når den gyldige tilstand vender tilbage. Gem et redigeret logudsnit og recovery-tiden. Tilsammen dækker disse tjek funktionalitet, holdbarhed og driftsegenskaber — ikke kun, om processen er oppe.

Byg en Vikunja-container, der kan udskiftes

Den følgende kommando synliggør containergrænsen uden at foregive, at alle eksterne services bliver provisioneret.

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 åbner for ingress, skal du inspicere det resolved environment, mounts og listeneren. Tilføj de gennemgåede forbindelsesindstillinger for Postgres eller MySQL samt SMTP til produktionsteams, og brug private navne til private services. En vellykket opstart er først afsluttet, når du kan oprette et projekt, en opgave, en vedhæftet fil og en påmindelse, flytte opgaven på et board og verificere dens kalenderbegivenhed og notifikation — ikke når docker ps udskriver Up.

Rout Vikunja uden at lyve om HTTPS

Undgå midlertidige og permanente offentlige origins for Vikunja. Angiv i stedet VIKUNJA_SERVICE_PUBLICURL som den nøjagtige HTTPS-origin, peg det valgte DNS-navn på platformens route, og prox videre til port 3456.

Afprøv denne handling uden for hosten: Opret et projekt, en opgave, en vedhæftet fil og en påmindelse, flyt opgaven på et board, og verificer dens kalenderbegivenhed og notifikation. Hvis ingress fejler, gennemgår fejlfindingsguiden til 502 fejl med porte og listeners. Hvis Vikunja modtager requesten, men den offentlige API-URL er forkert, eller uploadede filer ikke ligger på et volume, peger evidensen nu videre end proxylaget.

Fejlfind en Vikunja-installation, der ser sund ud

For Vikunja skal du overvåge en transaktion i stedet for en proces: opret et projekt, en opgave, en vedhæftet fil og en påmindelse, flyt opgaven på et board, og verificer dens kalenderbegivenhed og notifikation. Kombinér latency og error rate med trafik med vedhæftede filer, databaseforespørgsler, background jobs og udgående e-mail i stedet for kun at måle den lille API-proces, så en alarm identificerer den komponent, der er begrænset.

Upgrade-prøvekørslen skal dække, at databasemigrationer og frontend/API-kompatibilitet skal testes, før du ændrer Vikunja-versioner. Gendan, migrér, og kør transaktionen, før du udskifter versionen i produktion. Hvis den offentlige API-URL er forkert, eller uploadede filer ikke ligger på et volume, må du ikke slette data for at få en grøn opstart. Sammenlign version, variabler, mounts og adgang til dependencies i den rækkefølge.

Deploy Vikunja på Dockup uden at miste grænserne

Dockup kan eje de udskiftelige platformdele: route trafik til port 3456, udstede domænet og certifikatet, injecte secrets, tilknytte persistent storage og forbinde Vikunja med managed eller privat tilknyttede services. Det kan ske på Dockup-infrastruktur eller på en server, du selv tilknytter.

Acceptancetestene for Vikunja er stadig eksplicitte. Efter one-click-deploymenten skal du angive VIKUNJA_SERVICE_PUBLICURL som den nøjagtige HTTPS-origin, oprette forbindelse til og teste Postgres eller MySQL samt SMTP til produktionsteams og køre dette scenarie: Opret et projekt, en opgave, en vedhæftet fil og en påmindelse, flyt opgaven på et board, og verificer dens kalenderbegivenhed og notifikation. Denne opdeling er bevidst: Dockup fjerner gentagen opsætning af infrastruktur uden at foregive, at applikationsroller, provider credentials eller restore-politik vælger sig selv.

Ofte stillede spørgsmål

Hvad har Vikunja brug for i en produktionsdeployment?

Route Vikunja-containeren på port 3456 gennem én HTTPS-origin. Det understøttende netværkskrav er Postgres eller MySQL samt SMTP til produktionsteams. Kald ikke Vikunja klar, før du kan oprette et projekt, en opgave, en vedhæftet fil og en påmindelse, flytte opgaven på et board og verificere dens kalenderbegivenhed og notifikation.

Hvilke Vikunja-data skal med i en backup?

Gør /app/vikunja/files persistent, og inkludér database, uploadede filer og konfiguration i det samme recovery-manifest. En ren Vikunja-restore er først godkendt, når projekter, opgavehistorik, vedhæftede filer, påmindelser og brugere kommer tilbage, og en planlagt notifikation stadig udløses.

Kræver Vikunja HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Vikunja-origin, og behold port 3456 på den interne route. Anvend Vikunja-indstillingen korrekt: Angiv VIKUNJA_SERVICE_PUBLICURL som den nøjagtige HTTPS-origin. For Vikunja beskytter HTTPS credentials eller brugerindhold under transport og sikrer en ensartet klientadfærd, der afhænger af origin.

Hvordan skal en Vikunja-upgrade testes?

Gendan den aktuelle Vikunja-state i en isoleret deployment, anvend kandidatversionen, og gentag acceptancetransaktionen. Vær særligt opmærksom på, at databasemigrationer og frontend/API-kompatibilitet skal testes, før du ændrer Vikunja-versioner. Behold det tidligere Vikunja-image, indtil grænserne for datamigrering og rollback er forstået.