Warum wir Directus.io für datengetriebene Projekte nutzen
Directus.io ist unser Werkzeug, wenn es um datengetriebene Projekte geht: APIs, Datenverwaltung, und Backend-as-a-Service — ohne proprietären Lock-in und mit voller Kontrolle über die eigene Datenbank.
Nicht jedes Projekt braucht ein klassisches CMS. Manchmal geht es um Daten: strukturierte Datensätze, die über APIs zugänglich gemacht werden müssen, die von verschiedenen Systemen gelesen und geschrieben werden, und die eine eigene Verwaltungsoberfläche brauchen.
Für solche Projekte setzen wir Directus.io ein — ein Open-Source-Tool, das aus jeder Datenbank eine vollständige API-Plattform mit Admin-Oberfläche macht.
Was Directus.io ist
Directus.io ist kein klassisches CMS im Sinne von «Inhalte verwalten, Website ausgeben». Es ist ein Data Platform Layer — eine Schicht, die sich über eine bestehende oder neue relationale Datenbank legt und automatisch APIs generiert.
Der Ansatz ist radikal datenbankorientiert: Directus lernt die Datenbankstruktur, generiert daraus sofort eine REST- und GraphQL-API, und baut eine Admin-Oberfläche, in der Daten verwaltet werden können.
Was Directus nicht tut:
- Keine vordefinierten Datenstrukturen — das Schema kommt aus der eigenen Datenbank
- Kein eigenes Datenbankformat — PostgreSQL, MySQL, SQLite, und mehr
- Kein proprietary Lock-in — Daten liegen in Standard-SQL, exportierbar jederzeit
Warum No-Lock-in so wichtig ist
Einer der grössten Risikofaktoren bei CMS-Entscheidungen ist der Vendor-Lock-in: Wenn man ein bestimmtes System wählt und die Daten dort proprietär gespeichert werden, ist der Wechsel später teuer.
Directus löst das konsequent. Die Daten liegen in einer Standard-Datenbank (z.B. PostgreSQL), die vollständig unter eigener Kontrolle ist. Directus sitzt obendrauf, aber nicht als einzige Zugangsmöglichkeit. Wenn man Directus irgendwann ersetzen will, sind die Daten einfach in der Datenbank — keine Migration, kein proprietäres Format.
Bei einem Projekt im Verlagsbereich war das ein entscheidendes Argument: Das Unternehmen wollte die Flexibilität behalten, das System in fünf Jahren zu wechseln, ohne Daten zu verlieren. Directus on PostgreSQL war die Antwort.
Self-Hosting: Daten unter eigener Kontrolle
Directus kann self-hosted betrieben werden — auf eigenem Server, eigener Cloud-Instanz, oder On-Premise. Für Unternehmen mit strengen Datenschutzanforderungen (z.B. Gesundheitswesen, Finanz, öffentliche Hand) ist das oft nicht verhandelbar.
Die Open-Source-Natur von Directus bedeutet: Keine Lizenzkosten für den Code selbst. Kosten entstehen nur durch Infrastruktur und Hosting.
Typische Hosting-Konfigurationen, die wir einsetzen:
- Directus + PostgreSQL auf einem dedizierten Server (KMU-Projekte)
- Containerisiert via Docker auf eigenem Cloud-Host (Enterprise-Projekte)
- Managed PostgreSQL-Dienst + Directus selbst deployt (hybrides Modell)
Flows und Automations: Logik ohne Code
Directus bietet ein eingebautes Automatisierungs-System namens «Flows». Mit Flows lassen sich datengetriebene Workflows bauen: Wenn ein neuer Datensatz erstellt wird, sende eine E-Mail. Wenn ein Feld geändert wird, aktualisiere einen anderen Datensatz.
Für viele Anwendungsfälle — Content-Workflows, Benachrichtigungen, Daten-Synchronisierungen — reichen Flows ohne eine einzige Zeile Code.
Bei einem Projekt im Eventbereich haben wir Flows eingesetzt, um automatisch Bestätigungs-E-Mails zu senden, Kapazitätsgrenzen zu prüfen, und Wartelisten zu verwalten. Ohne zusätzliche Backend-Logik.
Rollen und Berechtigungen: Granulare Zugriffskontrolle
Directus hat ein ausgefeiltes Rollen- und Berechtigungssystem. Nicht nur «Admin kann alles, Redakteur kann Inhalte bearbeiten» — sondern Berechtigungen auf Feldebene.
Das bedeutet: Eine Rolle kann Zugriff auf bestimmte Collections haben, aber nur auf bestimmte Felder, und nur lesend, nicht schreibend. Das ermöglicht komplexe Szenarien ohne massiven Implementierungsaufwand.
Für datengetriebene Projekte mit mehreren Systemakteuren (API-Clients, Admin-User, externe Partner) ist granulare Zugriffskontrolle oft kritisch. Directus löst das aussergewöhnlich gut.
Wann wir Directus einsetzen vs. Sanity
Die Entscheidung zwischen Directus und Sanity hängt von der Natur des Projekts ab:
Sanity wählen wir für:
- Inhalts-getriebene Projekte (Website-Content, Blogs, Marketing)
- Strukturierte Inhalte mit Rich Text, Referenzen, Medien
- Projekte, wo Redakteurskomfort im Vordergrund steht
Directus wählen wir für:
- Daten-getriebene Projekte (Verwaltungssysteme, APIs, Produktdaten)
- Projekte mit bestehenden Datenstrukturen oder SQL-Datenbanken
- Strenge Datenschutzanforderungen (Self-Hosting Pflicht)
- Projekte, die multiple Systeme integrieren müssen
Das bringt dir Directus.io konkret
- **Volle Datenkontrolle:** Standard-SQL, kein proprietary Format, jederzeit exportierbar
- **Kein Lock-in:** Wechseln ohne Datenmigration immer möglich
- **Automatische API:** REST + GraphQL ohne Aufwand aus jeder Datenbank
- **Self-Hosting:** DSGVO-konform, eigene Infrastruktur, keine Cloud-Abhängigkeit
- **Granulare Rechte:** Zugriff auf Feld-Ebene steuerbar
- **Open Source:** Keine Lizenzkosten, aktive Community, langfristig sicher