Vikunja 2026 selbst hosten: öffentliche URL, Datenbank und Dateispeicher
Vikunja mit korrekten Ports, persistentem Speicher, HTTPS, Secrets, Backups und Upgrade-Prüfungen selbst hosten. Erfahre, wie du eine falsche öffentliche API-URL behebst.
Wenn du bereits versucht hast, Vikunja selbst zu hosten, kennst du wahrscheinlich diese frustrierende Situation: Die UI wird angezeigt, aber die öffentliche API-URL ist falsch oder hochgeladene Dateien liegen nicht auf einem Volume. Den Container neu zu erstellen, behebt einen Widerspruch zwischen URLs, Status und Abhängigkeiten nur selten.
Dieser Leitfaden verwendet ein konkretes Erfolgskriterium: Erstelle ein Projekt, eine Aufgabe, einen Anhang und eine Erinnerung, verschiebe die Aufgabe auf einem Board und überprüfe das zugehörige Kalenderevent sowie die Benachrichtigung. Jede Konfigurationsentscheidung wird an diesem Kriterium gemessen – nicht an einem grünen Container-Status.
Wovon Vikunja abhängt
Ziehe drei Grenzen um Vikunja: den Ingress zu Port 3456, dauerhaften Status und unterstützende Anforderungen. Der Container ist austauschbar, die beiden anderen Bereiche benötigen jedoch klar definierte Verantwortliche. Der Netzwerkvertrag für Vikunja umfasst in Produktionsteams Postgres oder MySQL sowie SMTP. Halte private Endpunkte im internen DNS, erlaube nur erforderliche ausgehende Verbindungen und gib Vikunja ein Service-Credential mit begrenztem Geltungsbereich.
Das Diagramm ist vollständig, wenn ein sauberer Client ein Projekt, eine Aufgabe, einen Anhang und eine Erinnerung erstellen, die Aufgabe auf einem Board verschieben und das zugehörige Kalenderevent sowie die Benachrichtigung überprüfen kann. Erfasse Zeit- und Ressourcendaten für den Anhangsverkehr, Datenbankabfragen, Hintergrundjobs und ausgehende E-Mails – nicht nur für den kleinen API-Prozess. Schlägt die Transaktion fehl, zeigt die erste Grenze, die sich nicht wie dokumentiert verhält, ob du Routing, lokale Kapazität oder einen unterstützenden Dienst untersuchen musst.
Volumes sind nur die erste Wiederherstellungsebene
Erfasse den Status, bevor der erste echte Datensatz erstellt wird: Datenbank, hochgeladene Dateien und Konfiguration. Binde /app/vikunja/files vor dem Bootstrap ein, schreibe harmlose Beispieldaten und ersetze den Container, um zu beweisen, dass dieser Pfad tatsächlich persistent ist. Bestätige den Mount, indem du harmlose Daten schreibst, Vikunja ersetzt und die Daten anschließend wieder ausliest.
Snapshots sind für ein schnelles Rollback wertvoll. Verschwindet jedoch der Host oder das Volume, brauchst du ein unabhängiges Backup. Stelle die Daten in einer leeren Umgebung mit dem gepinnten Image wieder her und überprüfe, dass Projekte, Aufgabenhistorie, Anhänge, Erinnerungen und Benutzer zurückkehren und eine geplante Benachrichtigung weiterhin ausgelöst wird. Verwende persistente Volumes und Snapshots, um diese beiden Wiederherstellungsmechanismen klar voneinander zu trennen.
Schütze den wertvollen Teil von Vikunja
Überprüfe nach der ersten Anmeldung, was anonyme Besucher, normale Benutzer und Administratoren jeweils tun können. Der Vikunja-Fehler, den du vermeiden solltest, ist die Verwendung eines unveränderten JWT-Secrets oder das versehentliche Offenlassen der Registrierung. Die vorgesehene Richtlinie besteht darin, ein stabiles JWT-Secret zu verwenden, die Registrierung nach Abschluss der Anmeldung zu schließen und normale Mitglieder von Projektadministratoren zu trennen.
Erzeuge VIKUNJA_SERVICE_JWTSECRET als langen zufälligen Wert. Eine Rotation macht Sitzungen oder Tokens normalerweise ungültig. Plane daher die Auswirkungen auf Benutzer ein, statt sie als Verschlüsselungsmigration zu behandeln. Halte Konten für Abhängigkeiten von menschlichen Konten getrennt, verweigere nicht benötigten ausgehenden Datenverkehr, soweit praktikabel, und begrenze die Arbeit, die durch Anhangsverkehr, Datenbankabfragen, Hintergrundjobs und ausgehende E-Mails beeinflusst wird – nicht nur durch den kleinen API-Prozess.
Mache den Vikunja-Smoke-Test zu einem Release-Check
Ein Release Candidate für Vikunja erhält Traffic, indem er ein festgelegtes Szenario abschließt: Er erstellt ein Projekt, eine Aufgabe, einen Anhang und eine Erinnerung, verschiebt die Aufgabe auf einem Board und überprüft das zugehörige Kalenderevent sowie die Benachrichtigung. Erfasse den Image-Digest, die effektive Konfiguration ohne Secrets, den öffentlichen Ursprung und die Zeitstempel dieses Szenarios. Die Testdaten sollten löschbar, aber realistisch genug sein, um denselben Pfad wie bei echten Benutzern zu testen.
Führe den Test nach dem Ersetzen der Laufzeit aus und erstelle den Dienst anschließend aus Datenbank, hochgeladenen Dateien und Konfiguration neu. Die Wiederherstellung ist erfolgreich, wenn Projekte, Aufgabenhistorie, Anhänge, Erinnerungen und Benutzer zurückkehren und eine geplante Benachrichtigung weiterhin ausgelöst wird. Vergleiche die Ressourcenauslastung für Anhangsverkehr, Datenbankabfragen, Hintergrundjobs und ausgehende E-Mails – nicht nur für den kleinen API-Prozess – mit dem vorherigen Release und untersuche relevante Abweichungen vor der Freigabe.
Führe abschließend diesen kontrollierten Fehlerfall aus: Verweigere der Testidentität vorübergehend den Zugriff auf Postgres oder MySQL sowie SMTP für Produktionsteams. Überprüfe, dass Vikunja den Fehler verständlich erklärt, den bestehenden Status nicht beschädigt und den Betrieb wieder aufnimmt, sobald die gültigen Voraussetzungen zurückkehren. Speichere einen bereinigten Logauszug und die Wiederherstellungszeit. Zusammen decken diese Prüfungen Verhalten, Dauerhaftigkeit und Betriebsfähigkeit ab – nicht nur die Prozessverfügbarkeit.
Erstelle einen austauschbaren Vikunja-Container
Der folgende Befehl macht die Container-Grenze sichtbar, ohne vorzugeben, alle externen Dienste bereitzustellen.
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
Bevor du den Ingress öffnest, überprüfe die aufgelöste Umgebung, die Mounts und den Listener. Ergänze die geprüften Verbindungsparameter für Postgres oder MySQL sowie SMTP für Produktionsteams. Verwende für private Dienste private Namen. Ein erfolgreicher Start ist erst erreicht, wenn du ein Projekt, eine Aufgabe, einen Anhang und eine Erinnerung erstellen, die Aufgabe auf einem Board verschieben und das zugehörige Kalenderevent sowie die Benachrichtigung überprüfen kannst – nicht schon dann, wenn docker ps den Status Up ausgibt.
Leite Vikunja weiter, ohne bei HTTPS falsche Angaben zu machen
Vermeide vorübergehende und dauerhafte öffentliche Ursprünge für Vikunja. Setze stattdessen VIKUNJA_SERVICE_PUBLICURL auf den exakten HTTPS-Ursprung, verweise den gewählten DNS-Namen auf die Plattformroute und leite ausschließlich an Port 3456 weiter.
Führe diese Aktion von außerhalb des Hosts aus: Erstelle ein Projekt, eine Aufgabe, einen Anhang und eine Erinnerung, verschiebe die Aufgabe auf einem Board und überprüfe das zugehörige Kalenderevent sowie die Benachrichtigung. Schlägt der Ingress fehl, behandelt der Leitfaden zur 502-Fehlerbehebung Fehler bei Ports und Listenern. Nimmt Vikunja die Anfrage entgegen, ist aber die öffentliche API-URL falsch oder liegen hochgeladene Dateien nicht auf einem Volume, deutet die Ursache nun über den Proxy hinaus.
Diagnose eines Vikunja, das gesund aussieht
Überwache bei Vikunja eine Transaktion statt eines Prozesses: Erstelle ein Projekt, eine Aufgabe, einen Anhang und eine Erinnerung, verschiebe die Aufgabe auf einem Board und überprüfe das zugehörige Kalenderevent sowie die Benachrichtigung. Kombiniere Latenz und Fehlerrate mit Anhangsverkehr, Datenbankabfragen, Hintergrundjobs und ausgehenden E-Mails – nicht nur mit dem kleinen API-Prozess –, damit ein Alert die betroffene Komponente identifiziert.
Die Upgrade-Generalprobe muss berücksichtigen, dass Datenbankmigrationen und die Kompatibilität von Frontend und API vor einem Wechsel der Vikunja-Version getestet werden sollten. Stelle die Daten wieder her, führe die Migration durch und starte die Transaktion vor dem Austausch in der Produktion. Ist die öffentliche API-URL falsch oder liegen hochgeladene Dateien nicht auf einem Volume, lösche keine Daten, nur damit der Start grün aussieht. Vergleiche stattdessen Version, Variablen, Mounts und die Erreichbarkeit der Abhängigkeiten in dieser Reihenfolge.
Vikunja auf Dockup bereitstellen, ohne die Grenzen aufzugeben
Dockup kann die austauschbaren Plattformbestandteile übernehmen: den Traffic an Port 3456 weiterleiten, die Domain und das Zertifikat ausstellen, Secrets injizieren, persistenten Speicher anbinden und Vikunja mit verwalteten oder privat angebundenen Diensten verbinden. Das ist sowohl auf der Dockup-Infrastruktur als auch auf einem von dir angebundenen Server möglich.
Die Abnahme von Vikunja bleibt ausdrücklich deine Aufgabe. Setze nach der Bereitstellung per One-Click VIKUNJA_SERVICE_PUBLICURL auf den exakten HTTPS-Ursprung, verbinde Vikunja mit Postgres oder MySQL sowie SMTP für Produktionsteams, teste die Verbindungen und führe dieses Szenario aus: Erstelle ein Projekt, eine Aufgabe, einen Anhang und eine Erinnerung, verschiebe die Aufgabe auf einem Board und überprüfe das zugehörige Kalenderevent sowie die Benachrichtigung. Diese Aufteilung ist beabsichtigt: Dockup beseitigt wiederkehrende Infrastrukturarbeit, ohne vorzugeben, dass sich Anwendungsrollen, Provider-Credentials oder die Restore-Richtlinie von selbst festlegen.
Häufig gestellte Fragen
Was benötigt Vikunja für einen Production-Deployment?
Leite den Vikunja-Container über einen HTTPS-Ursprung an Port 3456 weiter. Die unterstützenden Netzwerkanforderungen sind Postgres oder MySQL sowie SMTP für Produktionsteams. Betrachte Vikunja erst dann als bereit, wenn du ein Projekt, eine Aufgabe, einen Anhang und eine Erinnerung erstellen, die Aufgabe auf einem Board verschieben und das zugehörige Kalenderevent sowie die Benachrichtigung überprüfen kannst.
Welche Vikunja-Daten gehören in ein Backup?
Persistiere /app/vikunja/files und nimm Datenbank, hochgeladene Dateien und Konfiguration in dasselbe Wiederherstellungsmanifest auf. Eine saubere Vikunja-Wiederherstellung ist erst erfolgreich, wenn Projekte, Aufgabenhistorie, Anhänge, Erinnerungen und Benutzer zurückkehren und eine geplante Benachrichtigung weiterhin ausgelöst wird.
Benötigt Vikunja HTTPS hinter einem Reverse Proxy?
Verwende HTTPS für den öffentlichen Vikunja-Ursprung und halte Port 3456 in der internen Route. Setze die Vikunja-Einstellung korrekt: VIKUNJA_SERVICE_PUBLICURL muss auf den exakten HTTPS-Ursprung zeigen. Bei Vikunja schützt HTTPS Zugangsdaten oder Benutzerinhalte während der Übertragung und sorgt für ein konsistentes, ursprungsabhängiges Verhalten des Clients.
Wie sollte ein Vikunja-Upgrade getestet werden?
Stelle den aktuellen Vikunja-Status in einem isolierten Deployment wieder her, spiele die Kandidatenversion ein und wiederhole die Abnahmetransaktion. Achte besonders darauf, dass Datenbankmigrationen und die Kompatibilität von Frontend und API vor einem Wechsel der Vikunja-Version getestet werden sollten. Bewahre das vorherige Vikunja-Image auf, bis die Grenzen der Datenmigration und des Rollbacks geklärt sind.