Selbsthost – Erste Schritte

Diese Anleitung führt Sie von einem leeren Server zu einem laufenden Kanera, bei dem Sie sich anmelden können.

Es deckt die Teile ab, die jede Bereitstellung benötigt: Anforderungen, Kapazität, die Umgebungsdatei, das Starten des Stacks und die Bestätigung, dass er funktioniert. Optionale Teile – die öffentliche API, MCP, E-Mail, Speicher und Backups – haben jeweils ihre eigene Seite, die am Ende verlinkt ist.

Anforderungen

Sie benötigen:

• Ein Server mit Docker und Docker Compose.
• Eine Domäne, die auf den Server zeigt.
• HTTPS vor Kanera, normalerweise über Caddy, Traefik, Nginx oder einen Cloud-Load-Balancer.
• SMTP-Anmeldeinformationen, wenn Kanera E-Mails senden soll.
• Ein Plan zum Sichern von PostgreSQL-Daten und hochgeladenen Dateien.

Planungskapazität

Kanera ist im Kleinteammaßstab ein Leichtgewicht. Seine Compose-Datei legt keine harten CPU- oder Speichergrenzen fest und der Migrationsdienst wird nach dem Start beendet. Der Standard-Stack führt PostgreSQL, Valkey, zwei API-Replikate, einen Worker, die öffentliche API, MCP und Nginx aus.

Verwenden Sie diese als Ausgangspunkte und messen Sie dann Ihre eigenen gleichzeitigen Aktivitäten, Dateien, Integrationen und Ihr Backup-Fenster:

Typisches Team	Startkapazität	Lokale Festplatte	Notizen
Persönlich oder leicht genutzt	1 vCPU, 1 GiB RAM	10 GiB	Benutzen API_REPLICAS=1 und lassen Sie das optionale Überwachungsprofil ausgeschaltet.
1 bis 25 aktive Benutzer	1–2 vCPU, 2 GiB RAM	20 GiB	Bequem für normale Board-Aktivitäten, Benachrichtigungen und leichte Integrationen.
26 bis 100 aktive Benutzer	2–4 vCPU, 4 GiB RAM	40 GiB	Fügt Spielraum für gleichzeitige Aktivitäten, Uploads, API-Verkehr, Webhooks und Datenbank-Cache hinzu.
Mehr als 100 aktive Benutzer	4+ vCPU, 8+ GiB RAM	80+ GiB	Führen Sie vor dem Start einen Belastungstest mit repräsentativen Daten durch, skalieren Sie dann API-Replikate und optimieren Sie PostgreSQL anhand der beobachteten Nutzung.

Hierbei handelt es sich um Planungsgrundlagen, nicht um feste Benutzergrenzen oder gemessene Kapazitätsgarantien. Die gleichzeitige Aktivität ist wichtiger als die Anzahl der registrierten Konten. Dateivolumen und -speicherung erhöhen in der Regel den Festplattenbedarf stärker als Kanera selbst. Bewahren Sie Datenbank- und hochgeladene Dateisicherungen außerhalb der primären Festplatte des Servers auf und warnen Sie bei Festplattenwachstum.

Das optionale Überwachungsprofil Prometheus, Grafana, Loki, Alloy und Exporter fügt mehrere Prozesse hinzu. Der Bereitstellungsleitfaden schätzt etwa 0,7 bis 1,5 GiB zusätzlichen Speichers, abhängig vom Protokollvolumen und der Dashboard-Nutzung. Budgetieren Sie dies separat oder führen Sie die Überwachung auf einem anderen Host aus.

Was die einzelnen Dienste tun und welche verfügbar gemacht werden sollen, erfahren Sie unter Dienste und Routing.

Laden Sie Kanera herunter

Kanera wird als vorgefertigte Docker-Images geliefert. Jeder freigeben Enthält eine betriebsbereite Version docker-compose.yml Dadurch werden sie abgerufen, sodass Sie das Repository nicht klonen oder etwas erstellen müssen.

Erstellen Sie auf dem Server ein Verzeichnis für Kanera und laden Sie die Compose-Datei und die Beispielumgebungsdatei aus der neuesten Version herunter:

mkdir kanera && cd kanera
curl -fsSLo docker-compose.yml https://github.com/happendev/Kanera/releases/latest/download/docker-compose.yml
curl -fsSLo .env https://github.com/happendev/Kanera/releases/latest/download/env.example

Die Compose-Datei heftet jedes Bild an diese Version, sodass sich bis zu Ihnen nichts ändert aktualisieren. Es benötigt Docker Compose 2.23 oder neuer (docker compose version).

Konfigurieren Sie die Umgebungsdatei

Offen .env und ersetzen Sie jeden Platzhalter. Legen Sie die erforderlichen Produktionswerte fest:

WEB_ORIGIN=https://kanera.example.com
COOKIE_DOMAIN=kanera.example.com
COOKIE_SECURE=true
KANERA_ENVIRONMENT=production

POSTGRES_PASSWORD=<openssl rand -hex 32>
JWT_SECRET=<openssl rand -hex 32>
MCP_INTERNAL_SECRET=<openssl rand -hex 32>
MFA_ENCRYPTION_KEY=<openssl rand -hex 32>
MEDIA_SIGNING_SECRET=<openssl rand -hex 32>
SECRETS_ENCRYPTION_KEY=<openssl rand -hex 32>

Halten Sie diese Geheimnisse bei erneuten Bereitstellungen stabil. Verändern JWT_SECRET meldet Benutzer ab. Verändern MFA_ENCRYPTION_KEY macht registrierte Authentifikatoren und MFA-Herausforderungen ungültig. Verändern MEDIA_SIGNING_SECRET macht vorhandene signierte Medien-URLs ungültig. MCP_INTERNAL_SECRET authentifiziert den MCP-Dienst gegenüber der API. SECRETS_ENCRYPTION_KEY schützt gespeicherte Integrationsgeheimnisse und sollte sich von unterscheiden JWT_SECRET.

Der selbstgehostete Modus ist die Standardeinstellung:

KANERA_DEPLOYMENT_MODE=self_hosted

Legen Sie keine gehosteten Stripe-Abrechnungsvariablen fest, es sei denn, Sie führen eine gehostete Bereitstellung im Kanera SaaS-Stil aus.

Siehe Umgebungsreferenz für Produktionseinstellungen und env.full.example für jeden optionalen Tuning-Wert und Standard.

Starten Sie Kanera

docker compose up -d

Docker ruft die Bilder ab, dann richtet der Migrationsdienst die Datenbank einmalig ein api, worker, und public-api beginnen. Der MCP-Dienst wird gestartet, nachdem die Integritätsprüfung der öffentlichen API bestanden wurde.

Überprüfen Sie die Bereitstellung

Öffnen Sie Ihre Webdomain in einem Browser:

https://kanera.example.com

Nützliche Kontrollen:

docker compose ps
docker compose logs -f api
docker compose logs -f worker
docker compose logs -f public-api
docker compose logs -f mcp

Gesundheitschecks:

curl https://kanera.example.com/api/health
curl https://api.kanera.example.com/health
curl https://mcp.kanera.example.com/health

Die öffentlichen API- und MCP-Prüfungen gelten nur, wenn diese Dienste verfügbar sind.

Wenn etwas nicht klappt, arbeiten Sie es durch Häufige Probleme in der Reihenfolge und nicht nach Symptomen.

Konfigurieren Sie, was Sie brauchen

Um sich anzumelden und Foren zu nutzen, ist nichts weiter unten erforderlich. Fügen Sie jedes Stück hinzu, wann Sie es möchten:

Seite	Abdeckungen
Umgebungsreferenz	Erforderliche Geheimnisse, öffentliche URLs, Zugriffsrichtlinien, Speicher, Übermittlung, Skalierung, Aufbewahrung, Überwachung und Administratoreinstellungen.
Dienste und Routing	Was jeder Dienst tut, empfohlene Domänen, Veröffentlichungsports und Reverse-Proxy-Vertrauen.
E-Mail und Benachrichtigungen	SMTP, Browser-Push, persönliche NTFY-/Gotify-/Webhook-Ziele und Chat-Ziele.
Integrationen und APIs	Offenlegung der öffentlichen API und des MCP, OAuth für KI-Agenten und Kopieren von Trello-Anhängen.
Speicherung und Backups	Lokaler oder S3-Upload-Speicher, Datenbank- und Dateisicherungen und die Geheimnisse, die es zu bewahren gilt.
Updates und Skalierung	Aktualisierung auf eine neue Version und Replikatanzahl.

Die durch die Implementierung unterstützte Bereitstellungsreferenz finden Sie unter DEPLOY.md im Kanera-Repository.