Die Open-Source-Urlaubsverwaltung ist eine ernstzunehmende Alternative zu Papierlisten oder einfachen Kalendern – aber sie ist kein Plug-and-Play-Produkt. Wer sie produktiv betreiben will, braucht laut Projektunterlagen ein Java/Spring-Boot-Setup, eine PostgreSQL-Datenbank, einen E-Mail-Server und eine OIDC-Anbindung und muss mit regelmäßigen Releases und offenen Issues rechnen. Unternehmen ohne eigenes Java-Team sollten deshalb vor der Einführung klären, wer Betrieb, Upgrade und Wartung verantwortet – sonst wird aus dem Ersatz fürs Papierchaos schnell ein neues Wartungsprojekt.

Was die Urlaubsverwaltung kann und für wen sie gedacht ist

Laut README des Projekts ist die Urlaubsverwaltung eine Web-Anwendung zur elektronischen Verwaltung von Abwesenheiten. Mitarbeitende stellen Urlaubsanträge, die berechtigte Personen genehmigen, ablehnen oder stornieren; Überstunden und Krankmeldungen lassen sich direkt pflegen. Das Rechte-Modell sieht laut Projektunterlagen die Rollen „inaktiv“, „User“, „Abteilungsleiter“, „Freigabe-Verantwortlicher“, „Chef“ und „Office“ vor, wobei eine Person mehrere Rollen haben kann. Damit deckt die Software typische deutsche Abwesenheitsprozesse mit ein- oder zweistufiger Freigabe ab.

Das Projekt existiert laut GitHub-Daten seit Juli 2013, ist unter Apache-2.0 lizenziert und wird derzeit aktiv weiterentwickelt: Der letzte Push im Repository stammt vom 25. August 2026, und zwischen dem 10. Juli und dem 8. August 2026 sind die Versionen 6.3.0 bis 6.7.0 erschienen. Für Teams, die eine selbst gehostete, in Java gepflegte Lösung suchen, ist das ein relevantes Signal – für alle anderen zählt vor allem der Betriebsaufwand.

Die wichtigsten Fakten im Überblick

Betrieb: Was beim produktiven Einsatz wirklich zählt

Die Maintainer nennen im README vier Voraussetzungen für den Betrieb: JDK 25, eine PostgreSQL-Datenbank (Version 18), einen E-Mail-Server und einen Security Provider. Die Anwendung wird entweder als JAR-Datei aus den Releases oder als Docker-Image betrieben; beim ersten Start werden die Datenbanktabellen laut Projektunterlagen automatisch angelegt. Vor der Produktivnahme müssen Datenbankzugang, E-Mail-Versand und die OIDC-Anbindung in einer eigenen application.yaml hinterlegt werden – die Standardwerte reichen laut README ausdrücklich nicht aus.

Ein Punkt, der häufig unterschätzt wird, ist die Authentifizierung: Der OIDC-Provider muss im Access Token die Attribute given_name, family_name und email liefern, und die Client-Registrierung braucht die Scopes openid, profile und email. Der erste Benutzer, der sich anmeldet, erhält laut Projektunterlagen automatisch die Rolle Office. Wer hier eine falsche oder unvollständige Konfiguration hat, bekommt nach dem Deployment keine funktionierende Anmeldung. Hilfreich ist laut README, bei Startproblemen zuerst das Logging zu konfigurieren, um die Fehlerursache zu sehen – ein klassischer Fall, bei dem Erfahrung mit Spring Boot und Identity-Anbietern Zeit spart.

Sicherheit und Berechtigungen: genau prüfen, bevor es live geht

Die Anwendung trennt Abwesenheitsdaten über Rollen, nicht nur über die Oberfläche. Trotzdem gibt es Punkte, die ein Unternehmen intern prüfen sollte. Die Projektunterlagen erwähnen die Kalenderfreigabe: Wenn die Rolle Office die unternehmensweite Kalenderfreigabe aktiviert, können berechtigte Mitarbeitende Urlaube im Unternehmen einsehen. In einem offenen Issue wünschen sich Nutzer eine feinere Steuerung, wer diese Funktion nutzen darf, sowie Optionen zur inhaltlichen Tiefe von iCal-Freigaben, damit zum Beispiel nicht jede Abwesenheitsart mit allen Details geteilt wird.

Diese offenen Punkte sind keine Aussage über konkrete Fehler, aber sie zeigen: Wer die Lösung einführt, sollte vorher festlegen, wer welche Abwesenheitsdaten sehen darf, und die Rollen- und Kalenderkonfiguration testen. Auch die Archivierung gehört dazu: Laut README bleiben die Daten deaktivierter Benutzer zur Archivierung bestehen. Ob das zu den eigenen Lösch- und Aufbewahrungsanforderungen passt, muss jedes Unternehmen selbst bewerten.

Wartung und Upgrades: der eigentliche Aufwand

Die Release-Aktivität ist hoch: Innerhalb von rund vier Wochen sind die Versionen 6.3.0, 6.4.0, 6.5.0, 6.6.0 und 6.7.0 erschienen. Die Release Notes nennen neben neuen Funktionen viele Dependency-Upgrades sowie Bugfixes, unter anderem für Statistiken und die Darstellung auf Mobilgeräten. Wer die Anwendung langfristig betreibt, sollte Updates deshalb nicht sammeln, sondern als regelmäßige Aufgabe einplanen: Release lesen, in einer Testumgebung prüfen, Datenbank- und Konfigurationsänderungen verstehen, dann ausrollen.

Positiv ist, dass das Projekt laut README einen Migrations-Guide für größere Versionssprünge bereitstellt. Trotzdem bleibt ein Restaufwand, der von außen oft unterschätzt wird: 218 offene Issues stehen im Repository, darunter auch ältere Themen wie die zeitliche Anlage des Urlaubskontos (Issue #858, seit 2019 offen, im 6.x-Meilenstein geplant). Manche Performance-Probleme in Statistikansichten wurden erst in den jüngsten Releases behoben. Das ist normale Software-Realität, aber es zeigt, dass „läuft bei uns“ nicht dasselbe ist wie „wird gepflegt“.

Hat Ihr System ein ähnliches Problem?

Passenden Service ansehen · Kontakt aufnehmen

Grenzen und offene Punkte: ehrlich einordnen

Diese Bewertung basiert auf einer Repository- und Dokumentationsprüfung; eine lokale Installation oder ein Laufzeittest wurde nicht durchgeführt. Technische Angaben stammen aus dem README, den Release Notes und offenen Issues und sind den Maintainern beziehungsweise den jeweiligen Autoren zuzuordnen.

Aus den offenen Issues ergeben sich außerdem Funktionslücken, die für die Entscheidung relevant sind: Es gibt laut Issue #2226 keinen etablierten Genehmigungsprozess für Überstunden, und die API bietet laut Issue #2557 bislang keine vollständigen GET-/POST-Methoden für Überstunden. Wer Überstunden automatisiert aus einer Zeiterfassung synchronisieren will, muss das entweder über die vorhandene API-Strecke prüfen oder individuell entwickeln. Auch die iCal-Freigabe ist in der Tiefe eingeschränkt (Issue #1735). Das sind bekannte, transparente Punkte – aber eben Punkte, die ein Unternehmen vor der Einführung kennen sollte.

Entscheidungskriterien: Wann die Open-Source-Lösung passt

• Sie haben ein Java- oder Spring-Boot-Team oder einen Dienstleister, der Betrieb und Updates verantwortet.
• Ihr Abwesenheitsprozess passt zu den vorhandenen Rollen inklusive ein- oder zweistufiger Freigabe.
• Sie können PostgreSQL, E-Mail-Versand und einen OIDC-Provider bereitstellen und betreiben.
• Sie akzeptieren regelmäßige Releases und planen Update- und Testaufwand ein.
• Ihre Integrationen (zum Beispiel Zeiterfassung oder HR-Systeme) lassen sich mit der vorhandenen API abbilden oder gezielt ergänzen.

Wenn mehrere dieser Punkte nicht erfüllt sind, ist eine fertige SaaS-Lösung oder ein individuell entwickeltes, betreutes System die pragmatischere Wahl.

Wann Sie externe Entwicklung und Wartung einplanen sollten

Die typischen Situationen, in denen Unternehmen bei einer selbst gehosteten Urlaubsverwaltung an Grenzen stoßen, sind selten exotisch: Die Instanz wurde von einem ehemaligen Mitarbeiter aufgesetzt und niemand kennt die Konfiguration; ein Versionssprung über mehrere Releases schlägt beim ersten Update fehl; nach einem Serverwechsel startet die Anwendung nicht oder der OIDC-Login bricht; oder die Abteilung möchte Überstunden aus der Zeiterfassung automatisch anbinden. Genau für diese Fälle sind spezialisierte Entwickler gefragt, die bestehende Systeme übernehmen, reparieren, migrieren und anschließend warten.

XP812 begleitet Unternehmen hands-on bei genau diesen Aufgaben: Übernahme bestehender Anwendungen, Reparatur von Produktionsstörungen, Upgrades und Migrationen, API-Integrationen sowie laufende Wartung von Business-Systemen. Gerade bei der Urlaubsverwaltung lohnt sich das, weil die laufenden Kosten weniger in der Software als in der Betreuung liegen: Releases prüfen, Konfiguration nachvollziehen, Datenbank- und OIDC-Themen beherrschen und Integrationen stabil halten.

Unser Fazit

Die Open-Source-Urlaubsverwaltung ist funktional überzeugend, aktiv gepflegt und für deutsche Abwesenheitsprozesse gut geeignet – unter einer Bedingung: Sie braucht jemanden, der sie kompetent betreibt. Für Teams mit Java-Erfahrung ist das Projekt eine solide, transparente Basis. Für alle anderen ist die Betreuungsfrage wichtiger als die Feature-Liste. Wer weder Kapazität noch Know-how für Betrieb, Upgrade und Integration hat, sollte diese Aufgabe bewusst an einen externen Dienstleister geben – oder sich frühzeitig für eine betreute Alternative entscheiden.

Hat Ihr System ein ähnliches Problem? Wenn Störungen, Angriffe, Upgrades oder fehlende Wartung den Betrieb beeinträchtigen, kann ich Analyse und Behebung übernehmen.

Passenden Service ansehen · Kontakt aufnehmen

Quellen

• GitHub Repository: urlaubsverwaltung/urlaubsverwaltung
• README: Betrieb, Konfiguration, Entwicklung und Support
• Release 6.7.0 (08.08.2026)
• Issue #858: Urlaubskonto wird erst nach dem Jahreswechsel angelegt
• Issue #2557: API GET und POST für Überstunden
• Issue #1748: Kalenderfreigabe der Firma einschränken