Genau darum ging es beim sechsten „Gemeinsam Machen” des Civic Data Lab am Donnerstag, 30. April 2026. Rund 27 Teilnehmende aus verschiedenen zivilgesellschaftlichen Organisationen kamen zusammen, um sich zu einem Thema auszutauschen, das oft im Hintergrund bleibt, aber entscheidenden Einfluss auf gemeinwohlorientierte digitale Projekte hat: SoftwareSoftwareWährend Hardware die physischen Bestandteile eines Computers beschreibt, wie zum Beispiel eine Festplatte, wird der Begriff Software für die Programme eines Computers verwendet, die ihn funktionsfähig machen, wie zum Beispiel das Betriebssystem.-DeploymentDeploymentDeployment bezeichnet den Schritt, in dem eine entwickelte Software – zum Beispiel eine Website, ein Machine-Learning-Modell oder ein Chatbot – so bereitgestellt wird, dass sie tatsächlich genutzt werden kann. Im Gegensatz zur einfachen Installation von Standardsoftware (wie z.B. eines Textverarbeitungsprogramms) ist das Deployment eigener Software in der Regel kein einmaliger Klick, sondern ein mehrstufiger Prozess. Dies gilt insbesondere dann, wenn mehrere Personen beteiligt sind, verschiedene Testphasen notwendig sind oder ein stabiler und fehlerfreier Betrieb sichergestellt werden muss. Heutzutage wird dieser Prozess häufig so weit wie möglich automatisiert, um Deployments einfacher, weniger fehleranfällig und häufiger durchführen zu können (siehe DevOps)..
Unter Deployment versteht man die Bereitstellung von Software: alles, was nötig ist, damit Open-Source Software selbst gehostet werden kann oder eigener Code für andere Nutzer*innen erreichbar und funktionsfähig ist. Im Gegensatz zur einfachen Installation von Standardsoftware ist das Deployment eigener Anwendungen ein mehrstufiger Prozess – von der lokalen Entwicklungsumgebung über eine Testumgebung (Staging) bis hin zur öffentlich zugänglichen Produktionsumgebung. Wer mehr zu den Grundlagen erfahren möchte, findet eine ausführliche Erklärung in unserer Lernlandkarte Datenmanagement.
Jonas aus dem CDL Team führte mit einer Präsentation für alle Teilnehmenden in die zentralen Begriffe ein, um Verständnis für die verschiedenen Formen von Deployment über Self-HostingHostingHosting bezeichnet die Bereitstellung und den Betrieb von IT-Infrastruktur und Rechenressourcen, um Websites, WebApps, Datenbanken und andere Anwendungen zugänglich zu machen. Hierfür werden meistens Server verwendet. Beim Self-Hosting (de: selbst hosten, Eigenhosting) betreibt und wartet man selbst nötige Infrastruktur und Anwendungen. Beim Managed Hosting übernimmt ein externer Anbieter den Betrieb und die Wartung der Infrastruktur und Anwendungen. Unabhängig davon, wer das Hosting übernimmt, spielt auch das “Wo” eine Rolle – die benötigten Rechenressourcen können entweder in der Cloud liegen (Cloud Computing, z.B. ein virtueller Server) oder physisch vor Ort sein (“on premise”, z.B. Server in einem eigenen Data-Center oder in einem separaten Raum im Büro). Mit der zunehmenden Verfügbarkeit von Cloud Computing und damit verbundenen Geschäftsmodellen nimmt der Anteil von Hosting in der Cloud in den letzten Jahren stetig zu. in der Cloud oder On-Premise zu schaffen, aber auch über Platform oder Container as a Service (PaaS/CaaS). Da man Deployment als kontinuierliche Tätigkeit sehen sollte, müssen auch Aspekte wie Updates und Wartung, Sicherheit und DatenschutzDatenschutzDatenschutz beschreibt Maßnahmen zum Schutz personenbezogener Daten vor Missbrauch, unbefugtem Zugriff und Verlust. Er umfasst Gesetze, Richtlinien und Techniken, die Organisationen verpflichten, personenbezogene Daten sicher zu verwalten. Datenschutz ist entscheidend, um das Vertrauen der Öffentlichkeit zu wahren und die Rechte Einzelner zu schützen. sowie kontinuierliches Monitoring zum Aufdecken von Fehlern und Lücken beachtet werden.
Jonas führte auch ein in Infrastructure as Code (IaC) als Ansatz, Infrastruktur reproduzierbar als Code zu beschreiben statt manuell zu konfigurieren; Container-Technologien wie Docker, die Anwendungen plattformunabhängig machen; und Coolify als Self-Hosting-Plattform (hier lang zur kurzen Erklärung), die viele dieser Konzepte für Nicht-Infrastrukturexpert*innen bündelt. Coolify erlaubt es, Anwendungen auf selbst gewählten Servern – z. B. bei europäischen Anbietern wie Hetzner – zu betreiben, ohne von kommerziellen SaaS-Angeboten abhängig zu sein. Ein praktisches Vorbild liefert CorrelAid (mehr dazu im CorrelAid-Blogbeitrag). Der Vortrag zeigte: Deployment kann viele Formen annehmen.
Track 1 sammelte zunächst, welche Deployment-Szenarien in zivilgesellschaftlichen Organisationen immer wieder auftauchen: eigenen Code deployen, Open-Source-Software self-hosten, Datenbanken betreiben, Reporting-Infrastruktur wie Dashboards aufbauen. Bei den genutzten Tech-Stacks zeigte sich eine bunte Mischung von niedrigem bis hohem Abstraktionslevel. Die Tools, Dienste und Konzepte, die hierbei zusammengetragen worden sind, haben wir um Begriffserklärungen angereichert und nach Kategorien sortiert hier als Handreichung für Euch aufbereitet: https://staging.civic-data.de/machen/deployment/.
Aus der Diskussion kristallisierten sich wiederkehrende Herausforderungen heraus:
Wartbarkeit als unterschätzter Faktor: Was heute gebaut wird, muss morgen noch verstanden und gepflegt werden können. Das gilt besonders dann, wenn KI-Unterstützung bei der Entwicklung genutzt wurde. Die Empfehlung der Gruppe ist es hier, auf zu große Tech Stacks zu verzichten und Tools zu verwenden, die auf Einfachheit ausgelegt sind, z.B. DuckDB für lokale Datenanalysen (hier lang zur kurzen Erklärung).
In diesem Zusammenhang ist fehlende Kontinuität in vielen Organisationen ein Problem: Häufig hängen Tech-Projekte an den Kompetenzen einzelner beruflich oder ehrenamtlich Engagierter. Wenn diese die Organisation verlassen, können ihre Infrastrukturen und Outputs nicht mehr ohne Einschränkungen gewartet und am Leben gehalten werden.
Sicherheit wurde als eines der dringlichsten Themen genannt, für das Vorwissen erforderlich ist. Angriffe auf Websites können ständig passieren und die Automatisierungsmöglichkeiten verschärfen dies. Einer der Teilnehmenden berichtete von konkreten Erfahrungen: Fake-Anmeldungen aus dem Ausland, ein Virus in WordPress, der nur beim Zugriff über Google auftauchte – und Google sperrte die Website daraufhin. Die Gruppe war sich einig: Sicherheit muss von Anfang an mitgedacht werden, auch beim Prototyp. Vor einem Go-Live sollte mindestens eine AuthentifizierungAuthentifizierungAuthentifizierung ist der Prozess, bei dem überprüft wird, ob eine Person, ein System oder eine Maschine tatsächlich die angegebene Identität besitzt. Das kann zum Beispiel die Überprüfung eines Passwortes zu einem angegebenen Benutzernamen sein, um sicherzustellen, dass die Person, die sich anmeldet, wirklich zu dem angegebenen Benutzernamen gehört. Grundsätzlich können bei der Authentifizierung unterschiedliche Methoden wie u.a. Passwörter, biometrische Daten oder Zertifikate zum Einsatz kommen. Die Authentifizierung eines Nutzers ist nur einer der drei Schritte, die bei einer Anmeldung eines Nutzers in einem System aus Sicht der Informationssicherheit ausgeführt werden: Authentisierung: Hier belegt ihr eure Identität, beispielsweise indem ihr euren Benutzernamen und euer Passwort eingebt. Authentifizierung: Das System prüft nun eure angegebene Identität, kontrolliert eure Eingaben und fordert bei Bedarf weitere Nachweise an (etwa bei der Multi-Faktor-Authentifizierung). Autorisierung: Nach erfolgreicher Identitätsprüfung legt das System fest, welche Zugriffsrechte ihr erhaltet - also welche Aktionen ihr im System ausführen dürft und auf welche Informationen ihr zugreifen könnt. eingerichtet und ein klarer Sicherheitsrahmen definiert sein.
KI beim Deployment war ein weiteres Dauerthema. LLM-Tools verändern sich rasant und können schon heute nicht nur dabei helfen, Anwendungen zu erstellen, sondern auch zu ihrem Deployment beraten. Doch die KI übernimmt keine Verantwortung und haftet nicht. Die Gruppe empfahl: KI kann gut bei technischer Syntax und Fehlersuche helfen, sollte aber nie autonom deployen oder Entscheidungen mit Datenschutzrelevanz treffen. Das bedeute auch, dass ein Verständnis der vorherrschenden Deployment-Architektur essenziell ist. Hilfreich sei es, die Deployment-Architektur einmal initial zu entwerfen und diesen Rahmen dann als Kontext ins Prompt zu geben. Dies ist auch deshalb die nachhaltigere Variante, da zu erwarten ist, dass größere Rechenoperationen mithilfe von KI-Modellen in Zukunft eher wieder teurer werden.
Diskutiert wurde die Idee, ob ein Civic Data Stack als Minimalinfrastruktur für Daten- und KI-Projekte der Zivilgesellschaft realisierbar und wünschenswert wäre. Es bestünde der große Vorteil, dass Architekturfragen nicht für jede Organisation neu geklärt werden müssten. Denkbar wären Docker für Anmeldeprozesse, Webserver für statische Webseiten sowie eine DatenbankDatenbankEine Datenbank ist ein System zur Speicherung und Verwaltung von Daten. Es handelt sich um eine Softwareanwendung, die strukturierte Daten in Tabellen (Spalten und Zeilen) organisiert und effiziente Abfragen und Transaktionen ermöglicht. Datenbanken werden in zahlreichen Bereichen eingesetzt, um große Mengen an Informationen sicher und zugänglich zu halten., bereitgestellt als Templates mit Infrastructure sowie Configurations as Code. Auf der anderen Seite gibt es bereits Click-and-Go-Lösungen für Dockercontainer, die aber bei der Anwendung schnell an ihre Grenzen kommen, weil die realen Fälle doch einen hohen Grad von Individualisierung erfordern. Eine gemeinsame Infrastruktur würde zwar niedrigschwelliger für die Einzelnen sein, jedoch im Hinblick auf Zugriffsrechte und Datenschutzerfordernisse zu Schwierigkeiten führen.
Das CDL Team teilte Erfahrungen mit Deployment in den kleinen mittelgroßen Datenprojekten, die in den vergangenen zwei Jahren im Rahmen von Datenvorhaben durch das Machen-Team umgesetzt worden sind:
Das Projekt all.txt, ein Online-Texteditor für genderneutrales Schreiben, zeigte exemplarisch, wie komplex Deployment in der Praxis werden kann: Die Entwicklung einer datenbasierten Webanwendung mit Frontend und BackendFrontend und BackendDie Begriffe Frontend und Backend bezeichnen unterschiedliche Bereiche oder Schichten (en: “Layer”) einer Anwendung: Das Frontend ist die Präsentationsebene einer Anwendung, die für die Benutzerin sichtbar ist und mit der sie mithilfe von Bedienelementen wie z.B. Buttons, Menüs oder Formularen interagieren kann. Das Backend ist der Bereich einer Anwendung, die dem Frontend die Logik der Anwendung bereitstellt. Im Backend werden z.B. Daten aus Datenbanken gelesen, Benutzer*innen authentifiziert oder Berechnungen durchgeführt. Frontend und Backend sind besonders bei WebApps relevant. In diesem Fall erfolgt die Kommunikation zwischen Frontend und Backend typischerweise über eine API. sowie die Implementation von DevOpsDevOpsDevOps ist ein Ansatz in der Softwareentwicklung und IT, bei dem die enge Zusammenarbeit zwischen Entwicklung („Development“) und IT-Betrieb („Operations“) im Vordergrund steht. In der klassischen Softwareentwicklung (z.B. Wasserfallmodell) sind Entwicklung und Betrieb meist stark voneinander getrennt und werden oft von unterschiedlichen Abteilungen oder Auftragnehmern durchgeführt. Die Software wird zunächst vollständig entwickelt, abgenommen und anschließend in den Betrieb überführt. Bei DevOps hingegen werden Entwicklung und Betrieb in gemeinsamen, agilen Teams integriert. So ergänzt DevOps agile Methoden, indem der Betrieb stärker in den Entwicklungsprozess eingebunden wird und erste fertige Funktionalitäten schnell an die Nutzer*innen bereitgestellt werden, um frühzeitig Feedback aus der Anwendung zu erhalten. Ziel von DevOps ist es, die Softwarequalität zu erhöhen, Entwicklungszyklen zu verkürzen und Updates schneller bereitzustellen. Zentrale Prinzipien sind die kontinuierliche Integration (Continuous Integration), die kontinuierliche Bereitstellung (Continuous Delivery) und eine weitgehende Automatisierung (siehe auch CI/CD).-Praktiken wie CI/CDCI/CDCI/CD beschreibt einen automatisierten Prozess in der Softwareentwicklung, bei dem neue Änderungen der Software regelmäßig zusammengeführt (continuous integration), getestet und den Nutzer*innen der Software bereitgestellt (continuous deployment) werden. CI/CD ist eng mit dem Konzept des Deployments verknüpft, da es diesen letzten Schritt der Entwicklung einer Software - die Bereitstellung der Software für die Nutzer*innen - stark vereinfacht und durch Automatisierung beschleunigt. Als Teil des DevOps-Ansatzes trägt CI/CD dazu bei, Software schneller, zuverlässiger und mit weniger manueller Arbeit in Betrieb zu nehmen. Während DevOps der übergeordnete Ansatz ist, der Entwicklung und Betrieb zusammenbringt, beschreibt C/CD die konkreten Prozesse und Werkzeuge, mit denen dieser kontinuierliche Fluss von Änderungen automatisiert wird. Die folgende Grafik zeigt den grundsätzlichen Ablauf eines CI/CD Prozesses: und Infrastructure as Code sind gut lösbare Probleme – aber sie erfordern Grundverständnis und praktische Kompetenz. Wissenstransfer und Dokumentation sind hier essenziell.
Beim Datenvorhaben mit dem Jugendmusikprojekt TEN SING ging es um ein wiederkehrendes Deployment-Problem: Die jährliche Erhebung unter Ehrenamtlichen ließ sich ohne externe Ressourcen und Unterstützung kaum aufrechterhalten. Besonders die Anforderung „Serverstandort in Deutschland” aus dem Kirchlichen Datenschutzgesetz erwies sich als Ko-Kriterium, das viele niedrigschwellige SaaS-Lösungen aus dem Rennen nahm.
Ein weiterer Use Case: Ein RAGRAGRetrieval-Augmented Generation (RAG) ist eine Erweiterung von Large Language Models (LLMs). Das Prinzip von RAG ist, dass zusätzliche Informationen aus einer Wissensdatenbank in die Text-Anfrage (en: Prompt) an eine generative KI einbezogen werden. Dadurch entsteht eine Lösung, die deutlich flexibler und aktueller ist als ein reines Sprachmodell. Die beiden Phasen des RAG Systems sind: “Retrieval” (de: Abruf): Ein Modell oder Algorithmus durchsucht externe Quellen (z. B. Datenbanken, Websites, Textsammlungen), um relevante Informationen zu einer Anfrage zu finden. “Augmented Generation” (de: erweiterte Erzeugung): Ein Generatives KI Modell nutzt sowohl erlerntes Wissen als auch die abgerufenen Informationen, um eine passende Antwort oder einen Text zu verfassen.-ChatbotChatbotEin Chatbot ist eine Software, die textbasierte oder gesprochene Kommunikation über ein Eingabe- und Ausgabefeld ermöglicht.. Es handelt sich um ein Teilgebiet der Künstlichen Intelligenz, in dem Methoden entwickelt werden, um automatisierte Dialogsysteme zu erstellen. Im öffentlichen Diskurs steht der Begriff meist für Anwendungen in Kommunikationskanälen wie Webseiten und sozialen Medien, um Kundensupport zu bieten und Anfragen zu beantworten. Ein Beispiel ist die Möglichkeit der Stornierung von Online-Bestellungen über einen Chatbot., der Schüler*innen, Lehrkräfte und Begleitpersonen von Schüler*innenvertretungen über Mitbestimmung informiert. Die Datenbasis bestimmt dabei maßgeblich, was der Chatbot leisten kann – und die Frage, wo dieser sicher deployed wird, ist keine technische Nebensache. Sie wurde im Datenvorhaben mit Schule ein Gesicht geben bearbeitet.
Auf dem gemeinsamen Miro-Board wurde sichtbar, wie unterschiedlich die Ausgangssituationen sind: Manche Organisationen erstellen Berichte noch vollständig manuell, andere experimentieren bereits mit Tools wie Tally. Fragen nach einer Roadmap für die nächsten fünf Jahre und einem passenden Tech-Stack standen im Raum – und machten deutlich, wie dringend orientierungsgebende Ressourcen gebraucht werden.
Aus beiden Tracks entstanden konkrete Wünsche und Ideen, die in unterschiedlichen Kontexten nachverfolgt werden:
Deployment ist kein Selbstzweck. Es geht darum, dass digitale Lösungen zuverlässig, sicher und langfristig nutzbar sind – auch wenn Projektförderzyklen enden. Die Veranstaltung zeigte: Das ist mit den richtigen Werkzeugen und etwas strukturiertem Wissen auch für Organisationen ohne große IT-Abteilung machbar.
Das Civic Data Lab möchte hier weiter unterstützen – ob durch Ressourcen, Austauschformate oder konkrete Beratung. Habt Ihr Bedarfe oder Fragen rund ums Deployment? Meldet Euch gerne in unserer Community!
Datenteam und Kommunikation angela.berger@caritas.de Kontakt in HumHub
Kommunikation stephanie.agethen@caritas.de Kontakt in HumHub
