Ein Terminbuchungstool ist eigentlich eine kleine Sache: ein paar freie Zeitfenster anzeigen, Name und E-Mail-Adresse entgegennehmen, eine Bestätigung verschicken. Trotzdem landen genau diese Daten auf den meisten Websites bei einem externen Anbieter, oft außerhalb der EU, samt eingebettetem Skript, das schon beim Seitenaufruf Verbindungen aufbaut. Auch ich habe lange solche Tools genutzt. Für eine Website, die sich mit digitaler Nachhaltigkeit beschäftigt, fühlte sich das aber zunehmend falsch an. Deshalb läuft die Terminbuchung auf datensm.art jetzt mit cal.rs, und zwar auf meinem eigenen Server.
Was cal.rs ist
cal.rs ist eine quelloffene Terminplanungssoftware unter AGPL-3.0-Lizenz, entwickelt von Olivier Lambert. Er beschreibt sie selbst als „Like Cal.com, but self-hosted“ – ohne Node.js, ohne PostgreSQL, ohne Abo. Technisch besteht das Ganze aus einer einzigen ausführbaren Datei, geschrieben in Rust, einer SQLite-Datenbank in einer einzelnen Datei und ein paar HTML-Templates. Auf dem Server läuft genau ein Prozess dauerhaft im Hintergrund. Laut Projektseite stellt die Software zur Laufzeit keine externen Anfragen.
Rust ist eine moderne Programmiersprache, die schnelle und sparsame Programme erzeugt, ohne dass eine schwere Laufzeitumgebung mitlaufen muss. Das merke ich im Betrieb: kein Framework-Stapel, kein Paketmanager, kein Datenbankserver, der gewartet werden will.
Drei Gründe, die für mich zählen
Datenschutz: Wer bei mir einen Termin bucht, gibt Namen, E-Mail-Adresse und Anliegen an. Diese Daten bleiben jetzt auf meinem Server und wandern nicht zu einem Dritten mit eigenen Geschäftsinteressen. Eine Einschränkung gehört dazu: Aktuell ist noch mein Google-Kalender angebunden, über den cal.rs meine freien Zeiten abgleicht. Als nächsten Schritt plane ich den Wechsel auf einen selbst betriebenen CalDAV-Kalender, die Software unterstützt ihn bereits.
Digitale Nachhaltigkeit: Ein kompiliertes Programm mit SQLite braucht keine Container-Landschaft, keinen separaten Datenbankserver und kein schweres JavaScript-Widget im Browser meiner Besucher. Auf meinem Server belegt der laufende Prozess rund 34 MB Arbeitsspeicher. Wenig im Vergleich zu anderen Bibliotheken. Und vor allem: Weniger JavaScript bedeutet weniger Rechenlast, weniger Wartung und weniger Angriffsfläche.
Digitale Unabhängigkeit: Kein Anbieter kann Preise erhöhen, Funktionen hinter eine Bezahlschranke schieben oder den Dienst einstellen. Der Quellcode ist offen, die Daten liegen in einer einzigen Datei, die ich jederzeit sichern kann. Nebenbei entfallen die laufenden Kosten für ein externes Kalendertool.
Wie sich das im Alltag anfühlt
Das Layout an datensm.art anzupassen, war überraschend einfach: Die Oberfläche basiert auf Templates und bringt Farbthemen mit, die sich mit eigenen Farben überschreiben lassen. Das Projekt ist sehr aktiv. Seit Juni sind mehrere Versionen erschienen, unter anderem mit Google-OAuth, Exchange-Anbindung und SMS-Benachrichtigungen. Als mir auffiel, dass in den Bestätigungsmails falsche Uhrzeiten standen, habe ich das gemeldet. Der Entwickler hat den Fehler für Version 1.17.1 kurzfristig bestätigt, die Korrektur ist für die nächste Version angekündigt.
Was Du heute tun kannst
Schau Dir an, welche Drittanbieter-Skripte auf Deiner Kontakt- oder Buchungsseite geladen werden. Der Netzwerk-Tab in den Entwicklertools Deines Browsers zeigt es in Sekunden. Jede externe Verbindung ist eine Frage wert: Brauche ich die wirklich, oder geht es auch schlanker und unter eigener Kontrolle? Und wenn Du über genau solche Fragen mit mir sprechen willst: Hier kannst Du einen Termin buchen, selbstverständlich über cal.rs.
Digitale Unabhängigkeit beginnt nicht mit großen Strategiepapieren, sondern mit der Frage, wo Dein nächster Kundentermin gespeichert wird.
Quellen: cal.rs – Self-hostable scheduling in Rust · calrs auf GitHub · calrs Release-Übersicht