Zum Inhalt

BaseHarbor v0.4.23

Veröffentlicht am 08.10.2026. Release-Umbrella: #571; Implementierung: #809.

Core-Installation und erster Application-Workflow

Der BaseHarbor Core besteht verbindlich aus SQL + Secrets + Identity. Die aktuellen Referenz-Realisierungen sind PostgreSQL, OpenBao und Keycloak. Die Web Console bleibt optional.

Der Core lässt sich ohne Application und ohne Repository einrichten. Der Bootstrap konvergiert SQL, Secrets und Identity, prüft ihre Bereitschaft und speichert den verbindlichen Installationszustand. Ein erneuter Versuch verwendet eigene Ressourcen wieder und gleicht sie ab, statt einen zweiten Core zu erzeugen.

Benötigt die erste Application einen Core, bietet der geführte Setup-Flow dessen Einrichtung an. Nach bestätigter Bereitschaft wird der ursprüngliche Vorgang fortgesetzt. Nicht-interaktive Aufrufe melden den notwendigen Bootstrap ausdrücklich, sofern kein automatisches Setup angefordert wurde. CLI, JSON, MCP und geschütztes HTTP verwenden dieselben Bootstrap-Semantiken.

Die Frage nach Entwicklungs- oder Deployment-Maschine steuert Defaults. Entwicklungsmaschinen unterstützen lokale Repositories und Workspaces direkt; Deployment-Maschinen erfordern eine explizite Source-/Workspace-Auswahl. Der normale sichere lokale Entwicklungsablauf erfordert keinen interaktiven Login.

Sicherheit und Placement

Geschützte Zugangsdaten und TLS bleiben Teil des Core-Vertrags. Die Core-Capabilities sind verpflichtend; Provider können shared oder pro Application isoliert platziert werden. Zusätzliche Isolation kann zusätzliche Provider-Instanzen und Ressourcen erfordern.

Eine optionale Console verbindet sich mit genau einem ausgewählten Core derselben Installation und Sicherheitsgrenze. Same-Origin-HTTPS ist die Standardtopologie. Browser-Origin- und Destination-Prüfungen verhindern, dass Zugangsdaten an einen fremden Core weitergegeben werden. Die Application-Identity-Reconciliation kann keine Installation-Identity-Ressourcen ersetzen.

Application-Vorgänge halten Core-verwaltete Secrets, Service-PKI und Runtime-Broker an die ausgewählte Installation gebunden, unabhängig vom Workload-Placement. Die Ausführung prüft diese Core-Bindung erneut und verweigert geänderte oder nicht verfügbare Konfiguration vor nativer Workload-Inspektion oder Mutation. Remote-Auswahl führt niemals implizit zu einem lokalen Core als Ersatz.

Generierte Provider-TLS-Dateien behalten innerhalb geschützter Staging-Verzeichnisse die für ihren unprivilegierten nativen Dienst erforderlichen Berechtigungen. Runtime-Umgebungen bleiben ausschließlich für den Besitzer lesbar. Die Prüfung unveränderlicher Projekte erkennt veränderte Dateiberechtigungen vor der Ausführung. Normales Destroy erhält persistente Daten; ein ausdrücklich angeforderter Reset eigener Ressourcen kann sie entfernen. Die vollständige Remote-Application-Abnahme bleibt erforderlich.

Normales Podman-Destroy mit anschließendem Apply erhält und verwendet dasselbe eigene Provider-Datenvolume wieder. Beim Entfernen verwalteter Units wird der native Besitz vor dem Stoppen erneut geprüft. Ein alter eigener Unit-Nachweis autorisiert keine Ressource, deren Labels inzwischen auf fremden Besitz verweisen.

Der Remote-Quadlet-Adapter veröffentlicht den vollständigen Graphen vor der Aktivierung, startet Container-Abhängigkeiten vor ihren abhängigen Diensten und kehrt diese Reihenfolge beim Destroy um. Zyklen werden vor der Veröffentlichung abgewiesen. Diese Projektmechaniken ersetzen keine vollständige Remote-Abnahme.

Core-verwaltete Init-Dienste erhalten ihren nativen Abschlussnachweis. Core prüft den erfolgreichen Abschluss vor dem Start einer abhängigen Application. Fehlgeschlagene oder nicht gestartete Init-Dienste blockieren die Aktivierung. Diese Units sind vom automatischen Node-Start ausgeschlossen, damit ein Neustart die Prüfung nicht umgeht.

Vor Provider-Aktivierung muss Core die exakte unveränderliche Projekt-Zuordnung dauerhaft speichern. Eine fehlgeschlagene Speicherung hinterlässt keinen ausführbaren Handle und wiederholt die Veröffentlichung nicht automatisch. Podman-Netzwerk-Cleanup entfernt nur das exakte eigene Netzwerk ohne Force und erhält aktive Consumer. Expliziter Daten-Reset prüft die Abwesenheit des Volumes und gleicht einen ausdrücklich angeforderten erneuten Versuch nach normalem Teardown ab. Der fokussierte native Provider-Nachweis ersetzt nicht den vollständigen Remote-Application-Workflow.

Ressourcenausgaben unterscheiden Planungsschätzungen von Messungen. Es wird kein universeller Core-Speichermindestbedarf behauptet. Gemessen wird die vollständige PostgreSQL-/OpenBao-/Keycloak-Topologie: stabilisierter Idle-Verbrauch, beobachteter Startup-/Konvergenz-Peak, gleichzeitiger Gesamtverbrauch, Provider-Images und Placement. Die Core-Ressourcenbeobachtungen dokumentieren die geprüfte Docker-Referenztopologie und die Grenzen ihrer Messungen.

Remote-Speicher-Preflight verwendet aktuelle Belege zu verfügbarem RAM und Swap vom ausgewählten authentifizierten Ausführungs-Node. Core-Host-RAM und Runtime-Info- Gesamtspeicher ersetzen diese Node-Kapazität nicht. Erschöpfter RAM wird auch ohne verlässliche Workload-Schätzung abgewiesen. Diese Beobachtung misst keine PSI- oder VM-/Cgroup-Limits und begründet keine vollständige Remote-Application-Abnahme.

Verwaltete Trust-Rotation

Geschütztes HTTP kann für eine ausdrücklich ausgewählte Installation dieselbe Rotation von Zugangsdaten und Service-CA anfordern wie CLI und MCP. Die verbundene Console fragt nach Bestätigung; Recovery-Material bleibt bei Core. Die Rotation liefert nur geprüfte Readiness-Angaben. Eine unterbrochene Beobachtung muss vor einem erneuten Versuch geprüft werden und wird nicht automatisch wiederholt. Die Browser-Abnahme am endgültigen Kandidaten bleibt erforderlich.

Fehlerkorrekturen aus v0.4.22

Beim Identity-Start wird zuerst die erste Keycloak-Instanz authentifiziert. Danach starten die weiteren Instanzen, damit die initiale Datenbankmigration nicht gleichzeitig mehrfach ausgeführt wird. Die Core-Readiness toleriert vorübergehende interne Authentifizierungsfehler des nativen Providers. Ungültige Zugangsdaten und andere Client-Ablehnungen bleiben blockierend.

Interaktive Terminals erhalten frühe Eingaben und Terminal-Protokollantworten. Log-Beobachtungen liefern kleine Ausgabeblöcke zeitnah, auch beim Folgen eines ansonsten inaktiven Containers. Während Provider-Setup bleibt die HTTPS-Verbindung für Ausführungsbeobachtungen aktiv; Keepalive-Kommentare melden keinen Fortschritt und verlängern keine Authentifizierungsfristen.

Application-Repair behält die ausgewählte Umgebung. Authentifizierte Operator-Aufrufe erhalten die Auflösung der Tenant-Mitgliedschaft auch bei wiederverwendeten Datenbankverbindungen. Row-Level-Isolation und die Ablehnung unscoped Writes bleiben erhalten.

Die Application-Übersicht verwendet die kanonischen Statusbeobachtungen einschließlich verwalteter Provider (#811). Backup stellt Runtime-Broker im Core-Runtime-Kontext wieder her und versucht eine begrenzte Wiederherstellung nach abgebrochener Aufnahme (#812). Geschlossene oder nicht-interaktive Secret-Eingabe liefert einen verständlichen Missing-Secret-Fehler; --yes umgeht die Secret-Verfügbarkeit nicht (#813).

Generierte Compose-Dateien und Quellcode verwenden übereinstimmende Runtime-Bindings (#814). Go-Image-Builds erhalten den durch Tidy erzeugten Modulzustand, Next.js prüft Runtime-Bindings erst während Requests und Quarkus führt Packaging durch den Maven-Lifecycle aus. Generierte Workloads werden unabhängig von gültiger YAML-Einrückung erkannt (#815). Frisches Core-Setup erhält alte Recovery-Dateien und wählt einen neuen Standard-Ausgabepfad; ausdrücklich ausgewählte Pfade bleiben vor Überschreiben geschützt (#526).

Fokussierte Runtime-Regressionsprüfungen und frische native Template-Builds bleiben Voraussetzung für die Release-Abnahme dieser Fehlerkorrekturen.

Öffentliche Companion-Implementierungen

Die optionale BaseHarbor Console und der BaseHarbor Node Connector sind öffentliche Companion-Repositories. Sie konsumieren Core-eigene Verträge und sind keine unabhängigen Control Planes.

Für die Console liegen native Nachweise für authentifizierten Core-/OIDC-Zugang, lokales Application-Plan/Apply/Status/Doctor/Repair/Destroy, Core-Setup für die erste Application, geschützte Trust-Rotation, Terminal und Live-Logs vor. Die Prüfung gegen den endgültigen gepinnten Kandidaten bleibt erforderlich. Diese lokalen Workflows begründen keine Remote-Application-Unterstützung.

Für den Node Connector liegen native Docker-/Podman-Nachweise für Enrollment, authentifizierte Provider-Veröffentlichung, TLS-Probes, unveränderliches Repair, eigenes Cleanup und den Erhalt fremder Ressourcen vor. Vollständige Remote-Application- Unterstützung erfordert weiterhin die exakte Core-zu-Connector-zu-Runtime-Abnahme. Kubernetes und OpenShift verwenden üblicherweise ihre nativen authentifizierten APIs und benötigen den Connector nicht.

Repository-lokale grüne Checks ersetzen keine gepinnten Cross-Repository-Nachweise.

Release-Abnahme

Die Release-Anforderungen (EN) erhalten die veröffentlichte Acceptance-Baseline und verlangen die neuen Integrationsnachweise. Source-Checks ersetzen keine tatsächlichen Docker-/Podman-, Browser-, Connector- oder Remote-Application-Workflows. Fehlende oder fehlgeschlagene Pflichtnachweise verhindern die Freigabe.

Die endgültigen Release Notes ergänzen das verbleibende Integrationsverhalten nach Umsetzung und Abnahme. Die endgültige Zusammenführung des menschlichen CLI-Surfaces bleibt Scope von #610/#611.

Remote-Status und exakte Consumer-Abnahme

Remote-Status und Application-Übersicht prüfen den geschützten Deployment-Beleg und die aktuelle Inventur eigener Container auf dem Node. Fehlende lokale Dateien beweisen keine Remote-Abwesenheit. Provider-Health allein lässt die vollständige Application-Bereitschaft weiterhin unbestätigt.

Der schreibgeschützte Core-Identity-Abgleich deckt jetzt das begrenzte native Keycloak-JDBC-Wiederverbindungsfenster nach der HA-Datenbank-Konvergenz ab. Mutationen und abgelehnte Authentifizierung bleiben Fail-Closed.

Der Console-Release-Producer kann den exakten Core-Kandidaten über einen kontrollierten Integration-Branch mit unveränderlicher SHA prüfen. Den Demo-Pin liest er aus diesem Core. Die sechs gesperrten öffentlichen Verträge müssen weiterhin Byte für Byte übereinstimmen. Das vermeidet rekursive Source-Pins, ohne verpflichtende Abnahmeprüfungen abzuschwächen.

  • Keycloak-Bootstrap verwendet nach Admin-Rotation die aktiven Zugangsdaten. MongoDB behandelt Zugangsdaten mit führendem Minus als Werte, auch bei Healthchecks und Rotation.

  • OIDC-Discovery wiederholt vorübergehende Serverfehler begrenzt während der Identity-Konvergenz; Zugriffsablehnungen bleiben blockierend.

  • Core-Realm-Reconciliation liest nach vorübergehenden Serverfehlern den Zustand erneut und prüft das Eigentum vor einem weiteren Schreibzugriff.