---
title: "OSS und Enterprise"
description: "Was das öffentliche Apache-2.0-Repo connectplatform/ring enthält und was Ringdom in privaten Overlays behält (Kubernetes-Manifeste, Forge-CI, Order Lab). Fähigkeitsmatrix, Schichtenmodell und die Leak-Sperre, die beides getrennt hält."
locale: "de"
---
# OSS und Enterprise

> **Info**
> Nutze die Tabs **Gründer** / **Entwickler** in der Seitenleiste der Dokumentation, um diese Seite zu filtern. Kurz gesagt: Die gesamte Anwendung ist Open Source. Privat bleiben das Hosting von Ringdom, die CI-Pipeline und eine kleine Gruppe von Modulen nur für Betreiber.

Ring ist in Schichten aufgebaut. **Layer 1** ist die Community-Codebasis, auf GitHub als `connectplatform/ring` unter der Lizenz Apache 2.0 veröffentlicht. Pakete in **Layer 2** (`ring-presets/`) fügen vertikale Presets hinzu. Overlays in **Layer 3** (`ringdom-clones/`) enthalten Marke, Dokumentation und private Module eines Klons. Ein Build kopiert zuerst Layer 1 und legt dann die Overlays darüber. Existiert dieselbe Datei in mehr als einer Schicht, gewinnt die spätere Schicht.

| Fähigkeit | Öffentliches OSS (GitHub) | Ringdom-Siedler |
|------------|---------------------|-----------------|
| Vollständige Next.js-App (`web/`): Shop, Wallet, News, Messaging, Admin und der Rest | Ja | Ja |
| `install.sh`, Helfer in `ring/scripts/`, `data/schema.sql` | Ja | Ja |
| `ring` CLI (`cli/`) | Ja. `upgrade`, `config` und `test` funktionieren überall | Ja, plus der private Build-Pfad |
| Docker-Dateien und env-Vorlagen | Ja | Ja |
| Basis-Dokumentation | Minimal (`web/docs/en/index.mdx` plus zwei Feature-Seiten) | Vollständiger Portal-Korpus im Overlay |
| Kubernetes-Manifeste (`k8s/`) | Nein | Ja |
| Forgejo-CI-Workflows (`.forgejo/`) und Forge-Build-Pipeline | Nein. Werden aus dem GitHub-Spiegel entfernt | Ja |
| Order Lab, Rechner, `my-orders`, `my-jobs`, Bestellungen im Admin-CRM | Nein. Nur Community-Stubs | Ja |
| Preset-Auswahl in `ring-config.json` und Layer-1-Kataloge (`features/entities/presets/`) | Ja | Ja |
| Preset-Pakete in Layer 2 (`ring-presets/`) | Nein. Auf der Forge gehostet | Ja |

### For founders

## Welcher Weg zu dir passt

  
- **[Selbst betreiben](/docs/deployment/self-hosted.md)** — Klone das öffentliche Repo, starte den Assistenten und hoste es, wo du willst. Code, Daten und Mitglieder gehören dir.

  
- **[Eine Vertikale gestalten](/docs/customization/vertical-presets.md)** — Presets geben einem Klon eine fertige Form für eine Branche. Layer 1 enthält die Auswahl. Umfangreichere Pakete kommen über Ringdom.

  
- **[Siedler werden](/docs/customization/ringization-playbook.md)** — Das Ringization-Playbook beschreibt den Siedler-Weg: ein dünnes Overlay auf Layer 1, gebaut und gehostet von Ringdom.

```mermaid
flowchart LR
  L1["Layer 1: connectplatform/ring (öffentlich)"] --> B["Build"]
  L2["Layer 2: Preset-Paket (optional)"] --> B
  L3["Layer 3: Overlay deines Klons (privat)"] --> B
  B --> C["Dein laufender Klon"]
```

### Typische Szenarien

1. **Unabhängige Community.** Nutze nur OSS. Du bekommst alle Funktionen für Mitglieder und betreibst sie auf deinem eigenen Server.
2. **Regionale Genossenschaft ohne eigenen Betrieb.** Werde Siedler. Ringdom betreibt den Cluster, die Builds und die Rollouts.
3. **Agentur mit vielen Kunden.** Starte für Prototypen mit OSS und verlege dann Kunden, die Presets oder verwaltetes Hosting brauchen, auf Siedler-Overlays.

### Was Open Source hier bedeutet

- **Apache 2.0.** Du darfst den Code betreiben, ändern und darauf aufbauende Dienstleistungen verkaufen, gemäß den Lizenzbedingungen in `web/LICENSE`.
- **Was privat bleibt, steht in der Tabelle.** Das sind Infrastruktur, CI, Betreibermodule und Preset-Pakete. Ein Siedler-Klon kann außerdem eigene private Module in seinem Overlay führen.

### For developers

## Schichtenübersicht (geprüfte Pfade)

| Schicht | Repo | Inhalt |
|-------|------|----------|
| L1 Community | `connectplatform/ring` auf GitHub, gespiegelt von der Ringdom-Forge | `web/`, `cli/`, `scripts/`, `install.sh`, Root-`package.json` |
| L2 Pakete | `ring-presets/` auf der Forge | Vertikale Presets |
| L3 Overlay | `ringdom-clones/` auf der Forge | Überschreibungen von `web/` (Marke, Dokumentation, Order Lab, Rechner), `k8s/`, `scripts/ci/`, `.forgejo/` |

## Wie die Trennung durchgesetzt wird

| Mechanismus | Datei | Was er tut |
|-----------|------|--------------|
| GitHub-Spiegel | `scripts/push-github-oss.sh` | Baut aus der Spitze der Forge einen einzelnen Commit ohne `.forgejo/` und pusht ihn nach `github/main` |
| Leak-Sperre | `scripts/check-no-org-leak.sh` (`npm run check:org-leak`) | Schlägt fehl, wenn `k8s`, `cli` (innerhalb von `web/`), `.forgejo`, `.env.local`, Order Lab, Rechner oder die Routen `my-orders` / `my-jobs` echte Pfade in `ring/web` sind statt zu fehlen oder Symlinks zu sein. Verlangt außerdem, dass `ring-config.json` eine committete reguläre Datei ist |
| Community-Stubs | `scripts/ensure-community-stubs.sh` | Stellt Community-Versionen wie `lib/payments/conductor/handlers/project-order.community.ts` wieder her, wenn die Overlay-Links fehlen |
| Ignore-Regeln | `web/.gitignore` | Hält `web/k8s/`, `web/cli/`, `web/scripts/`, `web/propagation/` und `.forgejo/` aus Layer-1-Commits heraus |
| Shadow-Bericht | `npm run compose:shadow` | Listet Layer-1-Pfade, die ein Overlay ersetzt, damit Überschreibungen im Review sichtbar sind |

> **Tip**
> Die Root-Verzeichnisse `cli/` und `scripts/` im Repo sind öffentlich. Ignoriert werden nur die Pfade `web/cli`, `web/k8s` und `web/scripts`, weil das auf Ringdom-Maschinen lokale Symlinks auf das private Overlay sind.

## Mitwirken

**Nur gegen Layer 1 arbeiten**

Lege Community-Änderungen in `ring/web` oder `ring/cli` ab. Committe nie Overlay-Dateien oder Symlinks.

**Die Prüfungen ausführen**

{`npm run check:org-leak
npm run type-check
npm run lint`}

**Secrets heraushalten**

Env-Vorlagen enthalten nur Platzhalter. Lege niemals echte Schlüssel in Code-Kommentare, MDX-Beispiele oder `ring-config.json`.

## Häufige Fragen

### Auswirkungen

#### Was fehlt in OSS?

Die Zeilen, die in der Tabelle mit **Nein** markiert sind. Order Lab, Projektbestellungen und Rechner kompilieren gegen Community-Stubs, daher funktioniert der Build trotzdem. Einzelne Siedler-Klone können außerdem eigene private Module in ihrem Overlay mitführen.

#### Kann ich die Ring CLI ohne Ringdom nutzen?

Ja, für `upgrade`, `config` und `test`. `prod` benötigt deine eigenen Kubernetes-Manifeste und eine eigene Registry. Siehe [Ring CLI](/docs/cli.md).

### Betrieb

#### Wo liegt die Portal-Dokumentation?

Der vollständige Dokumentationskorpus von ring-platform.org liegt im privaten Layer-3-Overlay und wird öffentlich unter `/docs` ausgeliefert. Layer 1 behält eine kleine Community-Basis unter `web/docs/`.

## Verwandte Dokumentation

  
- [development/community-tooling](/docs/development/community-tooling.md) — Nächster Schritt: die öffentlichen Setup- und Wartungswerkzeuge im Detail.

  
- [deployment/self-hosted](/docs/deployment/self-hosted.md) — Gleicher Ablauf: den OSS-Build auf deinem eigenen Server betreiben.

  
- [customization/ringization-playbook](/docs/customization/ringization-playbook.md) — Siehe auch: der Siedler-Weg vom dünnen Overlay zum gehosteten Klon.

  
- [cli](/docs/cli.md) — Vertiefung: welche CLI-Befehle außerhalb von Ringdom funktionieren.