Installation
Dieses Verfahren beschreibt die Installation von PlantPulse Studio auf einem einzelnen Kundenserver. Es besteht aus vier Docker-Containern (Web · Server · Builder Sidecar · Docker-Proxy). Das Installationsskript übernimmt alles automatisch, von der Docker-Installation bis zum Start.
Wir verwenden eine externe PG – Sie können dieselbe PG verwenden, die auch die Plattform nutzt. Früher gab es einen Modus, der einen gebündelten Container startete, aber der wurde entfernt (2026-08-28) – es gab tatsächlich einen Vorfall, bei dem sich zwei Prozesse auf einem Server um Port 5432 stritten.
Wenn Sie ein Air-Gap-Netzwerk ohne Internetzugang haben, lesen Sie stattdessen Installation im luftdichten Netzwerk.
1. Voraussetzungen
Serverspezifikationen
| Element | Minimum | Empfohlen | Hinweise |
|---|---|---|---|
| CPU | 4 Kerne | 8 Kerne oder mehr | Pro App-Sitzung wird ein Build ausgeführt |
| RAM | 8 GB | 16 GB oder mehr | Siehe Tabelle unten |
| Festplatte | 50 GB frei | 100 GB oder mehr | Nur die Container-Images sind etwa 6 GB groß |
| OS | Linux (x86_64) | RHEL 9 / Rocky 9 / Ubuntu 22.04 oder neuer | systemd + Docker müssen laufen |
Speicherberechnung – das sind die festen Obergrenzen des Stacks.
| Container | Speicherobergrenze |
|---|---|
| studio-server (Orchestrator) | 2 GB |
| agent-server (Builder Sidecar) | 2 GB (einstellbar über AGENT_SERVER_MEMORY) |
| studio-web (nginx) | 256 MB |
| docker-proxy (Docker-Zugang) | 128 MB |
| Pro App-Sitzungscontainer | 2 GB |
App-Sitzungscontainer werden immer dann gestartet, wenn ein Benutzer ein Projekt öffnet, und werden nach 30 Minuten Inaktivität automatisch entfernt. Planen Sie zusätzlich 2 GB pro gleichzeitig aktivem Benutzer ein.
Planen Sie 16 GB RAM · 8 Kerne · 100 GB Festplatte ein – das ist komfortabel.
Software
- Docker Engine + Docker Compose v2 (v2.22 oder neuer) Falls nicht installiert, installiert das Ein-Zeilen-Installationsskript beides automatisch.
curl,tar(in den meisten Distributionen enthalten)
Ports und Firewall
Der Stack läuft im Host-Netzwerkmodus. Das heißt, die Container-Ports sind direkt auf dem Host geöffnet. Der Zugriffsschutz erfolgt daher ausschließlich über die Server-Firewall.
| Port | Zweck | Firewall |
|---|---|---|
| 80 | Studio-UI (nginx) | Öffnen |
| 5171 | App-Listener – Vorschau · Bereitgestellte Apps · QR-Zugriff | Öffnen (erforderlich) |
| 5170 | Studio-API | Web-Server ist interner Proxy – nicht öffnen (nur für Diagnose) |
| 8000 | Builder Sidecar (agent-server) | Nur Loopback – niemals öffnen |
| 5172 | MCP-Tool-Brücke | Nur Loopback – niemals öffnen |
| 2375 | Docker-Daemon-Zugang (docker-proxy) | Nur an 127.0.0.1 binden – der einzige Container im Stack, der nicht im Host-Netzwerk läuft |
Die Vorschau (/preview/…) und bereitgestellte Apps (/apps/…) werden aus Sicherheitsgründen auf einem anderen Ursprung (Standard-Port 5171) als das Studio ausgeliefert. Das verhindert, dass JavaScript einer per Chat erstellten App auf das Studio-Login-Token zugreifen kann. Wenn Sie 5171 nicht öffnen, erscheint der Bildschirm leer.
Diese beiden Ports sind nur für die Kommunikation zwischen internen Komponenten gedacht und haben keinen Authentifizierungsmechanismus. Wenn sie extern zugänglich sind, kann der gesamte Benutzerarbeitsbereich gelesen und beschrieben werden. Der Stack bindet standardmäßig nur an Loopback, aber öffnen Sie diese Ports niemals in der Firewall.
Registry-Zugriff
Die Images werden von der KOPENS-Registry (docker.kopens.io) bezogen. Melden Sie sich vor der Installation einmal an. Konten werden vom KOPENS-Betriebsteam ausgestellt.
docker login docker.kopens.io
2. Datenbank vorbereiten
Studio verwendet eine externe PostgreSQL. Sie können dieselbe PG verwenden, die auch die Plattform nutzt.
DATABASE_URL ist erforderlichWenn diese Variable leer ist, bricht die Installation sofort ab und meldet, was fehlt. Es werden keine plausiblen Standardwerte erfunden – das hat in der Vergangenheit zu Unfällen geführt, weil scheinbar plausible Standardwerte auf falsche Ziele zeigten.
DATABASE_URL=postgres://`<user>`:`<password>`@`<db-host>`:5432/`<db-name>`
Datenbank und Benutzerkonto zuerst anlegen
🔴 Der Server führt nur Migrationen auf einer vorhandenen Datenbank durch. Er legt weder Datenbank noch Rollen an. Dafür gibt es ein separates Skript.
# .env 의 DATABASE_URL 이 가리키는 DB · 역할을 만든다
bin/provision-platform-db.sh
# 관리자 계정을 따로 줘야 하는 경우
ADMIN_URL=postgres://`<관리자>`:`<password>`@`<호스트>`:5432/postgres bin/provision-platform-db.sh
# 무엇을 할지 보기만 한다
DRYRUN=1 bin/provision-platform-db.sh
Es gelten die gleichen Regeln wie für die KI-Seite.
3. Installation (Einzeiler – empfohlen)
Melden Sie sich als root auf dem Server an und führen Sie eine Zeile aus. Das Skript übernimmt: Docker prüfen/installieren → Pakete herunterladen → .env erstellen → Stack starten.
curl -fsSL https://product.kopens.io/plantpulse-studio/install.sh | sudo bash
Das Installationsverzeichnis ist /opt/kopens/plantpulse-studio-docker. Alle späteren Betriebsbefehle werden von diesem Verzeichnis aus ausgeführt.
Werte vorab festlegen und unbeaufsichtigt installieren
Umgebungsvariablen müssen vor bash stehen, damit sie durch die Pipe übertragen werden.
curl -fsSL https://product.kopens.io/plantpulse-studio/install.sh \
| sudo PLATFORM_API_TARGET=https://192.168.0.41 \
DATA_ROOT=/data1/pp-studio \
PS_ANTHROPIC_API_KEY=sk-ant-... \
bash
Werte interaktiv abfragen lassen
curl -fsSL https://product.kopens.io/plantpulse-studio/install.sh | sudo INTERACTIVE=1 bash
Wenn Sie das Skript auf einem bereits installierten Server erneut ausführen, überspringt es die Abfragen komplett, weil der Sidecar die Werte bereits enthält. Der obige Bildschirm zeigt die Erstinstallation auf einer frischen Box.
Es werden nur fünf Dinge abgefragt (seit 2026.09). Die übrigen sieben werden mit Standardwerten belegt, und die festgelegten Werte werden am Ende der Installation als Liste ausgegeben – sie werden nicht versteckt, sondern angezeigt und übergangen.
| Nr. | Abfrage | Variable |
|---|---|---|
| 1 | Plattform-API-Server (https://…) | PP_API_URL |
| 2 | Plattform-API-Token (X-API-Key) | PP_API_TOKEN |
| 3 | AI-Gateway-Adresse – inklusive /v1 | PI_LLM_URL |
| 4 | AI-Gateway-Schlüssel (LiteLLM-Masterschlüssel) | PI_LLM_API_KEY |
| 5 | KI-Modellname – der im Gateway registrierte Name | AI_MODEL |
Wenn ein erforderlicher Wert fehlt, stoppt die Installation. Das ist beabsichtigt, um den Zustand „Installation scheint fertig, aber der Stack startet nicht“ zu verhindern. DATABASE_URL wird nicht abgefragt – PostgreSQL ist im Stack enthalten und die Installation füllt den Wert selbst aus.
Die sieben Werte, die nicht abgefragt und mit Standardwerten belegt werden – DATA_ROOT(/var/lib/pp-studio) · AI_PROVIDER(openai-compatible) · PP_LANG(en) · PP_TZ(Asia/Seoul) · APPS_PORT(5171) · REGISTRY(docker.kopens.io/ps) · PP_IMAGE_TAG (aktuelle Kalenderversion).
Wenn Sie einen Modellnamen angeben, den das Gateway nicht bereitstellt, schlägt das genauso fehl wie ein falscher Schlüssel. Deshalb wurde dieser Wert aus den Standardwerten herausgenommen und zur Abfrage gemacht.
Zum Ändern können Sie entweder Umgebungsvariablen setzen oder PP_ADVANCED=1 ausführen, um alles abzufragen.
PS_ANTHROPIC_API_KEY wird jetzt nicht mehr abgefragtDas war nur für Cloud-Claude erforderlich. Da dieses Produkt ein Gateway voraussetzt, war diese Frage praktisch für alle nur ein Durchklicken. Die Funktionalität bleibt – es gibt drei Wege, den Wert zu setzen: als Umgebungsvariable bei der Installation, später über bin/passwd.sh PS_ANTHROPIC_API_KEY (wenn der Wert weggelassen wird, wird er interaktiv abgefragt und erscheint nicht in der Befehlszeile), oder über Einstellungen > KI in der Oberfläche. Auch mit PP_ADVANCED=1 wird er nicht mehr abgefragt.
Wenn Sie das Installationsskript auf demselben Server erneut ausführen, werden nur der Code aktualisiert, .env und lokale Backups (dist/) bleiben erhalten. Das Skript kann daher auch für Upgrades verwendet werden.
Möglicherweise ist noch ein CDN-Cache vorhanden. Hängen Sie ?v=$(date +%s) an die URL an und laden Sie es erneut herunter.
Bei falschen Werten wird vor der Installation abgebrochen
Bevor das System angefasst wird – noch bevor Docker installiert wird – wird mit den empfangenen Zugangsdaten jeweils ein realer Aufruf durchgeführt. Für die Plattform ist das GET /api/v5/site?limit=1, für das Gateway GET /v1/models.
Nur eine Ablehnung bricht ab. Ein „Konnte nicht abfragen“ bricht nicht ab.
| Antwort | Bewertung | Installation |
|---|---|---|
2xx | Akzeptiert | Weiter |
401 · 403 | Zugangsdaten falsch | Abbruch |
400 | Anforderung des Installationsskripts fehlerhaft – Produktdefekt, bitte melden | Abbruch |
5xx · nicht erreichbar | Bewertung nicht möglich | Nur Warnung, weiter |
5xx wurde absichtlich nicht in dieselbe Zeile wie 401 gesetzt – es gab einen Fall, in dem eine überlastete Plattform zunächst 503 lieferte und drei Minuten später mit demselben Token 401. Wenn Sie ein Gateway, das gerade geprüft wird oder später als das Studio hochfährt, fälschlich als „falscher Schlüssel“ einstufen, wird eine einwandfreie Installation abgelehnt.
Der Modellname wird ebenfalls geprüft. Die /v1/models-Antwort des Gateways wird gelesen und geprüft, ob AI_MODEL in der Liste enthalten ist. Wenn nicht, wird die Liste der bereitgestellten Modelle ausgegeben und die Installation gestoppt. Wenn die Liste nicht gelesen werden kann, wird keine Bewertung vorgenommen – eine leere Antwort als „nicht vorhanden“ zu deuten, wäre eine falsche Aussage, die nicht fehlschlagen kann.
PP_SKIP_CRED_CHECK=1Dies ist für Tests gedacht, bei denen die Installation selbst mit Platzhalter-Zugangsdaten geprüft wird (das Release-Gate des Produkts nutzt diesen Pfad). Wenn Sie diesen Wert im regulären Betrieb aktivieren, verschieben Sie nur den unvermeidlichen Fehler beim ersten echten Einsatz vom Installationszeitpunkt nach hinten.
4. Installation (manuell)
Dies ist für den Fall, dass Sie die Pakete bereits heruntergeladen haben oder .env selbst erstellen möchten.
cd /opt/kopens/plantpulse-studio-docker
sudo cp .env.example /etc/kopens/plantpulse-studio.env
sudo vi /etc/kopens/plantpulse-studio.env # 아래 표를 보고 값 채우기
sudo chmod 600 /etc/kopens/plantpulse-studio.env
bash bin/up.sh
/etc/kopens/plantpulse-studio.envDie Umgebungsvariablendatei liegt außerhalb des Installationsverzeichnisses, nämlich unter /etc/kopens/plantpulse-studio.env (außerhalb des Repo-Baums). Die Berechtigungen sind 0600. Die drei Produkte Plattform · KI · Studio verwenden denselben Standard für /etc/kopens/plantpulse-<product>.env.
Die .env im Stammverzeichnis des Installationsverzeichnisses ist der alte Pfad. Weder Compose noch die anderen Skripte lesen diese Datei mehr; Änderungen dort haben keine Auswirkung auf den Stack. Bei bestehenden Installationen wird die .env von der bin/install.sh an den neuen Pfad verschoben (nicht neu erstellt – eine Neuerstellung würde zu einem Konflikt führen: Die DB hätte noch das alte Passwort, die Umgebungsvariable aber den neuen Standardwert, was beim nächsten Neustart zu einem Ausfall führt).
Wichtige Einträge in der Umgebungsvariablen-Datei
| Element | Beschreibung | Standardwert |
|---|---|---|
REGISTRY | Image-Registry. Wenn leer, werden nur lokale Images ohne Pull verwendet (Air-Gap). | docker.kopens.io/ps |
PP_IMAGE_TAG | Image-Tag. Wenn leer, folgt es dem Kalender von VERSION. Zum Festlegen wird ein Snapshot-Tag empfohlen (2026.09-20260911). | (leer) |
DATA_ROOT | Pfad, unter dem alle Daten (Arbeitsbereiche · Builds · Zustand · DB) gespeichert werden | /var/lib/pp-studio |
PLATFORM_API_TARGET | PlantPulse-Plattformadresse, an die Echtzeitdaten und Authentifizierung delegiert werden | https://192.168.0.41 |
APPS_PORT | Port des App-Listeners (Vorschau · bereitgestellte Apps) | 5171 |
PP_LANG | Standardsprache der Weboberfläche ko / en | en |
PP_TZ | Zeitzone (IANA-ID). Basis für die Interpretation von „heute · gestern · letzte Woche“ | Asia/Seoul |
STUDIO_CORS_ORIGINS | Nur angeben, wenn die API von einer anderen Domain aufgerufen wird. Standardmäßig blockiert. | Leer |
DATABASE_URL | Adresse der externen PostgreSQL – siehe Abschnitt 2 | Leer (erforderlich) |
PI_LLM_API_KEY · PP_API_TOKEN usw. | KI- · Plattform-Schlüssel – siehe Geheimnisverwaltung | Leer (erforderlich) |
Konten werden nicht über Umgebungsvariablen übertragen. Wenn der Server beim ersten Start keine Konten hat, wird ein Bootstrap-Administrator in der DB angelegt. Danach werden Konten über Einstellungen → Benutzerverwaltung in der Anwendung hinzugefügt, gelöscht und Rollen (Administrator / Ersteller / Betrachter) zugewiesen. Siehe unten 7. Erste Anmeldung.
PP_LANG=ko manuell eintragenDie von der Ein-Zeilen-Installation erstellte .env enthält die Zeilen PP_LANG · PP_TZ nicht, sodass die Standardwerte (en / Asia/Seoul) gelten. Um die Oberfläche auf Koreanisch anzuzeigen, fügen Sie in .env die PP_LANG=ko hinzu und bash bin/restart.sh.
.env ist ein bin/restart.sh zwingend erforderlichdocker restart liest die .env nicht erneut. Das ist eine typische Falle, bei der man lange nach „warum ändert sich nichts“ sucht, obwohl der Wert nicht übernommen wurde. Details finden Sie in der Geheimnisverwaltung.
5. Stack-Überprüfung
Nach der Installation muss das Container-Netzwerk aktiv sein. PostgreSQL ist hier nicht enthalten – wir verwenden eine externe PG.
| Container | Rolle |
|---|---|
plantpulse-studio-web | Studio-UI (nginx :80) – statische Oberfläche + API-Proxy |
plantpulse-studio-server | Orchestrator (:5170) – Agent · Sitzungen · Bereitstellung · App-Listener (:5171) |
plantpulse-studio-agent-server | Builder Sidecar – die Codierungs-Engine, die App-Code erstellt |
plantpulse-studio-docker-proxy | Docker-Daemon-Zugang. Nur auf 127.0.0.1 geöffnet |
Auf docker.sock wird nicht direkt am Server gemountet, sondern über den Docker-Proxy zugegriffen. Um Sitzungscontainer zu erstellen und zu löschen, ist der Daemon erforderlich. Den Socket direkt weiterzugeben würde Host-weiten Vollzugriff bedeuten.
Nur der Proxy läuft nicht im Host-Netzwerk, sondern veröffentlicht auf 127.0.0.1:2375. Im Host-Netzwerk wäre 2375 ein offener Daemon, der nur durch die Firewall geschützt wäre.
Um Sitzungscontainer zu erstellen, benötigt man POST /containers/create. Wer diese API aufrufen kann, kann auch Container mit einem Mount auf / erstellen. Die Kontrolleinheit des Proxys ist der Endpunkt, nicht der Parameter.
Der Proxy hat zwei Aufgaben – die Beschneidung ungenutzter API-Oberflächen (Volumes · Secrets · Configs · Swarm · Nodes · Plugins · Systemereignisse) und die Bündelung des Daemon-Zugriffs an einem Punkt, um ihn prüfbar zu machen. Der zulässige Bereich ist auf das beschränkt, was studio-server tatsächlich benötigt (Container · Images · Builds · exec · Netzwerke · Registry-Logins).
Behandeln Sie diesen Stack daher als Teil der Vertrauensgrenze. Sie müssen davon ausgehen, dass Personen, die Apps erstellen, auch Rechte auf dem Host haben.
Zusätzlich wird beim Öffnen eines Projekts durch einen Benutzer ein App-Sitzungscontainer pro Projekt gestartet. Das ist kein Stack-Container, sondern wird bei Bedarf vom Server erstellt und nach 30 Minuten Inaktivität entfernt.
6. Startprüfung
cd /opt/kopens/plantpulse-studio-docker
bash bin/status.sh # 컨테이너 상태 + 헬스 + 세션 컨테이너 수
curl -s localhost:5170/health
Direkt nach der Installation wird empfohlen, einmal das umfassende Prüfskript auszuführen. Es prüft Health · Web-Antwort · tatsächlichen Login · Sitzungs-Runtime-Image · Container-Status und beendet sich mit einem Fehler, wenn auch nur ein Punkt fehlschlägt.
bash bin/smoke-install.sh
✓ health
✓ client-config → {"lang":"ko",...}
✓ web 200
✓ 로그인(부트스트랩 계정)
✓ 세션 런타임 이미지
✓ 컨테이너 running(...)
✅ 설치 스모크 통과
Die App-Sitzungscontainer verwenden das plantpulse-studio-runtime-Image. Wenn bin/up.sh lokal nicht vorhanden ist, wird es heruntergeladen und getaggt. Schlägt das fehl, erscheint die Warnung ⚠️ 세션 런타임 이미지 없음 und das Öffnen von Projekten schlägt fehl. Prüfen Sie in diesem Fall den Registry-Login-Status und führen Sie bash bin/up.sh erneut aus.
Wenn das Image bereits lokal vorhanden ist, wird die up.sh nicht angetastet – um auf eine neue Version zu wechseln, siehe bin/update.sh.
7. Erste Anmeldung
Greifen Sie im Browser auf http://<server-ip>/ zu.
Wenn der Server zum ersten Mal startet und kein Konto vorhanden ist, wird ein Bootstrap-Administrator in der DB angelegt.
| Element | Wert |
|---|---|
| Benutzername | admin |
| Passwort | admin123! |
Das steht auch im Boot-Log – 부트스트랩 관리자 생성: admin — 로그인 후 비밀번호를 바꿀 것.
Dieser Wert ist bei allen Installationen identisch. Ändern Sie ihn sofort nach der Anmeldung unter Einstellungen → Benutzerverwaltung (Passwort zurücksetzen, mindestens 6 Zeichen). Das Ändern der Umgebungsvariablendatei bewirkt nichts – der Server prüft bei der Anmeldung ①DB → ②Umgebungsvariable. Wenn der Wert in der DB gefunden wird, ist die Sache damit erledigt.
Nach der Anmeldung:
- Einstellungen → Benutzerverwaltung – Bootstrap-Administrator-Passwort ändern, Benutzerkonten für das Vor-Ort-Team anlegen, Rollen (Administrator / Ersteller / Betrachter) zuweisen
- Passwörter · API-Schlüssel ändern – DB-Konto und KI-Schlüssel mit
bin/passwd.shauf einmal rotieren. Das muss nur einmal bei der Inbetriebnahme gemacht werden - Einstellungen → KI – Verbindungsstatus des KI-Providers und der Schlüssel prüfen
- Einstellungen → Plattform – Plattformadresse und Schlüssel prüfen (für den Abruf von Echtzeitdaten erforderlich)
Detaillierte Bildschirmbeschreibungen finden Sie unter Erste Schritte und Einstellungen (Administrator).
8. Tägliche Betriebsbefehle
Alle Befehle werden aus dem Installationsverzeichnis (/opt/kopens/plantpulse-studio-docker) ausgeführt.
bash bin/up.sh # 시작(레지스트리에서 최신 이미지 pull 포함). 종료 코드 0 = «준비됨»
bash bin/down.sh # 중지 — 데이터는 그대로 보존, 세션 컨테이너도 정리
bash bin/restart.sh # 재기동(.env 변경 반영)
bash bin/status.sh # 상태 요약
bash bin/logs.sh # 서버 로그 팔로우(기본 studio-server)
bash bin/logs.sh studio-web # 특정 서비스 로그
bash bin/update.sh # 이미지 갱신 + 재기동 → [업데이트](#9-aktualisierung)
bash bin/remove.sh # 컨테이너·네트워크 제거. **데이터는 보존이 기본**
start.sh · stop.sh funktionieren weiterhinDie drei Produkte (Plattform · KI · Studio) wurden so konsolidiert, dass sie dieselben, gleichbedeutenden Verben verwenden – up · down · restart · status · logs · update · remove.
Die alten Namen wurden nicht entfernt. bin/start.sh und bin/stop.sh bewirken weiterhin dasselbe (die CI ruft sie direkt auf entfernten Hosts auf). Sie müssen bestehende Runbooks nicht auf einmal umstellen.
down.sh nicht nur Compose aufruftDie Sitzungscontainer (Label plantpulse-studio=1), die der Studio-Server beim Öffnen einer App erstellt, werden nicht von Compose verwaltet. Wenn Sie nur docker compose down aufrufen, laufen diese weiter – das ist die Stelle, an der man denkt „runtergefahren, aber Container laufen noch“. down.sh räumt auch diese auf.
remove.sh löscht keine Daten – zum Löschen muss es explizit angefordert werdenbash bin/remove.sh # 컨테이너·네트워크만. 데이터 그대로
bash bin/remove.sh --volumes # 데이터까지 (확인을 묻습니다)
bash bin/remove.sh --volumes --yes # 자동화용 — 묻지 않습니다
Die echten Daten dieses Stacks liegen nicht in benannten Volumes, sondern in DATA_ROOT-Bind-Mounts (Standard: /var/lib/pp-studio) – PG-Daten · Arbeitsbereiche · Build-Artefakte · Zustand. docker compose down -v löscht diese nicht, aber wenn ein Administrator „Entfernen“ sagt, meint er oft genau das. Da dies nicht rückgängig zu machen ist, wird nur auf ausdrückliche Anforderung eingegriffen.
Um nur die Sitzungscontainer anzuzeigen, verwenden Sie:
docker ps --filter label=plantpulse-studio=1
9. Aktualisierung
bin/update.sh lädt die Images neu herunter und startet den Stack neu. Wenn Sie das Installationsskript erneut ausführen, werden auch die Betriebsskripte aktualisiert (.env · Backups bleiben erhalten).
=== "Nur Images aktualisieren"
cd /opt/kopens/plantpulse-studio-docker
bash bin/update.sh
up.sh (alt: start.sh) allein bleibt die „Sitzungs-Runtime“ auf dem alten Bildup.sh bezieht die Images der Compose-Dienste. Das Sitzungs-Runtime-Image, auf dem die Benutzer-Apps tatsächlich laufen, ist kein Compose-Dienst, wird also von compose pull nicht erfasst. up.sh lädt dieses Image nur herunter, wenn es lokal nicht vorhanden ist – wenn es vorhanden ist, bleibt es unverändert.
Wenn Sie also nur up.sh ausführen, sind die restlichen Images neu, aber die Sitzungs-Runtime bleibt stillschweigend auf der alten Version. Der Unterschied zu up.sh besteht darin, dass update.sh dieses eine Image erzwungen neu herunterlädt.
=== "Pakete ebenfalls aktualisieren"
curl -fsSL https://product.kopens.io/plantpulse-studio/install.sh | sudo bash
Version festschreiben
Die Versionsangabe erfolgt im Format YYYY.MM (z. B.: 2026.08). Für Betriebsumgebungen, in denen keine automatischen Updates gewünscht sind, fixieren Sie das Tag in .env.
TAG=2026.08
Führen Sie zuerst bash bin/backup.sh aus. Das Verfahren finden Sie unter Backup und Wiederherstellung.
Image-Signaturprüfung (optional)
Sie können prüfen, ob die bereitgestellten Images von KOPENS signiert wurden. cosign muss installiert sein.
cd /opt/kopens/plantpulse-studio-docker
bash bin/verify-images.sh
[verify] ✅ docker.kopens.io/ps/plantpulse-studio-server:2026.08
[verify] ✅ docker.kopens.io/ps/plantpulse-studio-web:2026.08
[verify] ✅ docker.kopens.io/ps/plantpulse-studio-runtime:2026.08
Nächste Schritte
- Geheimnisverwaltung – KI- · Plattform-Schlüssel sicher hinterlegen
- Domain und Reverse-Proxy – Dienst über Domain und HTTPS statt IP
- Backup und Wiederherstellung – Automatische Backups und Wiederherstellungs-Übung
- Fehlerbehebung – Symptom-Ursache-Maßnahmen-Tabelle