Docker Compose Schnellstart¶
In 5 Minuten von Null zur laufenden Kamerplanter-Instanz mit deinen ersten Pflanzen.
Voraussetzung
Docker und Docker Compose müssen installiert sein. Falls nicht, folge zuerst der Installationsanleitung.
1. Repository herunterladen¶
Lade den Quellcode herunter und wechsle in das Verzeichnis:
Kein Git installiert?
Du kannst das Repository auch als ZIP-Datei herunterladen: Gehe auf die GitHub-Seite, klicke auf den grünen Code-Button und wähle Download ZIP. Entpacke die Datei und öffne ein Terminal im entpackten Ordner.
2. Konfiguration erstellen¶
Kopiere die Beispiel-Konfiguration und passe die Passwörter an:
Öffne die Datei .env in einem Texteditor und ändere mindestens die Passwörter:
# Sichere Passwörter setzen (mindestens 12 Zeichen empfohlen)
ARANGO_ROOT_PASSWORD=dein-sicheres-passwort # (1)!
ARANGODB_PASSWORD=dein-sicheres-passwort # (2)!
- Das Passwort für die Datenbank. Wähle ein sicheres Passwort — es wird nicht im Browser angezeigt.
- Muss identisch mit
ARANGO_ROOT_PASSWORDsein.
Sicheres Passwort generieren
Unter Linux/macOS kannst du ein zufälliges Passwort erzeugen:
Kopiere die Ausgabe und setze sie als Passwort in der .env-Datei ein.
Die übrigen Einstellungen kannst du zunächst auf den Standardwerten belassen.
Vier zusätzliche Pflicht-Secrets (sonst startet das Backend nicht)¶
Ohne diese vier Werte bricht der Backend-Start ab
.env.example setzt DEBUG=false. Bei DEBUG=false prüft das Backend beim Start vier weitere Geheimnisse — JWT_SECRET_KEY, FERNET_KEY, ERASURE_TOMBSTONE_SALT und LOG_PSEUDONYM_SALT — und bricht mit einer Fehlermeldung ab, wenn eines davon fehlt (Fail-Fast-Gate, unabhängig vom Betriebsmodus). Die mitgelieferten docker-compose.yml/docker-compose.release.yml reichen diese vier Variablen nicht automatisch an den Backend-Container durch — du musst sie selbst ergänzen. Auch der celery-worker-Container prüft FERNET_KEY und LOG_PSEUDONYM_SALT inzwischen beim Start und bricht ebenso ab, wenn ein Wert fehlt oder ungültig ist — der celery-worker-Eintrag in der docker-compose.override.yml unten ist deshalb Pflicht, nicht optional. celery-beat prüft LOG_PSEUDONYM_SALT nicht.
Erzeuge die vier Werte:
# JWT_SECRET_KEY, ERASURE_TOMBSTONE_SALT und LOG_PSEUDONYM_SALT (je mind. 32 Zeichen)
openssl rand -hex 32
# FERNET_KEY (muss ein gültiger Fernet-Schlüssel sein)
python3 -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"
Trage die vier Werte in deine .env ein:
JWT_SECRET_KEY=<Ausgabe von openssl rand -hex 32>
FERNET_KEY=<Ausgabe des Fernet-Kommandos>
ERASURE_TOMBSTONE_SALT=<zweite Ausgabe von openssl rand -hex 32>
LOG_PSEUDONYM_SALT=<dritte Ausgabe von openssl rand -hex 32>
Lege zusätzlich eine docker-compose.override.yml an, die diese Werte tatsächlich an die Container durchreicht (Docker Compose lädt sie automatisch mit, sobald sie im selben Verzeichnis liegt):
services:
backend:
environment:
JWT_SECRET_KEY: ${JWT_SECRET_KEY}
FERNET_KEY: ${FERNET_KEY}
ERASURE_TOMBSTONE_SALT: ${ERASURE_TOMBSTONE_SALT}
LOG_PSEUDONYM_SALT: ${LOG_PSEUDONYM_SALT}
celery-worker:
environment:
FERNET_KEY: ${FERNET_KEY}
ERASURE_TOMBSTONE_SALT: ${ERASURE_TOMBSTONE_SALT}
LOG_PSEUDONYM_SALT: ${LOG_PSEUDONYM_SALT}
celery-beat:
environment:
FERNET_KEY: ${FERNET_KEY}
ERASURE_TOMBSTONE_SALT: ${ERASURE_TOMBSTONE_SALT}
Alternative: DEBUG=true nur für kurze lokale Tests
Setzt du DEBUG=true in der .env, überspringt das Backend diese Prüfung komplett und startet auch ohne die vier Secrets. Das ist für einen kurzen, rein lokalen Test auf deinem eigenen Rechner vertretbar, aber niemals für einen Server, der über das Netzwerk erreichbar ist — DEBUG=true schaltet zusätzlich ausführliche Logs frei. Details zu allen Pflicht-Secrets je Funktion: Konfigurationsmatrix — Pflicht-Secrets.
3. Kamerplanter starten¶
Starte alle Dienste mit einem einzigen Befehl:
Docker lädt beim ersten Start die benötigten Images herunter. Das kann je nach Internetverbindung 2–5 Minuten dauern. Bei weiteren Starts geht es deutlich schneller.
Prüfe, ob alle Dienste laufen:
Du solltest fünf Dienste sehen, alle mit dem Status running oder healthy:
NAME STATUS
kamerplanter-arangodb-1 running (healthy)
kamerplanter-valkey-1 running (healthy)
kamerplanter-backend-1 running (healthy)
kamerplanter-celery-worker-1 running
kamerplanter-celery-beat-1 running
kamerplanter-frontend-1 running (healthy)
Ein Dienst zeigt 'unhealthy' oder 'restarting'?
Warte 30 Sekunden und führe docker compose ps erneut aus — manche Dienste brauchen etwas länger zum Starten. Falls das Problem bestehen bleibt, prüfe die Logs:
4. Kamerplanter im Browser öffnen¶
Öffne deinen Browser und gehe zu:
Da Kamerplanter standardmäßig im Light-Modus startet, gibt es keinen Login-Bildschirm — du landest direkt im Onboarding-Wizard.
5. Erste Einrichtung¶
Beim ersten Öffnen startet Kamerplanter automatisch den Onboarding-Wizard. Er führt dich in wenigen Minuten durch Erfahrungsstufe, Standort und die Wahl eines Starter-Kits (z. B. "Fensterbrett-Kräuter" oder "Zimmerpflanzen-Starter"). Alles ist selbsterklärend und im Detail beschrieben auf der Seite Onboarding-Wizard.
Geschafft!¶
Dein Kamerplanter läuft. Von hier aus kannst du:
- Pflanzen ansehen und den Wachstumsstatus verfolgen
- Aufgaben prüfen, die das Starter-Kit angelegt hat
- Standorte anpassen — Räume umbenennen, weitere hinzufügen
- Weitere Pflanzen anlegen — über das Menü "Stammdaten"
Optionale Profile (KI, Sensordaten)¶
Der Basis-Start mit docker compose up -d reicht für den vollständigen Pflanzen-, Aufgaben- und Pflegebetrieb. Zusätzliche Funktionen — KI-Wissensassistent und Sensordaten-Historie — können über optionale Docker Compose Profile zugeschaltet werden.
Profile sind additiv und kombinierbar
Jedes Profil erweitert die Basis um zusätzliche Dienste. Du kannst mehrere Profile gleichzeitig aktivieren.
Übersicht der Profile¶
| Profil | Was es startet | Wofür | Nötiger .env-Schalter |
|---|---|---|---|
vectordb | PostgreSQL + pgvector (Port 5433) + Reranker-Service (Port 8081) | KI-/RAG-Wissensassistent — semantische Suche in der Wissensdatenbank | VECTORDB_ENABLED=true |
ollama | Ollama LLM-Server (Port 11434) | Lokale LLM-Inferenz für den Wissensassistenten, als Alternative zu einer Cloud-API | LLM_PROVIDER=ollama und LLM_API_URL=http://ollama:11434 |
timescaledb | TimescaleDB (Port 5432) | Zeitreihen-Speicherung von Sensordaten (Messwert-Historie, automatisches Downsampling) | TIMESCALEDB_ENABLED=true |
Beispiel-Befehle¶
Nur Basis (Standard — kein Profil nötig):
KI-Wissensassistent mit lokalem LLM (Ollama):
Aktiviere anschließend die Dienste in der .env:
VECTORDB_ENABLED=true
LLM_PROVIDER=ollama
LLM_API_URL=http://ollama:11434
LLM_MODEL=llama3.2 # Beliebiges auf Ollama verfügbares Modell
Modell beim ersten Start herunterladen
Ollama lädt das Modell beim ersten Aufruf herunter. Abhängig vom Modell sind das 4–15 GB — plane entsprechend Disk-Speicher ein.
KI-Wissensassistent mit Cloud-LLM (z. B. Anthropic):
VECTORDB_ENABLED=true
LLM_PROVIDER=anthropic
LLM_API_KEY=sk-ant-...
LLM_MODEL=claude-sonnet-4-20250514
Sensordaten-Historie:
Ressourcenbedarf der Profile¶
Ollama braucht deutlich mehr Ressourcen
LLM-Modelle sind groß. Rechne für ein kleineres Modell (z. B. llama3.2) mit mindestens 8 GB RAM und 5 GB freiem Speicherplatz. Größere Modelle benötigen entsprechend mehr. Ohne dedizierte GPU läuft die Inferenz auf der CPU — das ist langsamer, aber funktioniert.
| Profil | Zusätzlicher RAM (typisch) | Zusätzlicher Speicher |
|---|---|---|
vectordb | ~512 MB | ~500 MB |
ollama | 8–16 GB (je nach Modell) | 5–30 GB (je nach Modell) |
timescaledb | ~256 MB | wächst mit Sensordaten |
Nützliche Befehle¶
| Befehl | Was er tut |
|---|---|
docker compose up -d | Alle Basisdienste starten |
docker compose --profile vectordb --profile ollama up -d | Basis + KI-Profile starten |
docker compose --profile timescaledb up -d | Basis + Sensordaten-Profil starten |
docker compose stop | Alle Dienste anhalten (Daten bleiben erhalten) |
docker compose down | Alle Dienste stoppen und Container entfernen (Daten bleiben erhalten) |
docker compose down -v | Alles stoppen und Daten löschen (Neuanfang) |
docker compose logs -f backend | Backend-Logs live verfolgen |
docker compose ps | Status aller Dienste anzeigen |
Daten löschen
Der Befehl docker compose down -v löscht alle gespeicherten Daten unwiderruflich. Verwende ihn nur, wenn du einen kompletten Neuanfang möchtest.
Zugangspunkte¶
Standard (immer verfügbar)¶
| Dienst | URL | Beschreibung |
|---|---|---|
| Benutzeroberfläche | http://localhost:8080 | Die Kamerplanter-App |
| API-Dokumentation | http://localhost:8000/api/v1/docs | Interaktive API-Referenz (Swagger UI) |
| Datenbank-UI | http://localhost:8529 | ArangoDB Web-Interface (für Fortgeschrittene) |
Optional (nur mit aktiviertem Profil)¶
| Dienst | URL | Profil | Beschreibung |
|---|---|---|---|
| Reranker-Service | http://localhost:8081 | vectordb | Cross-Encoder für RAG-Qualität |
| Ollama | http://localhost:11434 | ollama | Lokaler LLM-Server (API) |
Alle Ports sind nur von diesem Rechner erreichbar
Docker Compose bindet jeden Port aus den Tabellen oben an 127.0.0.1. http://localhost:… funktioniert auf dem Rechner, auf dem Kamerplanter läuft — kein anderes Gerät im selben Netzwerk erreicht ihn: nicht die Datenbanken, nicht Valkey, nicht Ollama und auch nicht die App selbst. ArangoDB, Valkey und die PostgreSQL-Datenbanken halten deine Daten hinter den Beispiel-Passwörtern aus .env.example; Ollama und der Reranker-Service haben gar keine Authentifizierung.
Du willst Kamerplanter auf dem Smartphone oder Tablet öffnen? Bedenke, dass dieser Stack im Light-Modus läuft, der keine Anmeldung kennt: Sobald die Ports offen sind, kann jedes Gerät in deinem Netzwerk deine Daten lesen und ändern. Ist das in deinem Heimnetz in Ordnung, setze KAMERPLANTER_BIND_ADDRESS=0.0.0.0 in der .env und starte mit docker compose up -d neu. Damit öffnest du nur die Benutzeroberfläche (Port 8080) und die API (Port 8000) für dein Netzwerk — Datenbanken, Valkey, Ollama und der Reranker bleiben auf diesem Rechner. Die Schritte stehen unter Dauerbetrieb — Zugriff von anderen Geräten.
Der Reranker-Container läuft außerdem schreibgeschützt, als UID 1000 und ohne Linux-Capabilities — siehe „Container-Härtung" in der KI-Architektur.
Siehe auch¶
- Onboarding-Wizard — Ausführliche Beschreibung aller Wizard-Schritte
- Light-Modus — Was der Light-Modus genau bedeutet
- Erstes Deployment — Kamerplanter dauerhaft auf eigenem Server betreiben