Loomio selbst hosten: Der Weg von loomio.example.com zur laufenden Instanz
Loomio ist ein Tool zur kollaborativen Entscheidungsfindung. Loomio ist ein Entscheidungsfindungstool für kollaborative Organisationen.
Auf einen Blick
- Was ist das?
- Eine Analyse der Bereitstellung von Loomio auf einem einzelnen Ubuntu-Server mit Docker Compose, inklusive DNS-Vorbereitung, Geheimnissen, SMTP und Admin-Zugang.
- Für wen ist es gedacht?
- Loomio eignet sich für Organisationen, die Abstimmungen und Beschlüsse unter eigener Kontrolle abwickeln wollen und bereit sind, einen Server mit Docker, DNS-Einträgen und SMTP-Zugang zu pflegen. Wer keine eigene Mail-Zustellung aufbauen möchte, sollte vorab einen Anbieter wie SendGrid oder Mailgun wählen und prüfen, ob AGPL-3.0 zum eigenen Nutzungsszenario passt.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Ruby, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Loomio als Entscheidungsfindungswerkzeug für kollaborative Organisationen
Loomio ist ein Ruby-Projekt, das sich selbst als Entscheidungsfindungswerkzeug für kollaborative Organisationen beschreibt. Das Repository loomio/loomio zählt rund 2600 Sterne und 700 Forks, der master-Zweig wurde Ende August 2026 zuletzt aktualisiert. Aktuelle Releases erscheinen in kurzen Abständen: v3.4.0, v3.4.1 und v3.4.2 folgten innerhalb von drei Tagen, was auf eine aktive Wartung hinweist.
Wer das Werkzeug kennenlernen möchte, wird im README auf Loomio.com verwiesen, wo eine gehostete Variante erreichbar ist. Für den eigenen Betrieb liefert das Repository einen Deployment-Leitfaden unter deploy/README.md, für die Entwicklungsumgebung ein eigenes Dokument namens DEVSETUP.md. Die Co-op-Gruppe hinter dem Projekt dokumentiert ihre Arbeitsweise öffentlich im loomio-coop-handbook, ein ungewöhnlich transparenter Ansatz.
Voraussetzungen für das Self-Hosting auf einem einzelnen Server
Das deploy/README beschreibt den Betrieb auf einem einzelnen Server mit Docker Compose. Vorausgesetzt werden Root-Zugriff, eine öffentliche IP-Adresse, das aktuelle Ubuntu LTS, mindestens 1 GB RAM, ein Domänenname und ein SMTP-Server. TLS-Zertifikate werden über Let's Encrypt automatisch ausgestellt, der Betreiber muss dafür keine Zertifikatskette selbst verwalten.
Der Leitfaden benutzt durchgehend den Beispiel-Hostnamen loomio.example.com und die Beispiel-IP 192.0.2.1. Wer die Schritte nachvollziehen will, ersetzt diese Werte durch die eigenen. Ein separates Vorgehen für Container-Plattformen oder Kubernetes wird im README nicht beschrieben; der Umfang bleibt bewusst auf den Ein-Server-Fall begrenzt.
DNS-Einträge: A-, MX- und CNAME-Record vorbereiten
Bevor Docker ins Spiel kommt, verlangt der Leitfaden drei DNS-Einträge. Ein A-Record zeigt den Hostnamen auf die Server-IP, etwa loomio.example.com auf 192.0.2.1. Ein MX-Record ist nötig, damit die E-Mail-Antwortfunktion funktioniert, mit der Teilnehmer direkt per Mail auf Diskussionen reagieren können.
Zusätzlich verlangt das Setup einen CNAME-Record für den kollaborativen Bearbeitungsserver unter hocuspocus.loomio.example.com. Ohne diesen Eintrag fehlt die Live-Bearbeitung, die Loomio im Browser anbietet. Weitere Netzwerkkonfiguration wie Firewalls oder Reverse-Proxy-Optionen bespricht das README nicht; nginx kommt über die Compose-Definition mit, wie sich beim Fehlerbild 503 zeigt, das auftritt, wenn nginx vor dem Rails-Server bereitsteht.
Docker installieren und Konfigurationsdateien aus dem deploy-Verzeichnis holen
Die Servervorbereitung beginnt mit dem SSH-Login als Root. Für die Docker-Installation übernimmt der Leitfaden die Befehle von docs.docker.com: der offizielle GPG-Schlüssel, das apt-Repository und die Pakete docker-ce, containerd und compose-plugin. Damit läuft die Umgebung genauso wie in der offiziellen Docker-Dokumentation beschrieben.
Danach wird ein Bereitstellungsverzeichnis angelegt, und die beiden zentralen Dateien docker-compose.yml und env_template werden aus dem deploy-Verzeichnis des Repositorys heruntergeladen. Die Umgebungsvorlage wird mit eingeschränkten Rechten 600 nach .env kopiert, damit Zugangsdaten nicht für andere Systemnutzer lesbar sind. Diese Rechtevergabe ist der erste sicherheitsrelevante Schritt, bevor irgendein Container startet.
Geheimnisse generieren und SMTP-Zugang in der .env-Datei hinterlegen
Für die Geheimnisse führt der Leitfaden einen Einzeiler aus, der gegen das Loomio-Image läuft und Zufallswerte für POSTGRES_PASSWORD, DEVISE_SECRET, SECRET_COOKIE_TOKEN und RAILS_INBOUND_EMAIL_PASSWORD ausgibt. In der .env-Datei müssen anschließend alle REPLACE_WITH-Ausdrücke ersetzt werden, einschließlich eines passenden PostgreSQL-Passworts in DATABASE_URL. Die Vorlage dokumentiert zudem optionale Einstellungen für SSO, Themes und Dateispeicher, die je nach Bedarf aktiviert werden.
Der SMTP-Server bleibt Sache des Betreibers. Das README nennt Dienste wie SendGrid, SparkPost, Mailgun und Mailjet oder das Self-Hosting mit Haraka als Optionen. Die SMTP-Zugangsdaten wandern ebenfalls in die .env. Außerdem kann ein SPF-DNS-Eintrag nötig sein, damit der Server E-Mails im Namen der Domäne versenden darf. Wer diesen Punkt überspringt, riskiert, dass Einladungs- und Benachrichtigungsmails im Spam landen.
Datenbank initialisieren, Dienste starten und Logs beobachten
Mit vollständiger .env folgt die Datenbankinitialisierung in zwei Befehlen: `docker compose up -d db` startet die Datenbank, `docker compose run --rm app rake db:setup` legt das Schema an. Erst danach bringt `docker compose up -d` das volle Set hoch: Datenbank, Rails-Anwendung, den E-Mail-Antwortdienst und die Live-Update-Dienste.
Die Logs lassen sich mit `docker compose logs -f` verfolgen. Nützlich zu wissen: Ein 503-Fehler beim ersten Aufruf kann auftreten, wenn nginx vor dem Rails-Server startet, und verschwindet, sobald die Anwendung bereit ist. Nach jeder Änderung an env-Dateien startet der Leitfaden mit `docker compose down` und anschließendem `docker compose up -d` neu, damit die Werte übernommen werden.
Adminrechte per Rails-Runner vergeben und Updates mit UPGRADING.md planen
Die erste Registrierung läuft über die normale Anmeldung und E-Mail-Bestätigung. Administratorrechte vergibt der Betreiber danach per Rails-Runner-Befehl, der das is_admin-Flag des letzten Benutzers setzt; die Admin-Oberfläche liegt dann unter /admin. Bei Fehlern empfiehlt der Leitfaden, zuerst die Logs zu prüfen und bei Bedarf eine Anfrage an das Team zu senden. Für Benachrichtigungen lässt sich Sentry konfigurieren.
Updates laufen über `docker compose pull` und `docker compose up -d`; das Image-Tag folgt dem neuesten Patch-Release seiner Release-Serie. Vor einem Sprung auf eine neuere Neben- oder Hauptversion sollte UPGRADING.md gelesen werden, das Hinweise zu Migrationen sammelt. Die Repository-Metadaten listen AGPL-3.0 als Lizenz, was Netzwerk-Nutzung mit Quelloffenlegung verknüpft; das README selbst geht darauf nicht ein, Betreiber sollten den Lizenztext daher direkt gegen ihre Nutzungsszenarien prüfen. Bug-Meldungen und Beiträge laufen über GitHub-Issues, Kontakt gibt es per E-Mail oder auf BlueSky.
Redaktionelles Fazit
Loomio eignet sich für Organisationen, die Abstimmungen und Beschlüsse unter eigener Kontrolle abwickeln wollen und bereit sind, einen Server mit Docker, DNS-Einträgen und SMTP-Zugang zu pflegen. Wer keine eigene Mail-Zustellung aufbauen möchte, sollte vorab einen Anbieter wie SendGrid oder Mailgun wählen und prüfen, ob AGPL-3.0 zum eigenen Nutzungsszenario passt.
Community-Notizen