Loading documentation...
Preparing Ring content
Konzepte, Nutzen und typische Clone-Szenarien — weniger Code.
Konzepte, Nutzen und typische Clone-Szenarien — weniger Code.
Preparing Ring content
Preparing Ring content
Preparing Ring content
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/<pack>) fügen vertikale Presets hinzu. Overlays in Layer 3 (ringdom-clones/<slug>) 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/<pack>) | Nein. Auf der Forge gehostet | Ja |
Klone das öffentliche Repo, starte den Assistenten und hoste es, wo du willst. Code, Daten und Mitglieder gehören dir.
Presets geben einem Klon eine fertige Form für eine Branche. Layer 1 enthält die Auswahl. Umfangreichere Pakete kommen über Ringdom.
Das Ringization-Playbook beschreibt den Siedler-Weg: ein dünnes Overlay auf Layer 1, gebaut und gehostet von Ringdom.
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.
Ja, für upgrade, config und test. prod benötigt deine eigenen Kubernetes-Manifeste und eine eigene Registry. Siehe Ring CLI.
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/.
Nächster Schritt: die öffentlichen Setup- und Wartungswerkzeuge im Detail.
Gleicher Ablauf: den OSS-Build auf deinem eigenen Server betreiben.
Siehe auch: der Siedler-Weg vom dünnen Overlay zum gehosteten Klon.
Vertiefung: welche CLI-Befehle außerhalb von Ringdom funktionieren.
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/<pack>) fügen vertikale Presets hinzu. Overlays in Layer 3 (ringdom-clones/<slug>) 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/<pack>) | Nein. Auf der Forge gehostet | Ja |
Klone das öffentliche Repo, starte den Assistenten und hoste es, wo du willst. Code, Daten und Mitglieder gehören dir.
Presets geben einem Klon eine fertige Form für eine Branche. Layer 1 enthält die Auswahl. Umfangreichere Pakete kommen über Ringdom.
Das Ringization-Playbook beschreibt den Siedler-Weg: ein dünnes Overlay auf Layer 1, gebaut und gehostet von Ringdom.
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.
Ja, für upgrade, config und test. prod benötigt deine eigenen Kubernetes-Manifeste und eine eigene Registry. Siehe Ring CLI.
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/.
Nächster Schritt: die öffentlichen Setup- und Wartungswerkzeuge im Detail.
Gleicher Ablauf: den OSS-Build auf deinem eigenen Server betreiben.
Siehe auch: der Siedler-Weg vom dünnen Overlay zum gehosteten Klon.
Vertiefung: welche CLI-Befehle außerhalb von Ringdom funktionieren.
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/<pack>) fügen vertikale Presets hinzu. Overlays in Layer 3 (ringdom-clones/<slug>) 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/<pack>) | Nein. Auf der Forge gehostet | Ja |
Klone das öffentliche Repo, starte den Assistenten und hoste es, wo du willst. Code, Daten und Mitglieder gehören dir.
Presets geben einem Klon eine fertige Form für eine Branche. Layer 1 enthält die Auswahl. Umfangreichere Pakete kommen über Ringdom.
Das Ringization-Playbook beschreibt den Siedler-Weg: ein dünnes Overlay auf Layer 1, gebaut und gehostet von Ringdom.
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.
Ja, für upgrade, config und test. prod benötigt deine eigenen Kubernetes-Manifeste und eine eigene Registry. Siehe Ring CLI.
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/.
Nächster Schritt: die öffentlichen Setup- und Wartungswerkzeuge im Detail.
Gleicher Ablauf: den OSS-Build auf deinem eigenen Server betreiben.
Siehe auch: der Siedler-Weg vom dünnen Overlay zum gehosteten Klon.
Vertiefung: welche CLI-Befehle außerhalb von Ringdom funktionieren.
web/LICENSE.| 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 |
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.
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
Secrets heraushalten
Env-Vorlagen enthalten nur Platzhalter. Lege niemals echte Schlüssel in Code-Kommentare, MDX-Beispiele oder ring-config.json.
web/LICENSE.| 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 |
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.
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
Secrets heraushalten
Env-Vorlagen enthalten nur Platzhalter. Lege niemals echte Schlüssel in Code-Kommentare, MDX-Beispiele oder ring-config.json.
web/LICENSE.| 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 |
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.
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
Secrets heraushalten
Env-Vorlagen enthalten nur Platzhalter. Lege niemals echte Schlüssel in Code-Kommentare, MDX-Beispiele oder ring-config.json.