# klickops Handbook > The complete klickops product handbook, in German. Each block below is one page; the canonical HTML lives at the URL under its heading. --- # Dein erstes Deployment Section: start URL: https://klickops.io/docs/first-deploy Reviewed against: 2026.8.7 Von der Anmeldung zum laufenden Container mit URL. Etwa fünf Minuten, ohne Kubernetes anzufassen. ## Was du brauchst Ein Container-Image, das auf einem Port lauscht. Oder ein Git-Repository, das klickops für dich baut. Sonst nichts: kein Cluster, kein kubectl, kein YAML. Willst du es einfach mal laufen sehen? `nginx:1.27-alpine` auf Port 80 startet in Sekunden und liefert eine Seite aus. ## Anmelden und die Organisation benennen Nach der Anmeldung kommt ein einziger Bildschirm. Organisation benennen, Bedingungen akzeptieren, anlegen. Der Name ist aus deinem Konto vorausgefüllt, ein Klick genügt also. Ändern kannst du ihn trotzdem, wenn deine echte Firma darauf stehen soll. In der Organisation liegen dein Tarif, deine Rechnung und deine Leute. Danach denkst du eine Weile nicht mehr daran. ## Ein Projekt anlegen Ein Projekt klammert zusammen, was zusammengehört: eine App, ihre Datenbank, ihre Domain. Benenn es nach der Sache und nicht nach der Umgebung. Also `shop` statt `production`. Getrennte Umgebungen sind meistens getrennte Projekte. ## Die App aufschalten 1. Öffne das Projekt und klick auf **Deploy an app**. 2. Wähl die Quelle. Füg eine Image-Referenz ein, oder verbinde ein Git-Repository und lass klickops bauen. 3. Prüf den Port. klickops liest das Image aus und füllt ihn vor. Der Vorschlag stimmt meistens. 4. Lass den Rest, wie er ist. Ein Replica, ein TCP-Health-Check, CPU und Memory automatisch zugeschnitten. Das sind die Standardwerte, weil sie für die meisten Apps passen. 5. Klick auf **Deploy**. Die App erscheint in der Liste. Sie wird grün, sobald der Container auf seinem Port eine Verbindung annimmt. Das dauert meistens Sekunden. > [!Hinweis] > Die Oberfläche von klickops ist englisch. Deshalb stehen Knöpfe und Tabs in diesem Handbuch so da, wie du sie im Produkt siehst. ![Zwei laufende Apps in einem Projekt. So sieht die Liste aus, wenn ein Deployment durch ist.](/handbook/apps-list.webp) ## Ins Internet stellen Öffne die App, geh auf **Domains** und schalt die klickops-Subdomain ein. Du bekommst einen Hostnamen, der sofort auflöst, mit gültigem Zertifikat und ohne DNS-Konfiguration. Deine eigene Domain liegt auf demselben Tab. Hostname hinzufügen, den angezeigten DNS-Eintrag anlegen, warten bis die Prüfung grün wird. Mehr dazu unter [Domains](/docs/domains). ## Wie es weitergeht - Gib der App eine Datenbank und lass klickops die Zugangsdaten hineinlegen, statt sie in ein Secret zu kopieren. Siehe [Datenbanken](/docs/databases). - Lies [Organisationen, Projekte, Workloads](/docs/concepts), wenn du das Modell verstehen willst, bevor du mehr baust. - Alles, was die Oberfläche kann, kann auch die CLI `klops` und die API. Nichts hier ist eine Sackgasse. > [!Vorsicht] > Der Free-Tarif umfasst ein Projekt, eine App und eine Datenbank, mit je einem Replica. Wenn du etwas Echtes baust, stösst du schnell an. Die Grenzen greifen beim Anlegen und nicht erst auf der Rechnung. --- # Organisationen, Projekte, Workloads Section: start URL: https://klickops.io/docs/concepts Reviewed against: 2026.8.7 Die drei Ebenen, an denen alles andere hängt, und wem was gehört. ## Drei Ebenen, mehr nicht | | Was es ist | Was dazugehört | | --- | --- | --- | | Organisation | Deine Firma auf klickops | Tarif, Rechnung, Personen und alle Projekte darunter | | Projekt | Eine Klammer um zusammengehörende Workloads | Apps, Datenbanken, Buckets, Scheduled Jobs, Volumes und die Netzwerkregeln dazwischen | | Workload | Eine laufende Sache | Eigene Domains, Konfiguration, Speicher und Backups | ```diagram-nest Organisation: Acme Projekt: shop App: web Datenbank: orders-db Domain: shop.example.ch Projekt: marketing App: site ``` Eine vierte Ebene gibt es nicht. Was danach aussieht, gehört zu einem Workload: Eine Domain gehört zur App, auf die sie zeigt. Ein Volume gehört zur App, die es einbindet. Ein Zertifikat gehört zu seiner Domain. ## Organisationen Die Organisation begrenzt alles, was kein laufender Container ist. Hier vergibst du Zugriff, hier gilt der Tarif, hier entsteht die Rechnung. Wer zur Organisation gehört, sieht ihre Projekte. Eine eigene Anmeldung pro Projekt gibt es nicht. Eine bekommst du bei der Anmeldung. Die meisten brauchen nie eine zweite. Eine zweite trennt wirklich: eigene Rechnung, eigene Mitglieder, nichts wird geteilt. ## Projekte Im Projekt gruppierst du, was zusammengehört. Die brauchbare Frage lautet: Sprechen die Dinge miteinander? Eine App und die Datenbank, die sie abfragt, gehören in ein Projekt. Innerhalb eines Projekts erreichen sie einander über den Namen, in einem privaten Netz, ohne dass etwas nach aussen offen ist. Zwei Punkte solltest du vorher kennen. - **Ein Workload wechselt das Projekt nicht.** Weder eine App noch eine Datenbank. Ein Projekt später zu teilen heisst, Dinge neu anzulegen. Eine Minute Nachdenken am Anfang lohnt sich. - **Wer ein Projekt löscht, löscht seinen Inhalt.** Genau dafür ist die Klammer da. Es ist auch der schnellste Weg, ein Experiment aufzuräumen. Projektnamen sind innerhalb einer Organisation eindeutig, sonst nirgends. Zwei Organisationen dürfen also beide ein Projekt `api` haben, ohne sich abzusprechen. > [!Hinweis] > Unter der Haube ist ein Projekt ein Kubernetes-Namespace mit zufälligem Namen. Jeder Workload darin ist darunter gewöhnliches Kubernetes. Das zählt, falls du je wechseln willst: Deine Ressourcen sind normale Kubernetes-Objekte und kein eigenes Format. Nimmst du die klickops-Labels weg, laufen sie einfach weiter. ## Workloads Ein Workload ist eine laufende Sache, auf die du zeigen kannst. Heute sind das eine [App](/docs/apps), eine [Datenbank](/docs/databases), ein Bucket, ein Scheduled Job oder ein Volume. Alles, was du konfigurierst, hängt an einem davon. Deshalb hat das Handbuch eine Seite pro Workload und nicht eine pro Einstellung. Suchst du, wo etwas geändert wird, fang bei der Sache an, die es betrifft. ## Benennung Namen bestehen aus Kleinbuchstaben, Ziffern und Bindestrichen. Sie sind endgültig: Projekte und Workloads lassen sich nicht umbenennen, weil der Name die Identität ist, auf die anderes verweist. Benenn nach dem, was etwas ist, nicht danach, wo es läuft. `orders-db` übersteht den Weg von Staging nach Produktion. `prod-db-v2` fängt an zu lügen, sobald sich etwas ändert. ## Grenzen Der Tarif hängt an der Organisation. Er begrenzt, wie viel du von jeder Sache bekommst: Projekte, Apps, Datenbanken, Replicas, eigene Domains sowie CPU, Memory und Speicher pro Projekt. Die Grenzen greifen beim Anlegen und nicht auf der Rechnung. Stösst du an eine, siehst du einen Fehler im Formular statt einer Überraschung später. Die aktuellen Zahlen je Tarif stehen im Produkt auf der Tarif-Seite. --- # Apps Section: workloads URL: https://klickops.io/docs/apps Reviewed against: 2026.8.7 Ein Container, den du ausrollst, skalierst und auf eine Domain legst. Der Ausgangspunkt für alles andere im Projekt. ## Was das ist Eine App ist ein Container-Image, das in deinem Projekt läuft, mit den Replicas, Ressourcen, Volumes und Netzwerkeinstellungen, die dazugehören. Fast alles andere auf der Plattform hängt an einer App: Eine Domain zeigt auf eine App, ein Volume wird in eine App eingebunden, eine Datenbank legt ihre Zugangsdaten in eine App. klickops fängt beim Container-Image an. Deinen Code baut es nur, wenn du ein Repository verbindest. Eine eigene Pipeline betreibt es nicht. Hast du schon ein Image, bist du zwei Minuten von einer URL entfernt. ## Wann du das brauchst - Du hast ein Container-Image und willst es mit Hostname und TLS betreiben. - Du hast ein Git-Repository und willst, dass klickops es für dich baut. - Du ersetzt einen docker-compose-Dienst oder einen Heroku-Dyno durch etwas, das einen Node-Neustart übersteht. > [!Nicht dafür] > Eine Aufgabe, die nach Zeitplan läuft und sich dann beendet, ist ein Scheduled Job und keine App. Apps sollen laufen. Ein Container, der sich sauber beendet, wird deshalb neu gestartet. ## Eine App ausrollen 1. Öffne dein Projekt, geh auf **Apps** und dann auf **Deploy app**. 2. Wähl die Quelle: entweder ein Container-Image oder ein Repository, das klickops für dich baut. Fügst du eine Image-Referenz ein, liest klickops das Image aus und füllt Port, Startbefehl und die deklarierten Umgebungsvariablen vor. 3. Bestätige den Port, auf dem deine App lauscht. Der Vorschlag kommt aus dem Image und stimmt meistens. 4. Leg die Zahl der Replicas fest. Eines ist der Standard und lässt sich später ohne neues Deployment ändern. CPU und Memory wählst du nicht: klickops schneidet sie auf den tatsächlichen Verbrauch zu. 5. Füg eine Domain hinzu, wenn die App gleich öffentlich sein soll. Du kannst das auch überspringen und später im Tab **Domains** nachholen. 6. Prüf und rolle aus. Die App erscheint in der Liste mit Live-Status, während der Rollout läuft. ![Die Apps-Liste eines Projekts, mit Status und Ressourcenverbrauch pro App.](/handbook/apps-list.webp) ## Der Alltag Jede App öffnet auf **Overview**. Die Tab-Leiste darüber ist die ganze Oberfläche. | Tab | Was dort liegt | | --- | --- | | Overview | Status, aktuelles Image, letzte Versionen, Rollback | | Logs | Ausgabe des Containers, live und historisch | | Metrics | CPU, Memory, Neustarts, Anfragen | | Scaling | Zahl der Replicas und Autoscaling | | Domains | Hostnamen, TLS, Weiterleitungen, Zugriffsmodus | | Firewall | Wer diese App erreichen darf und was sie erreichen darf | | Configuration | Umgebungsvariablen, Secrets, Verknüpfungen | | Storage | Volumes, die in den Container eingebunden sind | | Builds | Erscheint, wenn die App aus einem Repository gebaut wird | | Previews | Umgebungen pro Pull Request, wenn ein Repository verbunden ist | | Shell | Eine interaktive Sitzung im laufenden Container | | Backups | Wiederherstellungspunkte für die App und ihre Volumes | | Advanced | Notausgänge, inklusive Rohansicht der Ressourcen | ## Einstellungen im Überblick | Einstellung | Standard | Was sie bewirkt | | --- | --- | --- | | Image | keines | Container-Image und Tag. Änderst du es, läuft ein Rollout. Der Bestätigungsdialog zeigt alt und neu. | | Port | aus dem Image | Der Port, auf dem dein Container lauscht. Services und Domains leiten dorthin. | | Replicas | 1 | Wie viele Instanzen laufen. Auf null zu skalieren stoppt die App, ohne sie zu löschen. | | Autoscaling | aus | Fügt Replicas zwischen Unter- und Obergrenze hinzu, je nach CPU-Last. | | CPU und Memory | automatisch | klickops schneidet beides auf den tatsächlichen Verbrauch zu. Du wählst keine Grösse. | | Health-Check | an, TCP | Datenverkehr wartet, bis der Port eine Verbindung annimmt. Ein TCP-Check braucht keinen Health-Endpunkt. Hast du einen, stell auf HTTP um. | | Als Nicht-Root ausführen | an | Verhindert, dass der Container als Root läuft. Images, die Root brauchen, müssen sich ausdrücklich abmelden. | | Update-Richtlinie | manuell | Ob klickops ein neues Image-Tag ausrollt, sobald die Registry es veröffentlicht. | ## Grenzen und Fallstricke - **Ein Rollout ist nicht sofort da.** klickops wartet, bis die neuen Replicas ihren Health-Check bestehen, und zieht erst dann die alten ab. Ein kaputtes Image lässt also die vorherige Version weiterlaufen. - **Auf null skalieren behält den Speicher.** Die App kostet keine Rechenzeit mehr, der Speicher läuft weiter. - **Die Shell ist kein Deployment-Weg.** Was du im laufenden Container änderst, ist beim nächsten Rollout weg. Leg es ins Image oder in die Konfiguration. - **Änderungen an der Konfiguration starten die App neu.** Das Speicherband nennt die Zahl der betroffenen Replicas, bevor du bestätigst. > [!Vorsicht] > Wer eine App löscht, löscht ihre Volumes mit, sofern er sie vorher nicht löst. Der Dialog listet genau auf, was mitgeht. ## Verwandt - [Domains](/docs/domains) gibt der App einen Hostnamen und ein Zertifikat. - [Datenbanken](/docs/databases) legt ihre Zugangsdaten direkt in die App. - Speicher, der einen Rollout übersteht, liegt auf einem Volume und wird im Tab **Storage** eingebunden. --- # Datenbanken Section: workloads URL: https://klickops.io/docs/databases Reviewed against: 2026.8.7 Eine verwaltete PostgreSQL- oder Valkey-Instanz im Projekt. Wird nach Zeitplan gesichert und ist von deinen Apps über den Namen erreichbar. ## Was das ist Eine Datenbank in klickops ist eine verwaltete Instanz, die du auf der Seite **Databases** eines Projekts anlegst. klickops betreibt sie, spielt Patches ein, überwacht sie und erstellt die Backups. Du bekommst eine Verbindungszeichenfolge und eine Konsole. Nichts davon liegt ausserhalb des Projekts. Löschst du das Projekt, löschst du die Datenbank mit. Zwei Engines stehen heute zur Wahl. **PostgreSQL** ist die vollständige, mit Replicas, Connection Pooling, Extensions und Wiederherstellung auf die Sekunde genau. **Valkey** ist eine einzelne In-Memory-Instanz für Caches, Sessions und Queues, bewusst ohne Replikation und ohne Backups. ## Wann du das brauchst - Deine App braucht eine Datenbank und du willst keine betreiben. - Du willst die Zugangsdaten in die App legen lassen, statt sie von Hand in ein Secret zu kopieren. - Du wechselst von einem gehosteten Anbieter und willst die Daten dort haben, wo dein Projekt liegt. > [!Nicht dafür] > Brauchst du eine Datenbank, die das Projekt überdauert, oder eine, die sich mehrere Projekte teilen? Dann leg sie in einem eigenen Projekt an und erreich sie über eine Firewall-Regel. Zwischen Projekten verschieben lässt sie sich nach dem Anlegen nicht. ## Eine Datenbank anlegen 1. Öffne dein Projekt, geh auf **Databases** und dann auf **Add database**. 2. Wähl die Engine. PostgreSQL setzt die Standardwerte unten. Valkey wechselt auf die Cache-Standardwerte und lässt den Backup-Schritt weg. 3. Leg die Grösse fest. Der Speicher ist ein Schieberegler, auf dem die Obergrenze deines Tarifs eingezeichnet ist. CPU und Memory folgen der Grösse und lassen sich später ohne Datenverlust ändern. 4. Entscheide über die Zahl der Instanzen. **PostgreSQL startet mit drei**, einer primären und zwei Replicas. Genau das lässt sie den Ausfall eines Nodes überstehen. Für eine Entwicklungsdatenbank stellst du auf eine, dann sinken auch die Kosten. 5. Wähl ein Backup-Ziel. Tägliche Backups sind bei PostgreSQL an, und ohne Bucket lässt sich der Assistent nicht abschliessen. 6. Leg sie an. Die Instanz ist meistens in weniger als zwei Minuten bereit. Die Seite zeigt die Phase, während sie hochfährt. ![Die Datenbanken-Liste eines Projekts, mit den verfügbaren Engines darunter.](/handbook/databases-list.webp) ## Eine App verbinden Öffne die Datenbank, geh auf **Connect** und wähl die App. klickops schreibt Host, Port, Datenbankname, Benutzer und Passwort als Verknüpfung in die App. Wird das Passwort später gewechselt, aktualisiert sich die App von selbst. Die Zugangsdaten stehen auf demselben Tab, falls du sie lokal brauchst. Das Passwort bleibt verdeckt, bis du es aufdeckst. Die API gibt es in keiner Listenantwort zurück. ```bash # eine psql-Sitzung über klickops, ohne lokalen Postgres-Client klops db query orders-db --project shop -c "select count(*) from orders" ``` ## Der Alltag Jede Datenbank öffnet auf **Overview**. Die Tab-Leiste darüber ist die ganze Oberfläche. Valkey zeigt eine kürzere: dort steht eine Befehlskonsole statt eines SQL-Editors, und einen Backup-Tab gibt es nicht. | Tab | Was dort liegt | | --- | --- | | Connect | Zugangsdaten, App-Verknüpfungen, Connection Pooler | | Query | SQL gegen die Instanz ausführen. Valkey zeigt eine Befehlskonsole | | Browse | Tabellen und Zeilen, nur lesend | | Data & backups | Zeitplan, Wiederherstellungspunkte, Dump-Import und -Export | | Storage | Das Volume vergrössern. Speicher wächst und schrumpft nie | | Updates | Kleine Patches und Wechsel auf eine neue Hauptversion | | Metrics | Verbindungen, Cache-Trefferrate, Speicherplatz, CPU | | Logs | Logs der Instanz, live und historisch | | Advanced | Extensions, Server-Parameter, TLS, Zugriffsregeln für Clients | ## Einstellungen im Überblick | Einstellung | Standard | Was sie bewirkt | | --- | --- | --- | | Version | PostgreSQL 16, Valkey 8.1 | Vorausgewählt, damit der Name das einzige Pflichtfeld bleibt. Kleine Patches kommen im Wartungsfenster. Ein Wechsel der Hauptversion ist ein eigener Schritt, den du vorher freigibst. | | Speicher | 10 GB | Grösse des Volumes. Wächst im laufenden Betrieb, schrumpft nie. Die Obergrenze deines Tarifs ist auf dem Regler eingezeichnet. | | Instanzen | 3 bei PostgreSQL, 1 bei Valkey | Drei Nodes sind der Standard: eine primäre, zwei Replicas, automatische Übernahme. Eine einzelne Instanz kostet ein Drittel und übersteht den Ausfall eines Nodes nicht. | | Connection Pooler | aus | Setzt PgBouncer vor die Instanz. Schalt ihn ein, wenn du mehr Clients als Verbindungen hast. | | Backups | an, täglich, 7 Tage | Nur PostgreSQL, und es braucht ein Ziel-Bucket, bevor etwas laufen kann. Zusätzlich werden die Write-Ahead-Logs gesichert, du kommst also auf jede Sekunde im Zeitfenster zurück. Valkey hat gar keine Backups. | | Extensions | keine | PostgreSQL-Extensions wie `postgis` oder `pgvector`. Eine zu installieren startet die Instanz neu. | | Parameter | Standard der Engine | Server-Parameter. Die meisten Änderungen starten die Instanz neu. Das Speicherband sagt es, bevor du bestätigst. | | TLS | erforderlich | Ob Clients über TLS verbinden müssen. Lass es an. | | Update-Richtlinie | automatisch | Ob klickops kleine Patches selbst einspielt oder auf deinen Klick wartet. | ## Grenzen und Fallstricke - **Speicher wächst nur.** Schrumpfen gibt es nicht. Plan für ein Jahr, nicht für ein Jahrzehnt. - **Valkey hat keine Backups.** Es ist ein Cache. Behandle alles darin als verzichtbar. - **PostgreSQL-Backups brauchen ein Ziel.** Sie sind standardmässig an, geschrieben wird aber nichts, bevor du ein Bucket angibst. - **Ein Wechsel der Hauptversion ist einseitig.** Der Plan zeigt, was sich ändert, und legt vorher ein Backup an. Zurück geht es danach nicht. - **Die Instanz ist aus dem Internet nicht erreichbar.** Apps im selben Projekt erreichen sie über den Namen. Alles andere braucht eine Firewall-Regel. > [!Vorsicht] > Wer eine Datenbank löscht, löscht ihr Volume und ihre Backups. Der Dialog verlangt den Namen zum Eintippen, weil es danach nichts rückgängig zu machen gibt. Exportier im Zweifel vorher einen Dump. ## Verwandt - [Apps](/docs/apps) ist üblicherweise das, was sich hier verbindet, über den Tab **Configuration**. - [Domains](/docs/domains), falls du etwas veröffentlichst, das damit spricht. --- # Buckets Section: workloads URL: https://klickops.io/docs/buckets Reviewed against: 2026.8.7 S3-kompatibler Objektspeicher für Dateien, die eine App nicht auf ihrer eigenen Platte halten soll. ## Was das ist Ein Bucket ist Objektspeicher, der die S3-API spricht. Deine App schreibt Dateien mit einem beliebigen S3-Client hinein, und die Dateien liegen ausserhalb des Containers, ausserhalb einer einzelnen Maschine und ausserhalb des Lebenszyklus der App. Buckets stehen im Projekt neben den Datenbanken als zweite Art von verwaltetem Zustand. Ein [Volume](/docs/volumes) ist eine Platte an einer App. Ein Bucket ist ein Dienst, den mehrere Dinge lesen und beschreiben können. ## Wann du das brauchst - Uploads von Nutzern, erzeugte PDFs, Exporte: alles, was ein Browser später herunterlädt. - Dateien, die mehr als eine App sehen muss. - Alles, was ein Volume unbegrenzt wachsen lassen würde. > [!Nicht dafür] > Objektspeicher ist kein Dateisystem. Es gibt keine echten Verzeichnisse, keine Teilschreibvorgänge und kein Anhängen an eine Datei. Code, der in einer Datei auf der Platte herumspringen will, braucht ein Volume. ## Einen anlegen 1. Öffne das Projekt, geh auf **Buckets** und dann auf **Add bucket**. 2. Gib ihm einen Namen und eine Grösse. 3. Leg ihn an. Er ist in Sekunden bereit, denn es fährt kein Cluster hoch. ## Eine App verbinden Öffne den Bucket und geh auf **Access**. Du bekommst einen Endpunkt, einen Access Key und einen Secret Key: die vier Werte, nach denen jeder S3-Client fragt. Übergib sie der App so, wie du jede andere Zugangsdaten übergibst. Der Secret Key verhält sich wie jedes Secret in klickops. Er wird gezeigt, wenn du danach fragst, und kommt in keiner Listenantwort zurück. ## Einstellungen im Überblick | Einstellung | Standard | Was sie bewirkt | | --- | --- | --- | | Name | keiner | Identifiziert den Bucket. Endgültig. | | Grösse | vom Regler | Das Speicherkontingent. | | Versionierung | aus | Behält alte Fassungen eines überschriebenen Objekts. Ein falscher Schreibvorgang bleibt so rettbar. | | Lifecycle | aus | Löscht Objekte automatisch nach einer Zahl von Tagen. | ## Grenzen und Fallstricke - **Versionierung ist aus und wirkt nicht rückwirkend.** Schalt sie ein, bevor das Überschreiben passiert, das du bereust, nicht danach. - **Lifecycle löscht wirklich.** Eine Ablaufregel ist eine geplante Löschung, und sie fragt nicht noch einmal nach. - **Einen riesigen Bucket aufzulisten ist langsam.** Der Tab **Objects** ist zum Nachschauen da, nicht zum Verwalten von Millionen Keys. Für Massenarbeit nimmst du einen S3-Client. - **Buckets stecken nicht in den Wiederherstellungspunkten des Projekts.** Ihre Haltbarkeit kommt von der Speicherschicht darunter. ## Verwandt - [Volumes](/docs/volumes) für eine Platte an einer App. - [Secrets](/docs/secrets), falls du die Keys lieber als Umgebungsvariablen übergibst. --- # Volumes Section: workloads URL: https://klickops.io/docs/volumes Reviewed against: 2026.8.7 Platte, die einen Rollout übersteht, eingebunden in eine App an einem Pfad deiner Wahl. ## Was das ist Das eigene Dateisystem eines Containers ist bei jedem Neustart weg. Ein Volume ist es nicht: Es behält seinen Inhalt über Neustarts, Rollouts und Image-Wechsel hinweg und erscheint im Container an einem Pfad, den du wählst. Ein Volume entsteht, indem du es an einen Workload hängst, nicht für sich allein. Es gibt kein leeres Volume, das auf Adoption wartet. So hat jedes Volume einen Besitzer, und du weisst immer, was kaputtgeht, wenn du es löschst. ## Wann du das brauchst - Uploads von Nutzern, die eine App auf die Platte schreibt. - Ein Cache oder Index, dessen Neuaufbau teuer ist, der aber keine Datenbank rechtfertigt. - Jedes Verzeichnis, das nach einem Deployment noch da sein muss. > [!Nicht dafür] > Zwei Apps können nicht auf dasselbe Volume schreiben. Brauchen sie gemeinsamen Zustand, ist das eine Datenbank oder ein Bucket. Eine geteilte Platte, um zwei Container zu koordinieren, ist der Anfang eines schlechten Nachmittags. ## Eines an eine App hängen 1. Öffne die App und geh auf **Storage**. 2. Füg ein Volume hinzu: Name, Grösse und der Pfad, an dem es im Container erscheinen soll. 3. Speichere. Die App startet einmal neu, das Volume hängt dran, und das Verzeichnis ist beim ersten Mal leer. Die Grösse kommt von einem Schieberegler mit der Obergrenze deines Tarifs, nicht aus einem Textfeld. Ein Tippfehler bei einer Speichergrösse ist in beide Richtungen teuer. ![Die Volumes-Liste eines Projekts, mit Grösse und dem, was sie einbindet.](/handbook/volumes-list.webp) ## Vergrössern Öffne das Volume und zieh die Grösse hoch. Es wächst im laufenden Betrieb, die App läuft weiter, und der neue Platz steht bereit, sobald das Dateisystem mitgezogen hat. Verkleinern gibt es nicht. Kubernetes bietet es nicht an, also klickops auch nicht. Kleiner werden heisst: zweites Volume anlegen, kopieren, Mount umhängen. ## Einstellungen im Überblick | Einstellung | Standard | Was sie bewirkt | | --- | --- | --- | | Name | keiner | Identifiziert das Volume im Projekt. Endgültig. | | Grösse | vom Regler | Wie viel Platte. Wächst im Betrieb, schrumpft nie. | | Mount-Pfad | keiner | Wo das Volume im Container erscheint, zum Beispiel `/data`. | | Backup | aus | `fs` kopiert die Dateien, `snapshot` nutzt die Snapshots der Speicherschicht, wo der Cluster sie unterstützt. | ## Grenzen und Fallstricke - **Speicher wächst nur.** Plan für ein Jahr, nicht für ein Jahrzehnt. - **Ein Schreiber.** Ein Volume hängt an einer App. Skalierst du die über ein Replica hinaus, braucht es Speicher, der das unterstützt, oder eine andere Form von Zustand. - **Der Mount verdeckt, was da war.** Hängst du an einen Pfad, den das Image schon befüllt hat, sind dessen Dateien unsichtbar und nicht etwa gemischt. Häng an ein leeres Verzeichnis. - **Backups sind aus, bis du sie einschaltest.** Ein Volume ohne Backup ist genau so haltbar wie die Platte darunter. > [!Vorsicht] > Wer eine App löscht, löscht ihre Volumes mit, sofern er sie vorher nicht löst. Und wer ein Volume löscht, löscht die Daten ohne Rückweg. Der Dialog listet auf, was mitgeht. ## Verwandt - [Apps](/docs/apps) ist das, was ein Volume einbindet. - [Datenbanken](/docs/databases) bringen ihren Speicher selbst mit und brauchen kein Volume. --- # Scheduled Jobs Section: workloads URL: https://klickops.io/docs/scheduled-jobs Reviewed against: 2026.8.7 Ein Container, der nach Zeitplan läuft, seine Arbeit macht und sich beendet. ## Was das ist Ein Scheduled Job ist ein Container, den klickops nach Fahrplan startet. Er läuft, wird fertig und verschwindet bis zum nächsten Mal. Jeder Start ist ein Run, mit eigenem Exit-Code und eigenen Logs, so lange aufbewahrt, wie du willst. Das ist das Gegenstück zur App. Eine App soll laufen und wird neu gestartet, wenn sie sich beendet. Ein Job soll sich beenden, und Weiterlaufen ist der Fehlerfall. ## Wann du das brauchst - Ein nächtlicher Export, ein Rechnungslauf, ein Aufräumjob. - Ein wiederkehrender Abruf bei einer fremden API. - Eine Migration, die du auf einem Timer laufen lassen willst statt von Hand. > [!Nicht dafür] > Arbeit, die auf ein Ereignis reagiert statt auf eine Uhrzeit, ist kein Scheduled Job. Ein Queue-Consumer, der immer zuhören muss, ist eine App. ## Einen anlegen 1. Öffne das Projekt, geh auf **Scheduled jobs** und dann auf **New scheduled job**. 2. Gib ihm einen Namen und das Image, das laufen soll. Ein Kommando ist optional. Ohne eines läuft der Entrypoint des Images. 3. Setz den Zeitplan. Er ist ein Cron-Ausdruck, und der Standard `0 * * * *` bedeutet zu jeder vollen Stunde. Die Seite zeigt die nächsten Läufe im Klartext, damit du prüfen kannst, ob der Ausdruck meint, was du denkst. 4. Lass die Ressourcen auf automatisch, ausser du weisst, dass der Job schwer ist. 5. Leg ihn an. Er erscheint mit seiner nächsten Laufzeit und wartet. ![Die Liste der Scheduled Jobs, mit den nächsten 24 Stunden und dem letzten Ergebnis pro Job.](/handbook/scheduled-jobs-list.webp) ## Beobachten Öffne den Job. Der Tab **Runs** listet jeden Start mit Ergebnis und Dauer. Jeder Run behält seine eigenen Logs, und das ist der Unterschied zwischen "hat nicht geklappt" und zu wissen, warum. Du kannst jederzeit einen Run von Hand starten. Der läuft sofort, ohne den Zeitplan anzufassen. So testest du die Sache, bevor du sie einem Timer anvertraust. ## Einstellungen im Überblick | Einstellung | Standard | Was sie bewirkt | | --- | --- | --- | | Zeitplan | `0 * * * *` | Cron-Ausdruck. Standardmässig stündlich. | | Zeitzone | die des Clusters | Nach welcher Uhr der Zeitplan geht. Setz sie, wenn dein Job lokale Mitternacht meint. | | Concurrency | Allow | Was passiert, wenn ein Run noch läuft und der nächste ansteht. `Forbid` lässt ihn aus, `Replace` beendet den alten. | | Aufbewahrte Runs | 3 erfolgreiche, 1 fehlgeschlagener | Wie viel Verlauf und wie viele Logs bleiben. | | Ressourcen | automatisch | CPU und Memory. Zieh sie hoch für einen Job, der echte Arbeit macht. | | Pausiert | nein | Hält den Zeitplan an, ohne den Job zu löschen. | ## Grenzen und Fallstricke - **`Allow` ist der Standard und bedeutet Überlappung.** Ein Job, der länger dauert als sein Intervall, läuft doppelt. Ist das unsicher, setz `Forbid`. - **Ein verpasstes Fenster wird nicht nachgeholt.** Konnte der Cluster einen Run nicht starten, ist dieser Termin weg und steht nicht in einer Warteschlange. - **Logs verschwinden mit ihrem Run.** Die Aufbewahrung bestimmt, wie weit du zurückschauen kannst, und standardmässig bleiben nur die letzten drei Erfolge. - **Ein Job, der sich nie beendet, blockiert den nächsten** unter `Forbid` und stapelt sich unter `Allow`. Gib langen Jobs ein eigenes Timeout. ## Verwandt - [Apps](/docs/apps) für Arbeit, die durchgehend laufen muss. - [Secrets](/docs/secrets), falls der Job Zugangsdaten braucht. --- # Domains Section: networking URL: https://klickops.io/docs/domains Reviewed against: 2026.8.7 Ein Hostname, der auf deine App zeigt, mit einem TLS-Zertifikat, das für dich ausgestellt und erneuert wird. ## Was das ist Eine Domain ist die öffentliche Adresse einer App. Du gibst klickops einen Hostnamen und die zugehörige App. klickops leitet den Verkehr dorthin, stellt ein Zertifikat aus und erneuert es, bevor es abläuft. Im Container richtest du dafür nichts ein. ```diagram-flow Besucher -> DNS -> klickops -> Deine App ``` Jede Domain gehört zu genau einer App. Das ist Absicht: Ein Hostname ist eine Eigenschaft der App, auf die er zeigt. Deshalb verwaltest du ihn im Tab **Domains** der App und nicht in einer eigenen Liste von Routing-Regeln. ## Wann du das brauchst - Deine App soll aus dem Browser erreichbar sein. - Du willst HTTPS, ohne eine Zertifikatsdatei anzufassen. - Du ziehst einen Hostnamen von einem anderen Anbieter um und willst, dass das Zertifikat schon da ist, bevor du das DNS umstellst. > [!Nicht dafür] > Um eine andere Anwendung im selben Projekt zu erreichen, brauchst du keine Domain. Apps in einem Projekt erreichen einander über den Namen im internen Netz. Einem internen Dienst einen öffentlichen Hostnamen zu geben vergrössert nur seine Angriffsfläche. ## Zu einem Hostnamen kommen Es gibt zwei Wege. Der erste kommt ganz ohne DNS aus. **Eine klickops-Subdomain.** Schalt sie ein, und klickops vergibt eine unter seiner eigenen Wildcard. Sie löst sofort auf, mit bereits gültigem Zertifikat. Im gehosteten Betrieb ist das Label eine zufällige Zeichenfolge und nicht der Name deines Projekts, damit nichts über deine Mandanten im öffentlichen DNS landet. Selbst betriebene Installationen nutzen die lesbare Form `app.projekt.deine-basis-domain`. **Deine eigene Domain.** Hostname hinzufügen, dann auf klickops zeigen lassen. 1. Öffne die App, geh auf **Domains** und füg den Hostnamen hinzu, der dir gehört. 2. klickops zeigt dir den DNS-Eintrag, den du anlegen musst: ein `CNAME` für eine Subdomain, oder den Adresseintrag für eine Apex-Domain. 3. Leg diesen Eintrag bei deinem DNS-Anbieter an. Ein Wildcard-`CNAME` deckt alle Subdomains auf einmal ab, falls du weitere planst. 4. Warte, bis die Prüfung grün wird. klickops fragt das DNS ab und stellt das Zertifikat aus, sobald der Eintrag auflöst. Das dauert meistens ein bis zwei Minuten. > [!Hinweis] > Füg die Domain hinzu, bevor du produktiven Verkehr umlegst. Das Zertifikat entsteht, sobald das DNS auflöst. Stellst du erst nach der grünen Prüfung um, sieht kein Besucher je eine Warnung. ## Einstellungen im Überblick | Einstellung | Standard | Was sie bewirkt | | --- | --- | --- | | Hostname | keiner | Der Name, den Besucher eintippen. Eine Domain-Ressource pro Hostname. | | App | erforderlich | Welche App den Verkehr bekommt, und auf welchem Port. | | TLS | an | Stellt ein Zertifikat aus und erneuert es. Lass es an. | | Weiterleitung auf HTTPS | an | Schickt unverschlüsselte Anfragen auf die sichere Adresse. | | Zugriff | öffentlich | `public` bedient alle. `sso` setzt eine Anmeldung davor. Ein internes Werkzeug braucht damit keinen eigenen Anmeldecode. | | Pfad | `/` | Leitet nur ein Präfix auf diese App, wenn sich mehrere Apps einen Hostnamen teilen. | ## Grenzen und Fallstricke - **Ein Hostname, eine Domain-Ressource.** Der vorgelagerte Controller führt zwei Definitionen desselben Hosts nicht zusammen. Ein doppelter Hostname wird deshalb abgelehnt statt stillschweigend halb übernommen. - **Zertifikate brauchen öffentliches DNS.** Der Aussteller prüft über das Internet, dass dir der Name gehört. Ein Hostname, der nur intern auflöst, bekommt kein öffentliches Zertifikat. - **Apex-Domains brauchen einen Adresseintrag.** Die meisten DNS-Anbieter können auf einer Apex-Domain kein `CNAME` setzen. Nutz ihren Alias-Eintrag, oder zeig mit `www` auf klickops und leite die Apex-Domain dorthin weiter. - **Eine Domain zu entfernen wirkt sofort.** Der Verkehr endet im Moment des Löschens. Verschieb also zuerst das DNS, wenn der Name produktiv ist. ## Verwandt - [Apps](/docs/apps) ist das, worauf eine Domain zeigt. - Eine Domain gibt der App eine Adresse. Wer sie benutzen darf, regelt die Projekt-Firewall. --- # Firewall Section: networking URL: https://klickops.io/docs/firewall Reviewed against: 2026.8.7 Wer deine Workloads erreichen darf und was sie erreichen dürfen. Standardmässig zu, mit drei Schaltern für den Rest. ## Was das ist Jedes Projekt startet geschlossen. Von aussen kommt niemand hinein, und was hinausgeht, bestimmen drei Schalter, die dir gehören. Auf dieser Grundlage schreibst du Regeln für den Verkehr, den du wirklich willst. ```diagram-flow Internet -> Domain -> App -> Datenbank ``` Dieser Weg funktioniert ab Werk. Alles, was nicht darauf liegt, braucht eine Regel. Genau das ist der Sinn: Ein Workload, dem niemand Zugriff gegeben hat, ist ein Workload, den niemand erreicht. ## Wann du das brauchst - Ein zweites Projekt soll die Datenbank von diesem erreichen. - Eine App muss eine externe API aufrufen, während das Projekt sonst dicht ist. - Du willst belegen, dir selbst oder einer Revision, womit ein Workload tatsächlich sprechen kann. ## Die drei Standardwerte | Schalter | Standard | Was Ausschalten bedeutet | | --- | --- | --- | | Talk to project apps | an | Workloads im Projekt erreichen einander nicht mehr. Deine App verliert ihre Datenbank. | | Resolve names (DNS) | an | Nichts im Projekt löst noch Namen auf. Fast alles bricht, inklusive allem, was an einem Hostnamen hängt. | | Reach the internet | an | Keine ausgehenden Verbindungen ins öffentliche Internet. Ein abgeschottetes Projekt, was eine echte und laute Anforderung ist. | Diese Schalter gelten projektweit. Schaltest du einen aus, gilt das für jeden Workload. Behandle sie als Haltung und nicht als Regler. > [!Vorsicht] > **Resolve names (DNS)** auszuschalten bricht mehr, als es aussieht. Namen lösen nirgends mehr auf, und die Fehler zeigen sich als Timeouts an unbeteiligten Stellen statt als klare Ablehnung. ![Die Seite Network: die drei Grundschalter über dem Verkehr, den jeder Workload tatsächlich erzeugt hat.](/handbook/network.webp) ## Eine Regel schreiben Öffne **Network** und leg eine Policy an. Eine Regel benennt Quelle, Ziel und Port, und sie wirkt additiv: Regeln erlauben nur, sie nehmen nie etwas weg. Willst du etwas wegnehmen, schaltest du einen Standardwert aus. klickops kann Regeln auch aus beobachtetem Verkehr **ableiten**. Statt zu raten, womit eine App spricht, lässt du sie laufen und lässt dir dann die Regeln vorschlagen, die zu den gesehenen Flows passen. Lies sie durch, bevor du sie übernimmst: Beobachteter Verkehr enthält, was passiert ist, und nicht nur, was passieren sollte. ## Sehen, was läuft Die Ansicht **Flows** zeigt laufende Verbindungen zwischen Workloads, auch die abgelehnten. Die abgelehnte ist die nützliche: Sie sagt dir genau, welche Regel fehlt, statt dich aus einem Timeout raten zu lassen. ## Grenzen und Fallstricke - **Verkehr im Projekt ist durch diese Regeln nicht verschlüsselt.** Die Firewall entscheidet, wer verbinden darf, nicht wie die Verbindung aussieht. - **Regeln erlauben nur.** Ist etwas erreichbar und soll es nicht sein, schau bei den Standardwerten nach und nicht bei einer weiteren Policy. - **Ablehnungen sehen aus wie Hänger.** Eine blockierte Verbindung läuft meistens in einen Timeout statt abgewiesen zu werden. Eine rätselhaft langsame Anfrage lohnt darum einen Blick in Flows. - **Das braucht Cilium im Cluster.** Ohne Cilium sind die Schalter nur lesbar und spiegeln, was an Policies vorhanden ist, statt es zu steuern. ## Verwandt - [Domains](/docs/domains) ist der Weg, auf dem Verkehr überhaupt von aussen hereinkommt. - [Apps](/docs/apps) haben je einen eigenen Firewall-Tab für Regeln, die nur sie betreffen. --- # Deployment aus Git Section: delivery URL: https://klickops.io/docs/git Reviewed against: 2026.8.7 Verbinde ein Repository und lass klickops das Image bauen. Dann wird aus einem Push ein Deployment. ## Was das ist klickops fängt beim Container-Image an. Ein verbundenes Repository ergänzt den Schritt davor: klickops klont deinen Code, baut ein Image, schiebt es in seine eigene Registry und rollt es aus. Aus einem Push auf den gewählten Branch wird eine neue laufende Version. Ein CI-System ist das nicht. Es gibt keine Pipelines, keine Stages, keine Build-Matrix und keinen Ort, an dem deine Tests laufen. Brauchst du das, behalt dein CI und lass es ein Image schieben. klickops rollt dieses genauso gern aus. ## Wann du das brauchst - Du hast ein Repository und kein Image und willst keinen Build-Workflow pflegen. - Ein Push auf `main` soll ohne Handgriff in der Produktion landen. - Du willst pro Pull Request eine Umgebung zum Anschauen, bevor du mergst. > [!Nicht dafür] > Braucht dein Build Secrets, eigene Toolchains oder eine Testsuite, die zuerst grün sein muss, gehört das in dein CI. Bau dort, schieb das Image, und zeig klickops darauf. ## Ein Repository verbinden 1. Geh in der Organisation auf **Repos** und verbinde deinen Anbieter. GitHub läuft über eine App-Installation, klickops sieht also nie ein Passwort. 2. Wähl das Repository und seinen Default-Branch. 3. klickops schaut sich den Code an und schlägt vor, wie er gebaut wird. Übernimm den Vorschlag oder überschreib ihn. Ab dann steht das Repository jedem Projekt der Organisation zur Verfügung. Eine zweite App aus demselben Code braucht keine zweite Verbindung. ```diagram-flow Push auf deinen Branch -> klickops baut -> Image in der Registry -> Neue Version läuft ``` ## Wie gebaut wird | Builder | Wann er greift | Was er braucht | | --- | --- | --- | | Buildpacks | Standard. Kein Dockerfile im Repository. | Nichts. Die Sprache wird erkannt und ein Produktions-Image entsteht. | | Dockerfile | Ein Dockerfile liegt da, oder du wählst es. | Dein Dockerfile. klickops baut es so, wie es dasteht. | Builds laufen im Cluster, isoliert und ohne Root. Das Ergebnis landet in der Registry, die klickops betreibt. Dein Image verlässt die Plattform also nicht, ausser du hast eine eigene Registry eingerichtet. ## Einen Build verfolgen Die Seite **Builds** eines Projekts listet jeden Build mit Status und vollem Log. Ein fehlgeschlagener Build lässt die laufende Version in Ruhe. Genau das ist die nützliche Eigenschaft: Ein kaputter Commit reisst die Produktion nicht mit. ## Einstellungen im Überblick | Einstellung | Standard | Was sie bewirkt | | --- | --- | --- | | Branch | der Default des Repositories | Von welchem Branch ein Push ausrollt. | | Subpath | Wurzel des Repositories | Baut aus einem Unterverzeichnis, für ein Monorepo. | | Builder | buildpacks | Wie das Image entsteht. | | Previews | aus | Baut und rollt pro Pull Request eine Umgebung aus und räumt sie beim Schliessen ab. | ## Grenzen und Fallstricke - **Ein Push rollt den gewählten Branch aus und sonst nichts.** Arbeit auf anderen Branches baut nichts, solange Previews aus sind. - **Der erste Build ist der langsame.** Spätere Builds nutzen Layer wieder und sind deutlich schneller. - **Build-Logs hängen am Build.** Ist ein Build aus der Liste verschwunden, ist sein Log mit weg. - **Previews kosten, was sie laufen lassen.** Jeder offene Pull Request ist eine laufende Umgebung. Ein Repository mit zwanzig davon sind zwanzig Umgebungen. ## Verwandt - [Apps](/docs/apps) ist das, was ein Build am Ende ausrollt. - [Secrets](/docs/secrets) für Werte, die die laufende App braucht. Secrets zur Build-Zeit gibt es nicht. --- # Backups und Wiederherstellung Section: operations URL: https://klickops.io/docs/backups Reviewed against: 2026.8.7 Geplante Wiederherstellungspunkte für ein Projekt, und wie du ein einzelnes Stück zurückholst, ohne den Rest anzufassen. ## Was das ist Ein Wiederherstellungspunkt ist eine Kopie eines Projekts zu einem Zeitpunkt: die Workloads, ihre Konfiguration und der Inhalt der Volumes, die mitmachen. klickops legt sie nach einem Zeitplan an, den du setzt, und behält sie so lange, wie du sagst. Backups konfigurierst du pro Projekt und nicht pro Workload. Eine Wiederherstellung, die eine App zurückholt, aber nicht das Volume, in das sie schreibt, ist keine Wiederherstellung. ## Wann du das brauchst - Jemand hat das Falsche gelöscht. - Ein Deployment hat Daten beschädigt und du brauchst gestern. - Du willst eine Kopie der Produktion zum Herumprobieren, ohne die Produktion anzufassen. > [!Nicht dafür] > Ein Backup ist kein Datenbank-Backup. PostgreSQL führt eigene Write-Ahead-Logs und stellt auf die Sekunde genau wieder her, feiner als alles hier. Siehe [Datenbanken](/docs/databases). Diese Seite deckt alles drumherum ab. ## Einschalten 1. Öffne das Projekt und geh auf **Backups**. 2. Wähl einen Rhythmus: stündlich, alle sechs Stunden, täglich oder wöchentlich. Täglich läuft um 02:00. 3. Leg fest, wie lange die Punkte bleiben. 4. Speichere. Der erste Wiederherstellungspunkt entsteht zum nächsten Termin, oder sofort, wenn du einen von Hand auslöst. Volumes sind nicht dabei, bis du es sagst. Jedes Volume hat seine eigene Backup-Einstellung. So kostet ein Cache-Volume nichts, während das Uploads-Volume geschützt ist. Das ist Absicht: geschützter Speicher wird verrechnet, und die meisten Projekte haben Volumes, deren Inhalt nichts wert ist. ## Wiederherstellen Eine Wiederherstellung hat einen Umfang. Du wählst, was zurückkommt: - **Das ganze Projekt.** Alles aus dem Wiederherstellungspunkt. - **Eine App.** Ihre Ressourcen und die Volumes, die sie einbindet. - **Ein Volume.** Nur diese Platte, über den Namen. ```diagram-nest Wiederherstellungspunkt: shop, 02:00 Ganzes Projekt zurückholen App: web Volume: uploads App: api Datenbank: orders-db Eine App zurückholen App: web Volume: uploads Ein Volume zurückholen Volume: uploads ``` Du wählst ausserdem, was mit dem passiert, was jetzt da ist. Eine Wiederherstellung kann **unter neuem Namen** zurückkommen. Dann läuft das Original weiter und du vergleichst die beiden. Das ist fast immer der richtige erste Schritt, wenn du unsicher bist, und der Unterschied zwischen Wiederherstellen und Wetten. Der Fortschritt läuft live auf der Seite, Schritt für Schritt, und eine laufende Wiederherstellung lässt sich abbrechen. ## Einstellungen im Überblick | Einstellung | Standard | Was sie bewirkt | | --- | --- | --- | | Rhythmus | aus | stündlich, 6h, täglich (02:00) oder wöchentlich. | | Aufbewahrung | keine | Wie lange Wiederherstellungspunkte bleiben, bevor sie verfallen. | | Volume-Backup | aus, pro Volume | `fs` kopiert die Dateien, `snapshot` nutzt die Speicherschicht, wo der Cluster das unterstützt. | | Umfang | ganzes Projekt | Auf benannte Apps oder Volumes einengen. | | Unter neuem Namen | aus | Holt die Kopie neben das Original statt darüber. | ## Grenzen und Fallstricke - **Ein Volume ohne Backup ist nicht im Wiederherstellungspunkt.** Der Projekt-Zeitplan deckt es nicht stillschweigend mit ab. Prüf jedes Volume, dessen Inhalt dir fehlen würde. - **Backups taugen so viel wie die letzte Wiederherstellung, die du geprobt hast.** Mach einmal absichtlich eine unter neuem Namen, bevor du eine im Ernstfall brauchst. - **Über das Original wiederherzustellen zerstört.** Genau das bedeutet die Option, und dahinter gibt es kein zweites Rückgängig. - **Aufbewahrung löscht.** Ein Punkt jenseits der Aufbewahrung ist weg. Die Aufbewahrung ist also eine Entscheidung über den schlimmsten Datenverlust und keine Aufräumeinstellung. > [!Vorsicht] > Wer ein Projekt löscht, löscht seine Wiederherstellungspunkte mit. Räumst du etwas auf, das später zählen könnte, hol vorher heraus, was du brauchst, oder exportier es. ## Verwandt - [Volumes](/docs/volumes) entscheiden einzeln, ob sie geschützt sind. - [Datenbanken](/docs/databases) führen eigene Backups nach eigenem Zeitplan. --- # Wenn etwas nicht läuft Section: operations URL: https://klickops.io/docs/troubleshooting Reviewed against: 2026.8.7 Die Handvoll Fehler, die die meisten ausmachen, woran du sie erkennst und was zu tun ist. ## Fang hier an klickops versucht, in einem Satz am Workload selbst zu sagen, was los ist. Lies also zuerst die Statuszeile. Danach den Tab **Logs**, denn dort steht der Bericht des Containers über sein eigenes Ende. Drei Fragen klären das meiste. Ist er je gestartet? Ist er gestartet und dann gestorben? Oder läuft er und ist bloss nicht erreichbar? Das sind verschiedene Probleme, und die Abschnitte unten folgen dieser Reihenfolge. ## Er startet gar nicht **Das Image lässt sich nicht ziehen.** Der Name stimmt nicht, der Tag existiert nicht, oder die Registry braucht Zugangsdaten, die klickops nicht hat. Prüf die genaue Referenz, und bei einer privaten Registry, ob [Pull-Credentials](/docs/registries) hinterlegt sind. Ein Tippfehler im Tag sieht genauso aus wie ein fehlendes Image. **Die Projekt-Quota blockiert ihn.** Der Status sagt das direkt: im Projekt ist nicht genug CPU oder Memory übrig, um ihn zu starten. Entweder du entfernst einen Workload oder du erhöhst die Quota. Eine so abgelehnte Datenbank bleibt für immer in einer Provisioning-Phase stehen, weil der Operator nie einen Pod bekommt, über den er berichten könnte. **Die Tarifgrenze hat abgelehnt.** Das scheitert schon beim Anlegen, mit einer Meldung, die die Grenze benennt. Also sofort sichtbar statt als Hänger. Siehe [Tarif und Kosten](/docs/billing). ## Er startet und stirbt **Er beendet sich sauber.** klickops startet ihn neu, weil eine App laufen soll. Wenn die Sache wirklich einmal laufen und fertig sein soll, ist sie ein [Scheduled Job](/docs/scheduled-jobs) und keine App. **Er stürzt beim Start ab.** Der Grund steht in den Logs des gescheiterten Versuchs, und es ist meistens eines von drei Dingen: eine fehlende Umgebungsvariable, eine Datenbank, die er noch nicht erreicht, oder ein falscher Port. Prüf, ob der konfigurierte Port der ist, auf dem der Prozess tatsächlich lauscht. **Ihm geht der Speicher aus.** Der Container wird beendet und neu gestartet, und die Zahl der Neustarts klettert weiter. Memory wird auf den tatsächlichen Verbrauch zugeschnitten, ein Prozess, der wirklich mehr braucht, bekommt also mehr. Ein Leck wird schlicht wiederholt beendet. > [!Hinweis] > Ein gescheiterter Rollout reisst die laufende Version nicht mit. klickops wartet, bis die neuen Kopien ihren Health-Check bestehen, und zieht erst dann die alten ab. Ein kaputtes Image lässt also die vorherige Version weiterlaufen. Die App sieht ungesund aus, während sie es erneut versucht, und deine Nutzer merken nichts. ## Er läuft, ist aber nicht erreichbar **Prüf zuerst den Health-Check.** Datenverkehr wartet, bis der Port eine Verbindung annimmt. Ein Prozess, der auf einem anderen Port lauscht als dem konfigurierten, ist von innen gesund und von aussen unsichtbar. **Dann DNS.** Löst der Hostname nicht auf, wurde nie ein Zertifikat ausgestellt und die Domain-Prüfung nie grün. Siehe [Domains](/docs/domains). **Dann die Firewall.** Eine blockierte Verbindung läuft in einen Timeout statt abgewiesen zu werden, das sieht also nach Langsamkeit aus und nicht nach Ablehnung. Die Ansicht Flows zeigt abgelehnten Verkehr ausdrücklich, und das geht schneller als raten. Siehe [Firewall](/docs/firewall). ## Eine Datenbank hängt im Provisioning Gib ihr zwei Minuten: ein PostgreSQL-Cluster braucht die wirklich zum Hochfahren. Danach ist die übliche Ursache die Projekt-Quota, siehe oben. Meldet sie sich gesund und deine App kommt trotzdem nicht dran, liegt es fast nie an der Datenbank. Prüf, ob die App die Verknüpfung hat und ob beide im selben Projekt liegen, denn über eine Projektgrenze geht nichts ohne Firewall-Regel. ## Wann du fragst Wenn du den Namen des Workloads hast, den Zeitpunkt, ab dem es schiefging, und die genaue Meldung. Diese drei machen aus einem Gespräch eine Antwort. ## Verwandt - [Backups und Wiederherstellung](/docs/backups), wenn die Lösung zurück statt vorwärts heisst. - [Apps](/docs/apps) dazu, was jeder Tab zeigt. --- # Alerts und Benachrichtigungen Section: operations URL: https://klickops.io/docs/alerts Reviewed against: 2026.8.7 Erfahren, wenn ein Workload in Schwierigkeiten ist, und festlegen, wo diese Nachricht ankommt. ## Zwei Hälften **Alerts** entscheiden, wann etwas sagenswert ist, und werden pro Projekt eingestellt. **Kanäle** entscheiden, wo es gesagt wird, und gehören der Organisation, damit mehrere Projekte sich einen teilen können. Allein tut keines von beiden etwas. Ein Alert ohne Kanal ist eine Regel, die niemand hört. Ein Kanal ohne Alert ist ein Rohr, durch das nichts kommt. ## Einen Kanal einrichten 1. Geh in der Organisation auf **Notifications**. 2. Leg einen Kanal an: Slack, E-Mail, einen allgemeinen Webhook, Teams, Telegram oder Discord. 3. Schick eine Testnachricht. Mach das jetzt, statt mitten in einer Störung festzustellen, dass die Webhook-URL falsch war. ## Schwellwerte wählen Alerts feuern auf anhaltenden Druck und nicht auf eine einzelne Spitze. Es gibt drei: | Alert | Feuert, wenn | | --- | --- | | CPU | Die Auslastung dauerhaft über dem Schwellwert bleibt | | Memory | Der Verbrauch dauerhaft über dem Schwellwert bleibt | | Volume | Ein Volume über den Schwellwert hinaus volläuft | Beim Volume lohnt sich Sorgfalt am meisten. Druck auf CPU und Memory macht einen Workload langsam. Eine volle Platte bringt ihn zum Stehen und nimmt oft die Daten mit. > [!Vorsicht] > Schwellwerte, auf die du nie reagierst, erziehen dich dazu, den Kanal zu ignorieren. Wenn ein Alert seit einem Monat wöchentlich feuert und niemand etwas tut, heb entweder den Schwellwert an oder repariere den Workload. Ein lauter Kanal ist schlimmer als keiner, weil er den einen verdeckt, auf den es ankommt. ## Einstellungen im Überblick | Einstellung | Standard | Was sie bewirkt | | --- | --- | --- | | Aktiv | aus | Ob dieses Projekt überhaupt Alerts sendet. | | CPU-Schwellwert | Prozent | Anhaltende CPU-Last darüber benachrichtigt. | | Memory-Schwellwert | Prozent | Anhaltender Verbrauch darüber benachrichtigt. | | Volume-Schwellwert | Prozent | Ein Volume, das darüber hinaus volläuft, benachrichtigt. | | Kanal | keiner | Wohin die Nachricht geht. Wird pro Organisation eingerichtet. | ## Grenzen und Fallstricke - **Alerts gelten pro Projekt.** Ein neues Projekt hat keine, und das überrascht regelmässig beim ersten Mal, wenn etwas leise kaputtgeht. - **Kanäle gelten pro Organisation.** Wer einen entfernt, macht jedes Projekt stumm, das ihn benutzt hat. - **Das ist keine Verfügbarkeitsüberwachung.** Alerts beschreiben deine Workloads von innen. Ob ein Besucher deine Seite erreicht, ist eine andere Frage, die eine externe Prüfung besser beantwortet. - **Es wird niemand angepiepst.** Eine Nachricht landet in einem Kanal. Sie eskaliert nicht und weckt niemanden. ## Verwandt - [Volumes](/docs/volumes), die Ressource, deren Alert am meisten zählt. - [Wenn etwas nicht läuft](/docs/troubleshooting) dazu, was zu tun ist, wenn einer feuert. --- # Secrets Section: configuration URL: https://klickops.io/docs/secrets Reviewed against: 2026.8.7 Werte, die deine Workloads brauchen und niemand zurücklesen soll: Passwörter, API-Keys, Tokens. ## Was das ist Ein Secret ist ein Wert, den klickops verschlüsselt ablegt und dem Workload zur Laufzeit übergibt, ohne ihn dir je wieder zu zeigen. Konfiguration, die niemand verstecken muss, liegt daneben unter **Configuration**. Der Unterschied liegt in der Vertraulichkeit, nicht im Format. Secrets gehören zum Projekt. Ein Satz, den alle Workloads im Projekt teilen. Denn ein API-Key, den zwei Apps brauchen, ist ein Key und nicht zwei Kopien, die auseinanderlaufen. ## Wann du das brauchst - Ein API-Key eines Drittanbieters, ein SMTP-Passwort, ein Signing-Token. - Zugangsdaten, die du rotierst und an einer einzigen Stelle ändern willst. - Alles, was du ungern auf einem Screenshot finden würdest. > [!Nicht dafür] > Datenbank-Zugangsdaten gehören nicht hierhin. Eine Datenbank übergibt ihre Verbindungsdaten selbst als Verknüpfung an die App, und die wandert beim Passwortwechsel mit. Kopierst du sie in ein Secret, hast du eine zweite Kopie, die veraltet. Siehe [Datenbanken](/docs/databases). ## Ein Secret anlegen 1. Öffne das Projekt und geh auf **Configuration**. 2. Leg einen Key und seinen Wert an. Keys sind gross geschrieben, mit Unterstrichen, so wie Umgebungsvariablen aussehen. 3. Speichere. Workloads, die das Secret nutzen, starten neu. Das Speicherband nennt die Zahl, bevor du bestätigst. Ab diesem Moment ist der Wert nur noch schreibbar. Ersetzen kannst du ihn, zurücklesen nicht. Nicht in der Oberfläche, nicht über die API, nicht in einer Listenantwort. Verlierst du ihn, rotier ihn an der Quelle. ![Die Seite Configuration eines Projekts, mit Key-Namen und verdeckten Werten.](/handbook/secrets-list.webp) ## Ein Secret in einem Workload nutzen Öffne die App, geh auf **Configuration** und wähl die Keys aus, die sie bekommen soll. Jeder kommt als Umgebungsvariable unter seinem eigenen Namen an. Ein Workload bekommt nur, was du auswählst. Der geteilte Satz sorgt für eine einzige Kopie und nicht dafür, dass jeder alles sieht. ## Einstellungen im Überblick | Einstellung | Standard | Was sie bewirkt | | --- | --- | --- | | Key | keiner | Der Name der Umgebungsvariable. Gross, mit Unterstrichen, eindeutig im Projekt. | | Wert | keiner | Nur schreibbar. Ersetzbar, nie lesbar. | | Genutzt von | keinem | Welche Workloads diesen Key bekommen. Änderst du das, starten sie neu. | ## Grenzen und Fallstricke - **Zurücklesen geht nicht.** Genau das ist der Sinn, und es überrascht jeden einmal. Halte die Quelle dort, wo die Zugangsdaten ausgestellt wurden. - **Ein geändertes Secret startet neu, was es nutzt.** Ein Container liest seine Umgebung beim Start. Im laufenden Betrieb lässt sich das nicht ändern. - **Ein Secret ist keine Datei.** Zertifikate und Konfigurationsdateien, die auf der Platte liegen müssen, bindest du als Volume ein. - **Ein gelöschter Key bricht, was ihn erwartet.** Der Workload startet neu und die Variable fehlt einfach. Das zeigt sich meistens als Absturz beim Start und nicht als klare Meldung. ## Verwandt - [Apps](/docs/apps) bekommen Secrets als Umgebungsvariablen. - [Datenbanken](/docs/databases) liefern ihre Zugangsdaten selbst und brauchen kein Secret. --- # Pull-Credentials und Build-Registry Section: configuration URL: https://klickops.io/docs/registries Reviewed against: 2026.8.7 Woher klickops Images holt, die es nicht anonym erreicht, und wo gebaute Images landen. ## Zwei verschiedene Dinge Sie klingen ähnlich und tun das Gegenteil voneinander. | | Was es ist | Richtung | | --- | --- | --- | | Pull-Credentials | Zugangsdaten für eine Registry, in der deine Images liegen | klickops liest daraus | | Build-Registry | Wohin klickops Images legt, die es für dich baut | klickops schreibt dorthin | Die meisten Projekte brauchen beides nicht. Öffentliche Images brauchen keine Zugangsdaten, und Builds landen in der Registry, die klickops selbst betreibt, solange du nichts anderes angibst. ## Pull-Credentials Die brauchst du, wenn ein Deployment scheitert, weil das Image nicht geholt werden kann, und das Image privat ist. Ein öffentliches Image, das sich nicht holen lässt, hat ein anderes Problem, meistens einen Tippfehler im Tag. 1. Geh in der Organisation auf **Registries**. 2. Trag den Registry-Host ein, dazu Benutzer und Token. Nimm ein Token oder einen Deploy-Key statt eines Passworts, denn das kannst du widerrufen, ohne deine eigene Anmeldung zu ändern. 3. Rolle erneut aus. Apps der Organisation können jetzt Images von diesem Host nutzen. Das Token liegt als Secret und wird nie zurückgezeigt, genau wie jedes andere [Secret](/docs/secrets). ## Die Build-Registry Wenn klickops aus einem Repository baut, muss das entstandene Image irgendwo liegen. Standardmässig ist das die Registry, die klickops selbst betreibt, und nichts verlässt die Plattform. Zeig woandershin, wenn deine eigenen Systeme diese Images auch ziehen müssen, oder wenn eure Vorgaben sagen, dass Artefakte in eure eigene Registry gehören. Du gibst Host und Zugangsdaten mit Schreibrecht an, und Builds landen dort. ## Einstellungen im Überblick | Einstellung | Standard | Was sie bewirkt | | --- | --- | --- | | Host | keiner | Der Hostname der Registry, etwa `ghcr.io` oder `registry.example.com`. | | Benutzer | keiner | Das Konto oder der Roboter, der zieht. | | Token | keines | Nur schreibbar. Ersetzbar, nie lesbar. | | Build-Registry | klickops-intern | Wohin gebaute Images geschoben werden. | ## Grenzen und Fallstricke - **Zugangsdaten gelten pro Organisation, nicht pro Projekt.** Wer eine hinterlegt, stellt sie jedem Projekt der Organisation zur Verfügung. - **Eine geänderte Build-Registry verschiebt keine alten Images.** Bestehende Deployments ziehen weiter von dort, wo ihr Image tatsächlich liegt. - **Ein rotiertes Token bricht das Ziehen still, bis zum nächsten Mal.** Laufende Workloads laufen weiter, weil das Image schon auf dem Node liegt. Der Fehler zeigt sich beim nächsten Deployment oder Neustart. - **Manche Registries brauchen den vollen Pfad, nicht nur den Host.** Scheitert ein Pull trotz korrekter Zugangsdaten, prüf, ob die Referenz das Projekt- oder Namespace-Segment enthält, das die Registry erwartet. ## Verwandt - [Apps](/docs/apps) ist der Ort, an dem ein privates Image benutzt wird. - [Deployment aus Git](/docs/git) ist das, was in die Build-Registry schiebt. --- # Mitglieder und Rollen Section: organization URL: https://klickops.io/docs/members Reviewed against: 2026.8.7 Wer in deiner Organisation ist und was jede Person tun darf. ## Was das ist Wer in klickops überhaupt etwas sieht, ist Mitglied einer Organisation mit genau einer Rolle. Diese Rolle entscheidet, was die Person in jedem Projekt der Organisation tun darf. Es gibt drei, und das ist Absicht. Die meisten Zugriffsfragen beantwortet ein "darf diese Person etwas ändern". Wer eine vierte Rolle vermisst, will meistens die Projekte trennen. | Rolle | Darf | Darf nicht | | --- | --- | --- | | Viewer | Alles sehen: Workloads, Logs, Metriken, die Key-Namen der Konfiguration | Etwas ändern | | Editor | Alles wie ein Viewer, dazu ausrollen, ändern, neu starten, wiederherstellen, Workloads löschen | Mitglieder, Abrechnung oder Organisationseinstellungen verwalten | | Admin | Alles | nichts | ## Wann du das brauchst - Jemand kommt dazu und braucht Zugriff. - Eine externe Person soll Logs sehen, aber die Produktion nicht anfassen. - Jemand geht, und der Zugriff soll mitgehen. ## Jemanden einladen 1. Geh in der Organisation auf **Members** und lad per E-Mail-Adresse ein. 2. Wähl die Rolle. Nimm die kleinste, mit der die Person ihre Arbeit machen kann. Höherstufen ist später ein Klick. 3. Die Person nimmt an und landet in der Organisation. Eine Einladung ist kein Zugriff. Bis sie angenommen ist, ist nichts gewährt, und du kannst sie in der Zwischenzeit zurückziehen. ![Die Seite Members einer Organisation, mit der Rolle jeder Person.](/handbook/members.webp) ## Zugriff auf ein Projekt einengen Eine Rolle gilt für die ganze Organisation. Soll jemand nur an ein Projekt, vergib eine Rolle für dieses Projekt. Sie überschreibt die Organisationsrolle für dieses eine Projekt. Nutz das sparsam. Über projektweise Ausnahmen wird ein Zugriffsmodell zu etwas, das niemand mehr überblickt. Zwei Organisationen sind oft die klarere Antwort. ## Einstellungen im Überblick | Einstellung | Standard | Was sie bewirkt | | --- | --- | --- | | Rolle | viewer | Die organisationsweite Berechtigungsstufe. | | Projektrolle | keine | Überschreibt die Organisationsrolle für ein Projekt. | | Einladung | offen | Gewährt nichts, bis sie angenommen ist. Jederzeit widerrufbar. | ## Grenzen und Fallstricke - **Entfernen wirkt sofort.** Die Sitzungen der Person hören auf zu funktionieren, und was sie gestartet hat, läuft weiter. - **Ein Editor darf ein Projekt löschen.** Das ist dieselbe Macht wie eines anzulegen, und es löscht den Inhalt. Ist das zu viel, ist die Person ein Viewer mit Editor-Rechten auf den Projekten, wo sie sie braucht. - **Rollen stapeln sich nicht.** Die grosszügigere Vergabe gewinnt, statt sich zu kombinieren. - **Die Abrechnung sehen nur Admins.** Ein Editor sieht nicht, was die Organisation ausgibt. > [!Vorsicht] > Der letzte Admin lässt sich nicht entfernen. Eine Organisation ohne Admin kann niemand mehr verwalten. Stuf also zuerst jemanden hoch. ## Verwandt - [Organisationen, Projekte, Workloads](/docs/concepts) dazu, was eine Organisation enthält. - [Tarif und Kosten](/docs/billing) liegt auf derselben Ebene und ist Admins vorbehalten. --- # Tarif und Kosten Section: organization URL: https://klickops.io/docs/billing Reviewed against: 2026.8.7 Wofür verrechnet wird, wo du es siehst, und wie die Grenzen des Tarifs mit der Rechnung zusammenhängen. ## Was das ist Der Tarif hängt an der Organisation. Er setzt die Grenzen und enthält jeden Monat ein Guthaben. Was du tatsächlich laufen lässt, wird gegen dieses Guthaben gemessen, und was darüber hinausgeht, wird verrechnet. Zwei Zahlen zählen, und sie beantworten verschiedene Fragen. **Grenzen** beantworten "darf ich das anlegen", und sie greifen im Formular. **Verbrauch** beantwortet "was kostet das", und er läuft auf, während die Dinge laufen. ## Was gemessen wird | Gemessen | Wie | | --- | --- | | Compute | CPU und Memory, die deine Workloads tatsächlich brauchen, über die Zeit | | Speicher | Die Grösse der Volumes und Datenbanken, die du angelegt hast | | Geschützter Speicher | Volumes mit eingeschaltetem Backup, getrennt gezählt, weil Kopien zu behalten mehr kostet als eine zu behalten | Ein Workload auf null skaliert kostet keine Rechenzeit mehr und weiter Speicher. Das ist der günstigste Weg, etwas zu parken, das du noch nicht löschen willst. ## Wo du nachschaust - **Billing** zeigt die laufende Periode: enthaltenes Guthaben, verbrauchtes Guthaben, Hochrechnung. - **Usage** schlüsselt das nach Projekt und Workload auf. Eine Überraschung hat damit eine Adresse. - **Statements** ist der Verlauf, unbegrenzt aufbewahrt. Letzter März steht also noch da. ![Die Seite Billing: enthaltenes Guthaben, Verbrauch und Hochrechnung für die Periode.](/handbook/billing.webp) ## Grenzen und der Tarif Jeder Tarif begrenzt dieselben Dinge: wie viele Projekte, Apps und Datenbanken, wie viele Replicas pro App, wie viele eigene Domains, und wie viel CPU, Memory und Platte ein einzelnes Projekt insgesamt nutzen darf. Eine erreichte Grenze ist ein abgelehntes Anlegen mit einer Meldung, die die Grenze benennt. Kein stiller Fehlschlag und keine Überraschung auf der Rechnung. Der Free-Tarif ist bewusst klein: ein Projekt, eine App, eine Datenbank, je ein Replica. > [!Vorsicht] > Grenzen werden beim Anlegen geprüft. Ein Wechsel auf einen kleineren Tarif schaltet deshalb nichts ab. Was läuft, läuft weiter, und du kannst nichts Neues anlegen, bis du wieder unter der Grenze bist. ## Einstellungen im Überblick | Einstellung | Wo | Was sie bewirkt | | --- | --- | --- | | Tarif | Billing | Setzt alle Grenzen und das enthaltene Guthaben. | | Guthaben | Billing | Monatlich enthalten, wird vom Verbrauch aufgebraucht, bevor etwas verrechnet wird. | | Projekt-Quota | Quotas | Wie viel CPU, Memory und Platte ein Projekt nutzen darf, innerhalb der Obergrenze des Tarifs. | ## Grenzen und Fallstricke - **Speicher kostet, ob genutzt oder nicht.** Ein 100-GB-Volume mit 2 GB Inhalt kostet 100 GB, denn der Platz ist für dich reserviert. - **Backups sind auch Speicher.** Schutz für ein grosses Volume einzuschalten verändert die Rechnung. Deshalb ist er standardmässig aus. - **Nur Löschen beendet Speicherkosten.** Auf null zu skalieren beendet nur die Rechenzeit. - **Das alles sehen nur Admins.** Editoren können Dinge anlegen, die Geld kosten, und sehen nicht, was sie kosten. ## Verwandt - [Organisationen, Projekte, Workloads](/docs/concepts) dazu, worauf der Tarif angewendet wird. - [Mitglieder und Rollen](/docs/members) dazu, wer die Rechnung sehen darf. --- # Hilfe bekommen Section: organization URL: https://klickops.io/docs/support Reviewed against: 2026.8.25 Stell dem klickops-Team eine Frage direkt aus dem Produkt. Wir sehen deine Projekte bereits, du musst also nie ein Log hineinkopieren. ## Was das ist **Get help** in der oberen Leiste öffnet eine Support-Anfrage. Sie geht ans klickops-Team, und das ganze Gespräch läuft im Produkt: Du siehst die Antwort auf deiner Help-Seite und bekommst sie zusätzlich per Mail. Interessant ist, was die Anfrage mitnimmt. klickops kennt deine Umgebung bereits, deshalb hält eine Anfrage fest, **wo du warst**, statt eine Kopie von dem, was auf deinem Bildschirm stand: Organisation, Projekt, der Workload, den du angeschaut hast, und die Version, die lief. Wenn wir deine Anfrage öffnen, lesen wir deinen tatsächlichen Zustand in diesem Moment, live. Darum gibt es im Formular keine Stelle für ein Log, und darum reicht ein Satz meistens aus. ## Wann du das brauchst - Etwas ist kaputt und die Fehlermeldung sagt dir nicht, was du ändern sollst. - Du bist unsicher, ob eine Einstellung wirklich das tut, was du denkst. - Die Produktion steht und du willst jetzt einen Menschen daran haben. > [!Not this] > Eine fehlende Funktion ist ein Feature Request, keine Support-Anfrage. Die gehören auf die [Roadmap](/roadmap), wo andere Kundinnen und Kunden dafür stimmen können, und genau diese Stimmen bestimmen die Reihenfolge. ## Eine Anfrage stellen 1. Drück **Get help** in der oberen Leiste, egal auf welcher Seite du gerade bist. Von der kaputten Sache aus zu starten ist besser als vom Dashboard, denn die Anfrage zeigt dann direkt darauf. 2. Schreib in einer Zeile, was nicht stimmt, dann ein paar Sätze Detail: was du erwartet hast, was stattdessen passiert ist und seit wann. 3. Wähl, wie dringend es ist. **Production is down** überholt alles andere in der Warteschlange, heb dir das also für echte Ausfälle auf. 4. Häng einen Screenshot an, wenn es etwas zu sehen gibt. Direkt aus der Zwischenablage einfügen, hineinziehen oder eine Datei wählen. Bis zu drei. Musst du erst einen machen, minimiere das Fenster statt es zu schliessen: Was du geschrieben hast, bleibt erhalten. 5. Abschicken. Du landest auf der Anfrage und bekommst eine Mail, sobald wir antworten. ## Solange sie offen ist **Get help** listet deine Anfragen ebenfalls auf, und ein Punkt auf dem Knopf heisst, dass wir geantwortet haben. Jede Anfrage sagt, wer am Zug ist: | Status | Was das heisst | | --- | --- | | With support | Wir haben sie und schulden dir eine Antwort. | | We replied | Eine Antwort wartet auf dich. | | Resolved | Geschlossen. Eine Antwort öffnet sie wieder. | Antworte im Thread genauso wie beim ersten Mal, Screenshots inklusive. Wenn es erledigt ist, schliesst **Mark resolved** die Anfrage, und beide Seiten können sie später wieder öffnen. ## Was wir sehen Solange eine Anfrage offen ist, kann der Support dein Projekt so öffnen, wie du es siehst: Workloads, Pods, Events, Logs und die Empfehlungen zur Gesundheit deines Projekts. Genau das erlaubt uns zu antworten, ohne dich um Kopien zu bitten. Zwei Dinge sehen wir nicht. **Deine Secrets** gibt die API niemandem zurück, uns eingeschlossen. Und **was auf deinem Bildschirm steht**, weshalb der Screenshot der einzige Anhang ist, nach dem das Formular fragt. > [!Careful] > Ein Support-Thread ist für dich und das klickops-Team sichtbar, für sonst niemanden in deiner Organisation. Kolleginnen und Kollegen können deine Anfragen nicht lesen. Soll jemand übernehmen, leite die Antwort weiter statt den Link zu teilen. ## Grenzen und Stolpersteine - **Eine Anfrage gehört zu einer Organisation.** Sie nimmt die, in der du gerade arbeitest, wenn du den Knopf drückst. Bist du in der falschen, wechsle zuerst. - **Mail läuft nur in eine Richtung.** Eine Antwort auf die Benachrichtigungsmail erreicht uns nicht. Der Link darin öffnet den Thread, und der schon. - **Screenshots werden verkleinert.** Dein Browser skaliert sie vor dem Hochladen herunter, damit sie lesbar und klein bleiben. Schneide lieber auf den interessanten Teil zu, statt einen ganzen 4K-Bildschirm zu schicken. - **Eine minimierte Anfrage übersteht einen Reload, ihre Screenshots nicht.** Der Text kommt zurück, Bilder musst du neu anhängen. ## Verwandt - [Pläne und Kosten](/docs/billing) deckt Fragen zur Abrechnung ab, die du meist schneller selbst beantwortest. - [Mitglieder und Rollen](/docs/members) ist der Ort, an dem du änderst, wer was darf, statt uns zu fragen. --- # Projekt- und Organisationseinstellungen Section: organization URL: https://klickops.io/docs/settings Reviewed against: 2026.8.7 Die zwei Einstellungsseiten, was jede ändert, und die drei Aktionen ohne Rückweg. ## Wo was liegt Einstellungen sitzen auf der Ebene, die sie betreffen. Die eines Projekts ändern dieses Projekt, die einer Organisation jedes Projekt darunter. Das meiste aus dem Alltag steht gar nicht hier, sondern beim Workload, den es betrifft. Domains liegen an der App, Backups auf der Backups-Seite des Projekts, Secrets unter Configuration. Einstellungen sind für das, was die Klammer beschreibt, nicht ihren Inhalt. ## Projekteinstellungen Anzeigename und Beschreibung, beides kosmetisch und jederzeit änderbar. Der Name des Projekts selbst lässt sich nicht ändern, weil anderes darauf verweist. Zwei Aktionen haben Folgen: **In eine andere Organisation verschieben.** Das Projekt wandert mit seinen Workloads, und Tarif, Abrechnung und Mitglieder des Ziels übernehmen. Nützlich, wenn ein Projekt der Organisation entwächst, in der es angefangen hat. **Das Projekt löschen.** Alles darin geht mit: Apps, Datenbanken, Volumes und die Wiederherstellungspunkte. Der Dialog verlangt den Projektnamen zum Eintippen, weil dahinter nichts mehr kommt. > [!Vorsicht] > Ein gelöschtes Projekt nimmt seine Wiederherstellungspunkte mit. Ein Backup rettet dich hier also nicht. Wenn du davon später noch etwas willst, hol es vorher heraus oder exportier es. ## Organisationseinstellungen | Abschnitt | Was er setzt | | --- | --- | | Details | Den Anzeigenamen der Organisation | | Quota-Standards | Wie viel CPU, Memory und Platte ein neues Projekt bekommt, innerhalb der Obergrenze des Tarifs | | Registries | Pull-Credentials und Build-Registry. Siehe [Pull-Credentials](/docs/registries) | | Notifications | Die Kanäle, in denen Alerts landen. Siehe [Alerts](/docs/alerts) | Die Quota-Standards lohnen Verständnis. Sie gelten für danach angelegte Projekte und nicht rückwirkend. Wer sie anhebt, macht damit kein bestehendes Projekt grösser. Das änderst du am Projekt selbst. ## Grenzen und Fallstricke - **Namen sind endgültig, Anzeigenamen nicht.** Was eine URL, ein Label oder ein anderer Workload referenziert, lässt sich nicht umbenennen. - **Quota-Standards wirken nicht rückwirkend.** Ein neuer Standard gilt für neue Projekte. - **Ein Verschieben ändert, wer zahlt.** Tarif und Grenzen der Ziel-Organisation greifen sofort. Ein Projekt, das in einen kleineren Tarif zieht, kann über den Grenzen liegen und nichts Neues mehr anlegen. - **Diese Seiten sehen nur Admins.** Ein Editor darf in einem Projekt alles ausrollen und es nicht umbenennen. ## Verwandt - [Organisationen, Projekte, Workloads](/docs/concepts) dazu, wem was gehört. - [Tarif und Kosten](/docs/billing) für die Obergrenze, in der die Quota-Standards sitzen. - [Mitglieder und Rollen](/docs/members) dazu, wer diese Seiten öffnen darf. --- # klops CLI Section: tools URL: https://klickops.io/docs/cli Reviewed against: 2026.8.7 Alles, was die Oberfläche kann, aus dem Terminal oder aus einem Skript. ## Was das ist `klops` ist die Kommandozeile von klickops. Sie spricht dieselbe REST-API wie die Oberfläche, alles Klickbare ist also skriptbar. Es gibt keinen zweiten Funktionsumfang und nichts, was die Oberfläche kann und die CLI nicht. Sie spricht mit klickops und sonst mit nichts. Kein kubeconfig, keine direkten Datenbankverbindungen, kein `kubectl` auf deinem Rechner. Das ist Absicht: Zugriffskontrolle, Audit und TLS bleiben an einer Stelle, und dein Laptop braucht keine Cluster-Zugangsdaten. ## Wann du das brauchst - Ein Deployment aus einem Skript oder aus deinem eigenen CI. - Logs lesen oder eine Abfrage laufen lassen, ohne den Browser zu öffnen. - Dasselbe über zehn Projekte hinweg tun, ohne zwanzigmal zu klicken. ## Anmelden ```bash klops auth login --server https://klickops.example.com ``` Das schreibt `~/.klickops/config.yaml` mit den Rechten `0600` und verweigert das Lesen, wenn die Rechte weiter stehen. Im CI lässt du die Anmeldung weg und setzt stattdessen `KLICKOPS_SERVER` und `KLICKOPS_TOKEN`, mit einem [API-Token](/docs/tokens) statt deinem eigenen Konto. ## Wie ein Befehl aussieht Befehle lesen sich als Substantiv, dann Verb. ```bash klops apps list --project shop klops apps logs web --project shop --follow klops db query orders-db --project shop -c "select count(*) from orders" klops apps deploy web --image nginx:1.27-alpine --port 80 --project shop ``` Jeder lesende Befehl nimmt `-o`, und genau das macht ihn skriptbar: | Format | Wofür | | --- | --- | | `table` | Zum Lesen. Der Standard. | | `json` | Zum Weiterreichen an `jq`. | | `yaml` | Zum Vergleichen oder Weiterverarbeiten. | | `name` | Nur die Namen, für eine Shell-Schleife. | | `wide` | Zum Lesen, mit mehr Spalten. | Farbe fällt automatisch weg, sobald die Ausgabe kein Terminal ist. `klops apps list -o json \| jq` sieht also nie Escape-Sequenzen. ## Woher die Einstellungen kommen Flag schlägt Umgebungsvariable schlägt Konfigurationsdatei schlägt Standard. Ein `--project` auf der Kommandozeile gewinnt also gegen `KLICKOPS_PROJECT`, und das gegen den aktuellen Kontext in `~/.klickops/config.yaml`. | Variable | Setzt | | --- | --- | | `KLICKOPS_SERVER` | Mit welchem klickops gesprochen wird | | `KLICKOPS_TOKEN` | Das Token zur Anmeldung | | `KLICKOPS_ORG` | Standard-Organisation | | `KLICKOPS_PROJECT` | Standard-Projekt | ## Exit-Codes Skripte hängen daran, deshalb bleiben sie stabil. | Code | Bedeutet | | --- | --- | | `0` | Erfolg | | `1` | Etwas ist schiefgelaufen | | `2` | Der Befehl wurde falsch benutzt | | `3` | Nicht angemeldet, oder das Token ist abgelaufen | | `4` | Angemeldet, aber nicht berechtigt | | `5` | Nicht gefunden | | `6` | Existiert bereits | Der nützliche Unterschied: `3` und `4` sind zwei verschiedene Fragen. Eine `3` im CI heisst, das Token muss erneuert werden. Eine `4` heisst, es braucht mehr Rechte. ## Grenzen und Fallstricke - **Es gibt keinen Cache.** Jeder Befehl fragt den Server, denn veralteter Zustand tut mehr weh als ein Netzwerkaufruf. - **Die Konfigurationsdatei wird bei zu weiten Rechten abgelehnt.** Sie enthält ein Token, eine für alle lesbare Datei gilt deshalb als Versehen und nicht als Wunsch. - **Ein Token gehört einer Organisation, nicht dir.** Skripte sollten eines nutzen statt deiner persönlichen Sitzung, damit eine Kündigung nicht die Pipeline bricht. Siehe [API-Tokens](/docs/tokens). ## Verwandt - [API-Tokens](/docs/tokens) zum Anmelden eines Skripts. - [MCP-Server](/docs/mcp), falls klickops von einem KI-Assistenten statt von einem Skript bedient wird. --- # MCP-Server Section: tools URL: https://klickops.io/docs/mcp Reviewed against: 2026.8.7 Lass einen KI-Assistenten klickops direkt bedienen, mit deinen Rechten und deiner Audit-Spur. ## Was das ist Der MCP-Server ist ein kleines Programm auf deinem Rechner, das klickops einem KI-Assistenten als Werkzeugkasten anbietet. Der Assistent kann dann deine Apps auflisten, Logs lesen, nachsehen, warum ein Deployment nicht gesund ist, und Änderungen vornehmen, über dieselbe API, die auch die Oberfläche aufruft. Er ist ein Client, kein zweites Backend. Er hält keinen Zustand, spricht mit klickops und sonst mit nichts, und meldet sich als du an. Alles, was ein Assistent darüber tut, unterliegt deiner Rolle und landet unter deinem Namen im Audit-Log. ## Wann du das brauchst - Du willst fragen "warum ist die Checkout-App nicht gesund" und eine Antwort bekommen, die die echten Logs gelesen hat. - Du arbeitest ohnehin im Assistenten und willst nicht in den Browser wechseln. - Du willst einen Vorschlag, der aus dem tatsächlichen Zustand kommt statt aus einer Vermutung. > [!Vorsicht] > Ein Assistent mit deinen Rechten kann, was du kannst, auch löschen. Gib ihm ein Token, das auf das Nötige beschränkt ist, statt deiner Admin-Sitzung, und nimm für alles Erkundende ein Viewer-Token. Siehe [API-Tokens](/docs/tokens). ## Einrichten Im Bereich Settings gibt es eine Integrations-Seite mit dem Installationsbefehl und dem fertigen Konfigurationsblock für die gängigen Assistenten. Dort steht auch jedes Werkzeug, das der Server anbietet, erzeugt aus demselben Katalog, den der Server selbst liest. Was du dort siehst, bekommt der Assistent. Die Anmeldung nutzt die Konfigurationsdatei, die `klops auth login` schon geschrieben hat, oder `KLICKOPS_SERVER` und `KLICKOPS_TOKEN`, wenn du es lieber ausdrücklich hast. ## Was der Assistent tun kann Werkzeuge heissen nach dem, was sie tun: `klickops_list_apps`, `klickops_get_app_logs`, `klickops_restart_app`, `klickops_query_database`. Lesen macht den grössten Teil aus, und das ist der nützliche: Ein Assistent, der deinen echten Zustand sieht, hört auf zu raten. Änderungen gehen auch, und sie erben die Rechteprüfung der Endpunkte dahinter. Im MCP-Server gibt es keine zusätzliche Bestätigungsebene. Ein Token, das eine App löschen darf, erlaubt einem Assistenten, eine App zu löschen. ## Grenzen und Fallstricke - **Secrets werden nie zurückgegeben.** Werkzeuge zeigen Key-Namen, nie Werte, genau wie die API. Ein Assistent kann deine Zugangsdaten nicht aus klickops lesen. - **Er läuft lokal.** Eine gehostete Variante gibt es heute nicht. Der Server läuft dort, wo du ihn startest, und sein einziger Gegenüber ist dein klickops. - **Er hat kein Gedächtnis.** Jeder Aufruf liest den aktuellen Zustand. Das ist der Sinn, und es heisst, dass ein Assistent nicht auf etwas reagiert, das er vor zehn Minuten gesehen hat. - **Beschränk das Token.** Die nützlichste Gewohnheit: Viewer zum Fragen, Editor nur, wenn du es meinst. ## Verwandt - [API-Tokens](/docs/tokens), um einzugrenzen, was ein Assistent darf. - [klops CLI](/docs/cli) für dieselbe Fläche, von einem Skript bedient. --- # API-Tokens Section: tools URL: https://klickops.io/docs/tokens Reviewed against: 2026.8.7 Langlebige Zugangsdaten für Skripte, CI und Assistenten, auf eine Rolle und wahlweise auf einzelne Projekte beschränkt. ## Was das ist Ein API-Token meldet etwas an, das keine Person ist: eine CI-Pipeline, ein Deployment-Skript, einen KI-Assistenten. Es gehört der Organisation und nicht dir, und es trägt eine eigene Rolle. Genau diese Zugehörigkeit ist der Punkt. Ein Token an deinem Konto hört an dem Tag auf zu funktionieren, an dem du gehst, und nimmt die Pipeline mit. Ein Organisations-Token überdauert dich und lässt sich widerrufen, ohne jemandes Anmeldung anzufassen. ## Wann du das brauchst - Deployment aus deinem eigenen CI. - Ein Cron-Job, der irgendwo `klops` aufruft. - Einem [KI-Assistenten](/docs/mcp) Zugriff geben, ohne deine Sitzung herzugeben. ## Eines anlegen 1. Geh in der Organisation auf **Tokens**. 2. Benenn es nach dem, was es benutzt, nicht nach dir. `github-actions-shop` sagt der nächsten Person, was kaputtgeht, wenn sie es widerruft. `jan-token` sagt das nicht. 3. Wähl die Rolle. Viewer für alles, was nur liest. 4. Beschränk es wahlweise auf bestimmte Projekte. Ein Token ohne Projekt-Beschränkung erreicht die ganze Organisation. 5. Kopier den Wert. Er wird einmal gezeigt und nie wieder. ## Benutzen ```bash export KLICKOPS_SERVER=https://klickops.example.com export KLICKOPS_TOKEN=klp_… klops apps list --project shop -o json ``` Direkt gegen die API ist es ein gewöhnliches Bearer-Token: ```bash curl -H "Authorization: Bearer klp_…" \ https://klickops.example.com/api/klickops/projects/shop/apps ``` ## Einstellungen im Überblick | Einstellung | Standard | Was sie bewirkt | | --- | --- | --- | | Name | keiner | Wofür das Token da ist. Steht in der Liste und im Audit-Log. | | Rolle | viewer | Was es darf: `viewer`, `editor` oder `admin`. | | Projekte | alle | Beschränkt es auf benannte Projekte. Leer heisst ganze Organisation. | | Zuletzt benutzt | nie | Wann es sich zuletzt angemeldet hat, damit du ein lebendes Token von einem vergessenen unterscheidest. | ## Grenzen und Fallstricke - **Der Wert wird einmal gezeigt.** Verloren heisst neu ausstellen, nicht wiederherstellen. - **Ein Token läuft nicht von selbst ab.** Es gilt, bis es widerrufen wird. Deshalb zählt die Spalte "zuletzt benutzt": so findest du die, die niemand mehr braucht. - **Beschränk zuerst über die Rolle, dann über Projekte.** Die meisten CI-Pipelines brauchen `editor` auf einem Projekt, die meisten Assistenten nur `viewer`. - **Widerrufen wirkt sofort und ist endgültig.** Was es benutzt, scheitert beim nächsten Aufruf, mit Exit-Code `3` aus der CLI. > [!Vorsicht] > Ein Token in einem Repository ist ein Token in aller Hände. Leg es in den Secret-Store deines CI, und wenn doch eines committet wird, widerruf es, statt die Historie umzuschreiben. Nimm an, dass es gelesen wurde. ## Verwandt - [klops CLI](/docs/cli) liest `KLICKOPS_TOKEN` direkt. - [MCP-Server](/docs/mcp) sollte ein beschränktes Token bekommen statt deiner Sitzung. - [Mitglieder und Rollen](/docs/members) für dieselbe Frage bei Personen.