---
title: "Ring CLI"
description: "Der Befehl ring wird im öffentlichen Repo unter cli/ ausgeliefert. Nutze upgrade, um Systemupdates aus upstream in deinen Klon zu holen, config und test für lokale Prüfungen und prod oder status nur, wenn du einen eigenen Kubernetes-Cluster betreibst."
locale: "de"
---
# Ring CLI

> **Info**
> **Status:** Die Ring CLI wird im öffentlichen Repository unter `cli/` ausgeliefert. Frühere Dokumentation behauptete, sie sei nur für Enterprise verfügbar. Das stimmt nicht mehr. `upgrade`, `config` und `test` funktionieren für jeden Klon. `prod` und `status` erwarten einen Kubernetes-Cluster, den du per SSH erreichst, und Manifeste, die du selbst bereitstellst. Nutze die Tabs **Gründer** / **Entwickler** in der Seitenleiste, um diese Seite zu filtern.

Der Befehl `ring` ist ein kleines Node.js-Tool (`commander`, Node 18 oder neuer), das im Layer-1-Repo neben der App liegt: `ring/cli/` neben `ring/web/`. Er erledigt drei Aufgaben: Ring-Updates aus upstream in deinen Klon holen, eine lokale Deploy-Konfiguration pflegen und ein Docker-Image auf Kubernetes ausrollen.

| Frühere Dokumentation sagte | Aktuelles Repo |
|-------------------|--------------|
| Die CLI ist nicht im öffentlichen GitHub-Repo | `cli/` wird im Repo-Root versioniert und veröffentlicht |
| Erst `npm link`, dann `ring --version` | Führe `npm run cli:install` in `web/` aus, dann `ring --help` |
| `ring deploy prod` | Der Befehl heißt `ring prod`. Einen Unterbefehl `deploy` gibt es nicht |
| Die Community nutzt nur Skripte | Die Community kann `ring upgrade` für sichere Merges aus upstream nutzen |

### For founders

## Was die CLI für deinen Klon leistet

  
- **[Auf dem neuesten Stand bleiben](/docs/development/community-tooling.md)** — `ring upgrade` zeigt vorab, welche Ring-Systemdateien sich in upstream geändert haben, und merged sie nur, wenn du es willst.

  
- **[Selbst hosten](/docs/deployment/self-hosted.md)** — Kein Cluster? Nutze `install.sh` und einen einfachen Node- oder Docker-Host. Die CLI ist optional.

  
- **[Verwaltetes Hosting](/docs/development/oss-vs-enterprise.md)** — Für Ringdom-Siedler wird die Build- und Deploy-Pipeline übernommen.

### Typische Szenarien

1. **Du hast Ring vor Monaten geforkt.** Dein Entwickler führt `ring upgrade` aus, um zu sehen, was sich in upstream geändert hat, prüft den Diff und wendet ihn dann an. Nichts wird automatisch committet.
2. **Du betreibst dein eigenes Kubernetes.** Dein Entwickler richtet die CLI auf deinen Control Node, deine Registry und deinen Namespace aus und liefert neue Versionen mit `ring prod` aus.
3. **Du brauchst nur einen einzigen Server.** Lass die CLI weg. Folge der Anleitung zum Selbsthosting.

> **Tip**
> Ab Werk zeigen die Standardwerte der CLI auf den eigenen Produktionscluster und die Registry von Ringdom. Bitte deinen Entwickler, mit `ring config` eigene Werte zu setzen, bevor `prod` oder `status` laufen.

### For developers

## Installation

**Binary verlinken**

{`npm run cli:install   # cd ../cli && npm install && npm link
ring --help

# or run without a global link
npm run cli:dev -- --help`}

**Auf deine Infrastruktur ausrichten**

Die Konfiguration liegt in `~/.ring-platform.org/config.json` und startet mit den Standardwerten aus `cli/config.js`.

{`ring config --set k8s.controlNode=
ring config --set k8s.namespace=
ring config --set k8s.deployment=
ring config --set app.url=https://
ring config --list`}

## Befehle (aus `cli/index.js`)

| Befehl | Was er tut | Wichtigste Optionen |
|---------|--------------|--------------|
| `ring upgrade` | Drei-Wege-Merge der Systemdateien aus upstream in deinen Klon. Standardmäßig nur Vorschau | `--apply`, `--repo `, `--branch `, `--force` |
| `ring config` | `~/.ring-platform.org/config.json` lesen und schreiben | `--set k=v`, `--get k`, `--list`, `--reset` |
| `ring test` | Prüfungen von Datenbank und Services | `--type db-connection\|db-service\|user-data\|username` |
| `ring prod` | Docker-Build, Push, `kubectl apply`, `set image`, Warten auf den Rollout | `--deploy-version`, `--skip-build`, `--skip-push`, `--skip-deploy`, `--skip-manifest-apply`, `--apply-k8s-secrets`, `--dry-run` |
| `ring status` | Pods, Services und Ingress per SSH, dann `GET {app.url}/api/health` | keine |

`ring prod` hat außerdem `--forge-buildkit` und `--from-forge`. Beide steuern den privaten Builder von Ringdom und sind außerhalb davon nicht nützlich.

## So funktioniert `ring upgrade`

- **Upstream:** `upgrade.repoUrl` ist standardmäßig `https://github.com/connectplatform/ring`, Branch `main`, Remote-Name `ring-upstream`.
- **Basis:** der zuletzt synchronisierte upstream-Commit (`upgrade.lastSyncedRef`). Nur Dateien, die sich zwischen Basis und upstream geändert haben, werden angefasst.
- **Ausschlüsse:** Pfade aus `.reggie-propagate-exclude.json` werden immer übersprungen.
- **Sicherheit:** Konflikte bleiben als normale git-Marker stehen. Nichts wird committet. Der Verlauf landet in `.ring-upgrade-history.json` im git-Root.

{`ring upgrade            # dry run: list upstream changes
ring upgrade --apply    # write the merge to your working tree
git diff                # review, then commit yourself`}

## Was `ring prod` braucht

| Eingabe | Woher sie kommt |
|-------|---------------------|
| Image-Repository | `RING_DOCKER_REGISTRY` / `RING_DOCKER_NAMESPACE` / `RING_DOCKER_IMAGE` (Standard: Ringdom-Registry) |
| Manifeste | `web/k8s/deployment.yaml`, sonst `k8s/` im Org-Overlay (`cli/paths.js` `resolveK8sDir`). Nicht im öffentlichen Repo |
| Cluster-Secrets | `--apply-k8s-secrets` liest `RING_K8S_SECRETS_YAML` oder `k8s/secrets.yaml` |
| Build-Argumente | JSON in `RING_CLI_SECRETS_PATH` (`build_args`) |
| kubectl-Host | `k8s.controlNode` oder `RING_K8S_SSH_HOST` für einen einzelnen Lauf |

Führe immer zuerst `ring prod --dry-run` aus. Es gibt jeden Build-, Push- und `kubectl`-Befehl aus, ohne ihn auszuführen.

## Bekannte Lücken

## Verwandte Dokumentation

  
- [development/community-tooling](/docs/development/community-tooling.md) — Nächster Schritt: die vollständige Liste der öffentlichen Setup-Skripte neben der CLI.

  
- [development/oss-vs-enterprise](/docs/development/oss-vs-enterprise.md) — Siehe auch: welche Teile der CLI-Pipeline nur innerhalb von Ringdom laufen.

  
- [deployment/self-hosted](/docs/deployment/self-hosted.md) — Gleicher Ablauf: Deployment ohne Kubernetes, bei dem die CLI optional ist.