Vikunja zelf hosten in 2026: openbare URL, database en bestandsopslag

Als je al hebt geprobeerd Vikunja zelf te hosten, herken je deze frustrerende situatie waarschijnlijk: de UI verschijnt, maar de openbare URL van de API is onjuist of geüploade bestanden staan niet op een volume. De container opnieuw aanmaken lost een verschil tussen URL's, state en dependencies zelden op.

Deze walkthrough gebruikt één concreet voltooiingscriterium: maak een project, taak, bijlage en herinnering aan, verplaats de taak op een board en controleer het agenda-event en de notificatie. Elke configuratiekeuze wordt aan dat criterium getoetst, niet aan een groen containerbadge.

Waar Vikunja van afhankelijk is

Trek drie grenzen rond Vikunja: ingress naar poort 3456, duurzame state en ondersteunende vereisten. De container is vervangbaar, maar voor de andere twee zijn expliciete eigenaars nodig. Het netwerkcontract voor Vikunja bestaat voor productieteams uit Postgres of MySQL en SMTP. Houd private endpoints op interne DNS, sta alleen vereiste uitgaande verbindingen toe en geef Vikunja een servicecredential met beperkte scope.

Het diagram is compleet wanneer een schone client een project, taak, bijlage en herinnering kan aanmaken, de taak op een board kan verplaatsen en het agenda-event en de notificatie kan controleren. Verzamel timing- en resourcegegevens voor verkeer met bijlagen, databasequeries, background jobs en uitgaande e-mail, in plaats van alleen voor het kleine API-proces. Als de transactie mislukt, laat de eerste grens die zich niet gedraagt zoals gedocumenteerd zien of je routing, lokale capaciteit of een ondersteunende service moet onderzoeken.

Volumes zijn slechts de eerste herstel-laag

Leg de state vast voordat het eerste echte record wordt aangemaakt: database, geüploade bestanden en configuratie. Mount /app/vikunja/files vóór de bootstrap, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dat pad daadwerkelijk persistent is. Controleer de mount door onschadelijke data te schrijven, Vikunja te vervangen en die data opnieuw uit te lezen.

Snapshots zijn waardevol voor een snelle rollback, maar er is een onafhankelijke back-up nodig wanneer de host of het volume verdwijnt. Herstel naar een lege omgeving met de vastgezette image en controleer of projecten, taakgeschiedenis, bijlagen, herinneringen en gebruikers terugkomen en of een geplande notificatie nog steeds wordt verstuurd. Gebruik persistente volumes en snapshots om die twee herstelmechanismen van elkaar te onderscheiden.

Bescherm het waardevolle deel van Vikunja

Controleer na de eerste login wat een anonieme bezoeker, gewone gebruiker en administrator elk kunnen doen. Het Vikunja-probleem dat je wilt voorkomen, is het gebruik van een ongewijzigd JWT-secret of het per ongeluk openlaten van registratie. Het beoogde beleid is een stabiel JWT-secret gebruiken, registratie sluiten zodra de inschrijving is afgerond en gewone leden scheiden van projectadministrators.

Genereer VIKUNJA_SERVICE_JWTSECRET als een lange, willekeurige waarde; door dit normaal gesproken te roteren worden sessies of tokens ongeldig, dus plan de impact op gebruikers in plaats van dit een encryptiemigratie te noemen. Houd accounts voor dependencies gescheiden van menselijke accounts, blokkeer ongebruikte egress waar dat praktisch mogelijk is en begrens werk dat wordt beïnvloed door verkeer met bijlagen, databasequeries, background jobs en uitgaande e-mail, in plaats van alleen het kleine API-proces te begrenzen.

Maak van de Vikunja-smoketest een releasecontrole

Een release candidate voor Vikunja verdient verkeer door een vast scenario volledig uit te voeren: maak een project, taak, bijlage en herinnering aan, verplaats de taak op een board en controleer het agenda-event en de notificatie. Leg de image-digest, de effectieve configuratie zonder secrets, de openbare origin en de tijdstempels voor dat scenario vast. De testdata moet wegwerpbaar zijn, maar realistisch genoeg om hetzelfde pad als gebruikers te testen.

Voer dit uit nadat je de runtime hebt vervangen en bouw de service daarna opnieuw op vanuit de database, geüploade bestanden en configuratie. Herstel is geslaagd wanneer projecten, taakgeschiedenis, bijlagen, herinneringen en gebruikers terugkomen en een geplande notificatie nog steeds wordt verstuurd. Vergelijk de resource-metingen voor verkeer met bijlagen, databasequeries, background jobs en uitgaande e-mail met de vorige release, in plaats van alleen het kleine API-proces te vergelijken, en onderzoek betekenisvolle afwijkingen voordat je de release promoot.

Voer ten slotte deze gecontroleerde fout uit: ontzeg de testidentiteit tijdelijk de toegang tot Postgres of MySQL en SMTP voor productieteams. Controleer of Vikunja de fout uitlegt, bestaande state niet beschadigt en hervat zodra de geldige situatie terugkeert. Sla een geredigeerd logfragment en de hersteltijd op. Samen dekken deze controles gedrag, duurzaamheid en beheerbaarheid af, in plaats van alleen de uptime van het proces.

Bouw een vervangbare Vikunja-container

Met de volgende opdracht maak je de containergrens zichtbaar, zonder te doen alsof alle externe services worden ingericht.

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

Inspecteer voordat je ingress openstelt de opgeloste environment, mounts en listener. Voeg de gecontroleerde verbindingsinstellingen voor Postgres of MySQL en SMTP voor productieteams toe; gebruik private namen voor private services. Een succesvolle launch is pas afgerond wanneer je een project, taak, bijlage en herinnering kunt aanmaken, de taak op een board kunt verplaatsen en het agenda-event en de notificatie kunt controleren, niet wanneer docker ps Up afdrukt.

Routeer Vikunja zonder te doen alsof HTTPS actief is

Vermijd tijdelijke en permanente openbare origins voor Vikunja. Stel in plaats daarvan VIKUNJA_SERVICE_PUBLICURL in op de exacte HTTPS-origin, laat de gekozen DNS-naam naar de platformroute wijzen en proxy uitsluitend naar poort 3456.

Voer deze actie uit vanaf buiten de host: maak een project, taak, bijlage en herinnering aan, verplaats de taak op een board en controleer het agenda-event en de notificatie. Als ingress mislukt, behandelt de handleiding voor 502-problemen fouten met poorten en listeners. Als Vikunja het request ontvangt maar de openbare URL van de API onjuist is of geüploade bestanden niet op een volume staan, wijst het bewijs nu verder dan de proxy.

Diagnose van een gezond ogende Vikunja-installatie

Monitor voor Vikunja een transactie in plaats van een proces: maak een project, taak, bijlage en herinnering aan, verplaats de taak op een board en controleer het agenda-event en de notificatie. Combineer de latency en error rate hiervan met verkeer met bijlagen, databasequeries, background jobs en uitgaande e-mail, in plaats van alleen metingen van het kleine API-proces te gebruiken, zodat een alert het component met de beperking identificeert.

De upgrade-rehearsal moet omvatten dat database-migraties en compatibiliteit tussen frontend en API moeten worden getest voordat je Vikunja-versies wijzigt. Herstel, migreer en voer de transactie uit vóór je de productieomgeving vervangt. Als de openbare URL van de API onjuist is of geüploade bestanden niet op een volume staan, wis dan geen data om de startup groen te maken; vergelijk versie, variabelen, mounts en bereikbaarheid van dependencies in die volgorde.

Implementeer Vikunja op Dockup zonder de grenzen te vervagen

Dockup kan de vervangbare platformonderdelen beheren: verkeer naar poort 3456 routeren, het domein en certificaat uitgeven, secrets injecteren, persistente opslag koppelen en Vikunja verbinden met beheerde of privé gekoppelde services. Dit kan op de infrastructuur van Dockup of op een server die je koppelt.

Het acceptatiewerk voor Vikunja blijft expliciet. Stel na de one-click deployment VIKUNJA_SERVICE_PUBLICURL in op de exacte HTTPS-origin, verbind met Postgres of MySQL en SMTP voor productieteams, test deze verbindingen en voer dit scenario uit: maak een project, taak, bijlage en herinnering aan, verplaats de taak op een board en controleer het agenda-event en de notificatie. Die verdeling is bewust: Dockup neemt repetitieve infrastructuurconfiguratie weg, zonder te doen alsof applicatierollen, providercredentials of het restorebeleid vanzelf worden bepaald.

Veelgestelde vragen

Wat heeft Vikunja nodig voor een productie-implementatie?

Routeer de Vikunja-container op poort 3456 via één HTTPS-origin. De vereiste ondersteunende netwerkvoorzieningen zijn Postgres of MySQL en SMTP voor productieteams. Verklaar Vikunja pas gereed wanneer je een project, taak, bijlage en herinnering kunt aanmaken, de taak op een board kunt verplaatsen en het agenda-event en de notificatie kunt controleren.

Welke Vikunja-data hoort in een back-up?

Maak /app/vikunja/files persistent en neem de database, geüploade bestanden en configuratie op in hetzelfde herstelmanifest. Een schone Vikunja-restore is alleen geslaagd wanneer projecten, taakgeschiedenis, bijlagen, herinneringen en gebruikers terugkomen en een geplande notificatie nog steeds wordt verstuurd.

Heeft Vikunja HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de openbare Vikunja-origin en houd poort 3456 op de interne route. Pas de Vikunja-instelling correct toe: stel VIKUNJA_SERVICE_PUBLICURL in op de exacte HTTPS-origin. Voor Vikunja beschermt HTTPS credentials of gebruikerscontent tijdens transport en zorgt het voor consistent gedrag van clients die afhankelijk zijn van de origin.

Hoe test je een Vikunja-upgrade?

Herstel de huidige Vikunja-state naar een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat database-migraties en compatibiliteit tussen frontend en API moeten worden getest voordat je Vikunja-versies wijzigt. Bewaar de vorige Vikunja-image totdat de grenzen van datamigratie en rollback duidelijk zijn.