Referenz der Umgebungsvariablen

Dies ist die vollständige Liste der Umgebungsvariablen, die der Studio-Server einliest. Anders als Werte, die über die Oberfläche (Einstellungen) geändert werden, wirken sich Werte hier erst nach Bearbeiten der Datei und Neustart aus.

Die maßgebliche Quelle ist /etc/kopens/plantpulse-studio.env

/etc/kopens/plantpulse-studio.env

.env im Repository-Root wird nicht mehr gelesen

Werte im alten Pfad (.env im Installationsverzeichnis) werden nicht wirksam. Ist die alte Datei noch vorhanden, weist das Skript darauf hin. Bearbeiten Sie Werte über den oben genannten maßgeblichen Pfad.

Setzen Sie die Berechtigungen auf chmod 600 — die Datei enthält API-Schlüssel.

---

Images und Versionen

Variable	Standardwert	Beschreibung
REGISTRY	docker.kopens.io/ps	Registry, von der Images geholt werden. Leer bedeutet, dass nur lokale Tags verwendet werden (bei eigenem Build)
PP_IMAGE_TAG	(leer)	CalVer-Tag für unser Image-Set (server · web)
PS_IMAGE_TAG_SERVER	(keiner)	Wenn nur plantpulse-studio-server mit einem anderen Tag gestartet werden soll
PS_IMAGE_TAG_WEB	(keiner)	Wenn nur plantpulse-studio-web mit einem anderen Tag gestartet werden soll
PS_IMAGE_TAG_AGENT_SERVER	0c5ac7fb	Agent-Sidecar. Da es sich um einen Digest-Pin (OpenHands SDK v1.43.1) statt CalVer handelt, folgt es PP_IMAGE_TAG nicht

Es wird empfohlen, PP_IMAGE_TAG leer zu lassen

Bleibt es leer, liest bin/start.sh das CalVer aus der Datei VERSION und folgt bei jedem Release automatisch mit. Wird hier ein Monat von Hand eingetragen, bleibt dieser Wert fest eingefroren — genau deshalb kam es schon vor, dass ein Image von vor einem Monat lief.

Wenn ein Zeitpunkt fest fixiert werden muss, tragen Sie nicht den Monat (2026.09), sondern einen Snapshot-Tag (2026.09-20260911) ein. Rechnen Sie nicht selbst mit date +%Y.%m — zwischen 00:00 und 04:00 KST am 1. jedes Monats zeigt dies auf einen noch nicht existierenden Tag (das Release des Monats erscheint erst um 04:00).

Variablen namens TAG · AGENT_SERVER_TAG gibt es nicht

Compose liest nur die Namen aus der obigen Tabelle. Trägt man TAG=2026.08 ein, passiert nichts, und der Stack startet mit dem CalVer aus VERSION — man glaubt fixiert zu haben, folgt aber weiterhin mit.

Um auf einen bestimmten Release-Zeitpunkt zu fixieren, verwenden Sie einen Snapshot-Tag — z. B. TAG=2026.08-20260810. :::

---

Locale und Zeitzone

Es werden dieselben Variablennamen wie bei Platform und Edge verwendet.

Variable	Standardwert	Beschreibung
PP_LANG	en	Standardsprache der Web-Oberfläche (ko / en). Im Browser gespeicherte Werte haben Vorrang
PP_TZ	Asia/Seoul	IANA-Zeitzonen-ID. Grundlage für die Interpretation relativer Zeitangaben wie „heute / gestern"

Bei Vor-Ort-Einsatz in Korea belassen Sie PP_LANG=ko.

---

Speicherort der Daten

Variable	Standardwert	Beschreibung
DATA_ROOT	/var/lib/pp-studio	Workspace · Build-Artefakte · Zustand werden allesamt unterhalb dieses Pfads gespeichert

Dieser Pfad ist Ziel der Sicherung → Backup und Wiederherstellung.

---

Datenbank — externes PostgreSQL

Studio verwendet ein externes PostgreSQL. Es kann dasselbe PG wie die Platform gemeinsam genutzt werden.

Variable	Beispiel
DATABASE_URL	postgres://<user>:<password>@<db-host>:5432/ppstudio

🔴 Eine Variable namens PG_PASSWORD gibt es nicht. Das DB-Passwort ist in derselben Zeile wie DATABASE_URL enthalten — eine separate Variable nur für das Passwort könnte mit der URL in Widerspruch geraten, daher wurde alles in einer Zeile zusammengefasst.

DATABASE_URL ist zwingend erforderlich

Ist der Wert leer, bricht die Installation sofort ab und zeigt an, was fehlt — es wird kein plausibler Standardwert erfunden.

DB und Rolle müssen «vorher» angelegt werden

Der Server führt nur Migrationen auf einer bestehenden Datenbank aus. Er legt DB und Rolle nicht selbst an — das übernimmt bin/provision-platform-db.sh. Siehe „Datenbank vorbereiten" unter Installation.

---

Platform-Integration

Variable	Beschreibung
PP_API_URL	Adresse der Platform, an die Abfragen von Echtdaten und Login-Authentifizierung delegiert werden
PP_API_TOKEN	api_key dieser Platform

Im Container lauten die Namen anders

In Logs oder im Container erscheinen sie als PLATFORM_API_TARGET · PLATFORM_API_KEY. In .env tragen Sie die Namen PP_API_URL · PP_API_TOKEN ein — siehe „Namen auf zwei Ebenen" unten.

---

Listener-Ports

Variable	Standardwert	Beschreibung
PORT	5170	API-Port des Studio-Servers (Orchestrator). Da Web intern als Proxy dient, muss dieser nicht nach außen geöffnet werden — dient Diagnosezwecken (curl localhost:5170/health)
APPS_PORT	5171	Separater Listener-Port zum Ausliefern von Vorschau und bereitgestellten Apps

• Bei direktem Zugriff über Port — Die Firewall muss auch diesen Port öffnen, damit Vorschau, bereitgestellte Apps und QR-Zugriff funktionieren.
• Hinter einem Reverse-Proxy — Muss nicht geöffnet werden. Der Proxy leitet /container /preview · /apps derselben Domain an diesen Listener weiter → Domain und Reverse-Proxy.

Kein Angeben eines App-Origin nötig

Der Client verwendet ausschließlich relative Pfade. Die öffentliche URL von Vorschau und bereitgestellten Apps muss nicht separat mitgeteilt werden — das funktioniert auch bei einer Konfiguration, in der nur 80/443 geöffnet sind.

---

KI-Provider

Die Werte hier sind Anfangswerte. Werte, die über die Oberfläche (Einstellungen → AI) gesetzt werden, überschreiben diese.

Variable	Standardwert	Beschreibung
AI_PROVIDER	openai-compatible	Ist leer, gilt immer openai-compatible
PI_LLM_URL	(leer — erforderlich)	Gateway-Adresse. Es gibt keinen Standardwert
AI_MODEL	gpt-4o	Modellname
PI_LLM_API_KEY	(leer — erforderlich)	OpenAI-kompatibler Schlüssel
PS_ANTHROPIC_API_KEY	(leer)	Nur bei Nutzung von Cloud-Claude

⚠ Sind PI_LLM_URL und PI_LLM_API_KEY leer, verweigert der Stack den Start.

Warum PI_LLM_URL keinen plausiblen Standardwert erhält

Befindet sich das Gateway nicht auf diesem Host, schlägt der gesamte Chat mit fetch failed fehl — und weil der Wert plausibel aussieht, wird die Fehlersuche teuer. Tragen Sie die tatsächliche Adresse ein. Ob der eingetragene Wert korrekt ist, lässt sich vor dem Speichern über Verbindungstest im Tab Einstellungen → AI prüfen → Einstellungen (Administrator).

Der Provider wird nicht aus dem Schlüssel abgeleitet

Der Provider wird explizit über AI_PROVIDER angegeben. Würde er anhand des enthaltenen Schlüssels gewählt, wäre je nach env-Konfiguration nicht vorhersehbar, was tatsächlich startet.

---

CORS

Variable	Standardwert	Beschreibung
STUDIO_CORS_ORIGINS	(leer = same-origin)	Nur angeben, wenn der Zugriff von einer separaten Domain erfolgt

---

Installations- und Start-Flags

Dies sind Werte, die dem Befehl vorangestellt werden statt in .env (SKIP_DOCKER=1 bash bin/install.sh).

Variable	Standardwert	Beschreibung
SKIP_DOCKER	0	Bei 1 wird der Docker-Installationsschritt übersprungen (falls bereits installiert)
SKIP_WAIT	0	Bei 1 endet das Skript, ohne auf den Abschluss des Starts zu warten
WAIT_READY_MIN	10	Wartezeit bis zum Abschluss des Starts (in Minuten). Bei langsamer Verbindung oder großen Images erhöhen

Ressourcen des Agent-Sidecars

Variable	Standardwert	Beschreibung
AGENT_SERVER_CPUS	1	Anzahl der CPUs für den Builder-Sidecar
AGENT_SERVER_MEMORY	2g	Speicherlimit für den Builder-Sidecar

Was nicht über env übertragen wird

Benutzerkonten und Rollen werden nicht über Umgebungsvariablen festgelegt. Existiert noch kein Konto, legt der Server einen Administrator in der DB an; danach erfolgen Hinzufügen, Löschen und Vergabe von Rollen (admin / builder / viewer) ausschließlich über die Benutzerverwaltung in der App.

→ Ändern des Anfangspassworts

---

Verwandte Dokumente

• Installation — Ablauf zum erstmaligen Befüllen der Werte
• Verwaltung von Geheimnissen — Wo Schlüssel abgelegt werden
• Einstellungen (Administrator) — Werte, die über die Oberfläche geändert werden
• Domain und Reverse-Proxy

---

Namen auf zwei Ebenen — .env und der Container unterscheiden sich

🔴 Hier passieren die meisten Fehler. Die Namen, die in Logs · docker inspect · Produktquellen erscheinen, unterscheiden sich von denen, die in .env eingetragen werden. Einzutragen ist die linke Spalte.

In .env einzutragender Name	Im Container sichtbarer Name
PP_API_URL	PLATFORM_API_TARGET
PP_API_TOKEN	PLATFORM_API_KEY
PI_LLM_URL	AI_BASE_URL
PI_LLM_API_KEY	AI_API_KEY
PS_ANTHROPIC_API_KEY	ANTHROPIC_API_KEY

Bei den übrigen (DATABASE_URL · DATA_ROOT · APPS_PORT · AI_PROVIDER · AI_MODEL · STUDIO_CORS_ORIGINS) stimmen die Namen auf beiden Seiten überein.

Warum die Namen getrennt wurden

Auf einem Server liegen mehrere Produkte (Platform · AI · Studio) gemeinsam. Versieht man die Namen auf .env-Seite mit einem Produktpräfix (PP_ Platform · PI_ gemeinsame Infrastruktur · PS_ Studio), zeigt sich schon am Namen, zu welchem Produkt der Wert gehört, und es entsteht keine Verwirrung, selbst wenn sich zwei Produkte einen Wert teilen.