Så hostar du Vikunja själv 2026: Publik URL, databas och fillagring

Om du redan har försökt hosta Vikunja själv känner du förmodligen igen det frustrerande läget: gränssnittet visas, men API:ts publika URL är fel eller uppladdade filer ligger inte på en volym. Att skapa om containern löser sällan en konflikt mellan URL:er, state och beroenden.

Den här genomgången använder ett konkret godkännandekriterium – skapa ett projekt, en uppgift, en bilaga och en påminnelse, flytta uppgiften på en board och verifiera dess kalenderhändelse och notis. Varje konfigurationsval utvärderas mot det kriteriet, inte mot en grön containerstatus.

Vad Vikunja är beroende av

Dra tre gränser runt Vikunja: ingress till port 3456, persistent state och stödkrav. Containern kan ersättas, men de två andra behöver tydliga ägare. Vikunjas nätverkskontrakt för produktionsteam är Postgres eller MySQL samt SMTP. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge Vikunja en avgränsad service credential.

Diagrammet är komplett när en ren klient kan skapa ett projekt, en uppgift, en bilaga och en påminnelse, flytta uppgiften på en board och verifiera dess kalenderhändelse och notis. Samla in tids- och resursdata för bilagetrafik, databasfrågor, bakgrundsjobb och utgående e-post i stället för att bara mäta den lilla API-processen. Om transaktionen misslyckas visar den första gräns som inte fungerar enligt dokumentationen om du bör undersöka routing, lokal kapacitet eller en stödtjänst.

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

Lista state innan den första riktiga posten skapas: databas, uppladdade filer och konfiguration. Montera /app/vikunja/files före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är persistent. Bekräfta monteringen genom att skriva ofarliga data, ersätta Vikunja och läsa tillbaka dem.

Snapshots är värdefulla för snabb rollback, men en oberoende säkerhetskopia behövs om värden eller volymen försvinner. Återställ till en tom miljö med den låsta imagen och verifiera att projekt, uppgiftshistorik, bilagor, påminnelser och användare kommer tillbaka och att en schemalagd notis fortfarande skickas. Använd persistenta volymer och snapshots för att hålla isär de två återställningsmekanismerna.

Skydda den värdefulla delen av Vikunja

Efter den första inloggningen bör du granska vad en anonym besökare, en vanlig användare och en administratör kan göra. Det Vikunja-fel du bör undvika är att använda en oförändrad JWT-secret eller råka lämna registreringen öppen. Den avsedda policyn är att använda en stabil JWT-secret, stänga registreringen när alla användare har lagts till och skilja vanliga medlemmar från projektadministratörer.

Generera VIKUNJA_SERVICE_JWTSECRET som ett långt, slumpmässigt värde. Om du roterar det blir sessioner eller tokens normalt ogiltiga, så planera för användarpåverkan i stället för att kalla det en krypteringsmigrering. Håll beroendekonton separata från mänskliga konton, neka oanvänd egress där det är praktiskt möjligt och begränsa arbete som påverkas av bilagetrafik, databasfrågor, bakgrundsjobb och utgående e-post i stället för att bara begränsa den lilla API-processen.

Gör Vikunjas smoke test till en releasekontroll

En releasekandidat för Vikunja får ta emot trafik genom att slutföra ett fast scenario: skapa ett projekt, en uppgift, en bilaga och en påminnelse, flytta uppgiften på en board och verifiera dess kalenderhändelse och notis. Samla in image digest, effektiv konfiguration utan secrets, publik origin och tidsstämplar för scenariot. Testdata ska kunna tas bort, men vara tillräckligt realistiska för att använda samma flöde som användarna.

Kör testet efter att runtime har ersatts och bygg sedan om tjänsten från databas, uppladdade filer och konfiguration. Återställningen är godkänd när projekt, uppgiftshistorik, bilagor, påminnelser och användare kommer tillbaka och en schemalagd notis fortfarande skickas. Jämför resursmätningar för bilagetrafik, databasfrågor, bakgrundsjobb och utgående e-post med den tidigare releasen i stället för att bara jämföra den lilla API-processen, och undersök betydande avvikelser före promotion.

Testa slutligen detta kontrollerade fel: neka tillfälligt testidentiteten åtkomst till Postgres eller MySQL samt SMTP för produktionsteam. Verifiera att Vikunja förklarar felet, inte skadar befintlig state och återupptar driften när det giltiga tillståndet återkommer. Spara ett redigerat loggutdrag och återställningstiden. Tillsammans täcker dessa kontroller beteende, hållbarhet och driftbarhet – inte bara att processen är igång.

Bygg en utbytbar Vikunja-container

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

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

Innan du öppnar ingress bör du inspektera den upplösta miljön, monteringar och listener. Lägg till de granskade anslutningsinställningarna för Postgres eller MySQL samt SMTP för produktionsteam, och använd privata namn för privata tjänster. En lyckad start är klar när du kan skapa ett projekt, en uppgift, en bilaga och en påminnelse, flytta uppgiften på en board och verifiera dess kalenderhändelse och notis – inte när docker ps skriver ut Up.

Routa Vikunja utan att ljuga om HTTPS

Undvik tillfälliga och permanenta publika origins för Vikunja. Ange i stället VIKUNJA_SERVICE_PUBLICURL till den exakta HTTPS-originen, peka det valda DNS-namnet på plattformens route och proxya endast till port 3456.

Testa detta utifrån värden: skapa ett projekt, en uppgift, en bilaga och en påminnelse, flytta uppgiften på en board och verifiera dess kalenderhändelse och notis. Om ingress misslyckas beskriver felsökningsguiden för 502 vanliga fel med port och listener. Om Vikunja tar emot anropet men API:ts publika URL är fel eller uppladdade filer inte ligger på en volym pekar bevisen nu bortom proxyn.

Diagnostisera en Vikunja som ser frisk ut

För Vikunja bör du övervaka en transaktion i stället för en process: skapa ett projekt, en uppgift, en bilaga och en påminnelse, flytta uppgiften på en board och verifiera dess kalenderhändelse och notis. Kombinera dess latency och felfrekvens med bilagetrafik, databasfrågor, bakgrundsjobb och utgående e-post i stället för att bara mäta den lilla API-processen, så att en alert identifierar den komponent som är begränsad.

Uppgraderingsrepetitionen måste omfatta att databas-migreringar och kompatibilitet mellan frontend och API ska testas innan Vikunja-versioner ändras. Återställ, migrera och kör transaktionen före ersättning i produktion. Om API:ts publika URL är fel eller uppladdade filer inte ligger på en volym ska du inte radera data för att få en grön startup; jämför version, variabler, monteringar och nåbarhet till beroenden i den ordningen.

Distribuera Vikunja på Dockup utan att förlora gränserna

Dockup kan äga de utbytbara plattformsdelarna: routa trafik till port 3456, utfärda domän och certifikat, injicera secrets, ansluta persistent lagring och koppla Vikunja till hanterade eller privat anslutna tjänster. Detta kan göras på Dockup-infrastruktur eller på en server som du ansluter.

Acceptansarbetet för Vikunja är fortfarande explicit. Efter one-click-deployen anger du VIKUNJA_SERVICE_PUBLICURL till den exakta HTTPS-originen, ansluter till och testar Postgres eller MySQL samt SMTP för produktionsteam och kör följande scenario: skapa ett projekt, en uppgift, en bilaga och en påminnelse, flytta uppgiften på en board och verifiera dess kalenderhändelse och notis. Den uppdelningen är avsiktlig: Dockup tar bort repetitiv infrastrukturkonfiguration utan att låtsas att applikationsroller, provider credentials eller återställningspolicy väljer sig själva.

Vanliga frågor

Vad behöver Vikunja för en produktionsdistribution?

Routa Vikunja-containern på port 3456 via en enda HTTPS-origin. Nätverkskravet för stödtjänster är Postgres eller MySQL samt SMTP för produktionsteam. Kalla inte Vikunja redo förrän du kan skapa ett projekt, en uppgift, en bilaga och en påminnelse, flytta uppgiften på en board och verifiera dess kalenderhändelse och notis.

Vilka Vikunja-data ska ingå i en säkerhetskopia?

Gör /app/vikunja/files persistent och inkludera databas, uppladdade filer och konfiguration i samma återställningsmanifest. En ren Vikunja-återställning är godkänd först när projekt, uppgiftshistorik, bilagor, påminnelser och användare kommer tillbaka och en schemalagd notis fortfarande skickas.

Kräver Vikunja HTTPS bakom en reverse proxy?

Använd HTTPS för Vikunjas publika origin och behåll port 3456 på den interna routen. Tillämpa Vikunja-inställningen korrekt: ange VIKUNJA_SERVICE_PUBLICURL till den exakta HTTPS-originen. För Vikunja 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 Vikunja-uppgradering testas?

Återställ aktuell Vikunja-state till en isolerad deployment, använd kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom databas-migreringar och kompatibilitet mellan frontend och API ska testas innan Vikunja-versioner ändras. Behåll den tidigare Vikunja-imagen tills gränsen för datamigrering och rollback är förstådd.