Input: Gemeinsam Machen 6
Jonas Stettner | CorrelAid @ CDL
2026-04-30
Entwicklung von Deployment
viel vor in wenig Zeit, man mus nicht alles verstehen: wir teilen uns gleich in zwei gruppen auf nach erfahrungslevel
versuch beide gruppen zu bedienen und versuch raum zu öffnen für den gesamten Umfang von Deployment und was für Begriffe/Technologien hier eine Rolle spielen,
auf ein paar Aspekte detalierter am Beispiel von CorrelAid eingehen
eine Lösung für viele der Probleme: Coolify vorstellen
wie viele bestimmt wissen, wurde das world wide web um 1990 am CERN erfunden
hier sind man den ersten web server:
web server = software die anfragen von user agents akzeptiert und eine antwort zurückschickt
von statischen html Dateien bis zu von Large Language Models generierten Texten
ersteres benötigt wesentlich weniger Energie als letzteres (Atomreaktoren), aber gleiches Prinzip
Arbeit/Anwendungen werden immer web/cloud-basierter, Beispiel Office-Programme
Was ist Deployment?
Self-Hosting von Open Source
Self-Hosting: Verantwortung liegt bei einem selbst, Anwendung liegt in eigener Einflussphäre
Beispiel: Self-Hosting von Nextcloud oder OpenProject
Deployment von eigenem Code
Kann über Self-Hosting geschehen
PaaS-Anbieter (Platform as a Service, z.B. Vercel ; Heroku )
Beispiel: Diese Präsentation ist deployed über GitHub Pages (als static website)
Bezug auf Anwendungen, die auf Servern laufen und über das Internet erreichbar sind
Umfang von Deployment: Infrastruktur
Wo läuft die Anwendung?
Unterschiedliche Abstraktionslevel:
Server im Keller (On Premises)
Server bei einem Cloud Provider gemietet (oft VPS: Virtual Private Server)
PaaS/CaaS (Platform bzw. Container as a Service)
Je nach Wahl: man ist selbst verantwortlich für das Betriebssystem
(OS Administration, z.B. Linux-Distribution wie Debian )
Wie ist die Anwendung erreichbar?
Eine lesbare Adresse (z.B. civic-data.de) muss mit der
Server-IP verknüpft werden → DNS Management
Analogie DNS: wie ein Telefonbuch – Name rein, Nummer raus
Umfang von Deployment: Updates & Wartung
Deployment ist eine kontinuierliche Tätigkeit
Wie halte ich alles aktuell?
Die Anwendung selbst: neue Features, Bugfixes
Das Betriebssystem und Requirements: Sicherheitslücken werden
regelmäßig geschlossen
Umfang von Deployment: Monitoring
Merke ich, wenn etwas schiefläuft?
Ist die Anwendung noch erreichbar? → Uptime Monitoring
Werden CPU, RAM oder Speicher knapp? → Ressourcen-Monitoring
➡️ Notifications (z.B. E-Mail wenn correlaid.org down ist)
Ohne Monitoring erfährt man von Ausfällen oft erst durch Nutzende
Frühwarnung verhindert, dass kleine Probleme große werden
Umfang von Deployment: Sicherheit & Datenschutz
Wer darf auf die Anwendung zugreifen?
Unerwünschten Traffic blockieren → Firewalls
Klare Regeln, wer sich einloggen kann → Access Management
Was bedeutet das für den Datenschutz?
Wo werden Daten gespeichert? (EU vs. USA)
Wer hat theoretisch Zugriff auf die Daten?
ggf. spezielle Verträge mit Cloud Providern notwendig
ggf. Zertifizierungen notwendig
Deployment bei CorrelAid
Ein paar der genannten Aspekte detailiert besprechen und am Beispiel von CorrelAid
Wo deploye ich? - Cloud Provider
“Ich will mir keinen Server in den Keller stellen.” ➡️ Cloud Provider
Viele Cloud Provider bieten auch DNS Management, Firewalls und PaaS-Lösungen an
Die großen drei: AWS (Amazon Web Services), Azure , GCP (Google Cloud Platform)
Europäische Provider: z.B. Hetzner , Scaleway , Netcup
Tipp: lowendbox.com
Man kann manche Dinge auf VPS (Virtual Private Server) mit 1 VCPU/1 GB RAM für ~2$/Monat laufen lassen
➡️ CorrelAid nutzt hauptsächlich Hetzner
Exkurs: Infrastructure as Code (IaC)
Kernidee: Infrastruktur als Code beschreiben statt manuell klicken.
Reproduzierbar – gleiche Umgebung, überall
Nachvollziehbar – versionierbar via Git
Plattformunabhängig – AWS, Hetzner, DigitalOcean & Co.
Terraform / OpenTofu
Was soll existieren?
Ansible
Wie soll es konfiguriert sein?
➡️ CorrelAid nutzt OpenTofu + Ansible
Exkurs: Was sind Container?
Heutzutage laufen Anwendungen meistens in Containern statt direkt auf dem Server.
Vorteil: eine containerisierte Anwendung läuft auf jedem Betriebssystem gleich
Kein “bei mir läuft das aber” — die Umgebung ist immer identisch
Docker ist das verbreitetste Tool: man beschreibt die Umgebung
einmal in einem Image , der Container läuft überall
Image = Bauplan, Container = laufende Instanz davon
Exkurs: Container Orchestration
Wenn eine Anwendung aus mehreren Containern besteht
(z.B. App + Datenbank + Cache), oder High Availability wichtig ist, braucht man ein Tool das sie (über mehrere Server) zusammenhält und ihren Lebenszyklus administriert.
Docker Compose
Mehrere Container auf einem Server
✅ CorrelAid
Kubernetes
Hunderte (replizierte) Container auf mehreren Servern
Overkill für NPOs
Kubernetes: riesiger Operationsaufwand, lohnt sich erst ab sehr großer Skalierung
Docker Compose: eine YAML-Datei beschreibt alle Container und wie sie kommunizieren
Coolify als PaaS
➡️ CorrelAid nutzt Coolify als PaaS
Früher Vercel als PaaS für Website und OpenTofu/Ansible managed Docker Compose auf VPS
Vor Kurzem Umstieg auf Coolify (self-hosted)
Freie Auswahl von Cloud Providern (Standort)
Alles unter eigener Kontrolle, aber trotzdem Komplettlösung mit Best Practices
Keine Abhängigkeit von externen Anbietern und Features, für die man extra bezahlen muss
Coolify: Server-Management
Coolify Server
Features
Reverse Proxy (https)
Automatisierte OS Updates
Metrics
Coolify: Anwendungen
Coolify Application
Features
Verschieden Deployment-Modi: Docker Compose, Nixpacks und mehr
Verknüpfung mit GitHub Repositories mit Rolling Updates
Basic Auth: Passwortgeschützte Anwendungen