OpenFlags

Was ist OpenFlags?

OpenFlags ist ein Open-Source, self-hosted Feature-Flag-System für progressive Delivery: lokale Evaluation in App-SDKs und ein simples Control-Plane für gezielte Rollouts. Es stellt ein Control Plane und SDKs bereit, damit Anwendungs-Code Flags lokal evaluieren und Feature-Verhalten ohne erneutes Deployen für jede Änderung aktivieren kann.

Der Kernzweck von OpenFlags ist die Unterstützung von Release-Workflows – wie Prozent-Rollouts, gezielte Aktivierung und kontrollierte Freigabe – bei gleichzeitig niedriger Latenz der Flag-Evaluation und Laufzeit-Ownership in der eigenen Infrastruktur.

Wichtige Features

• Self-hosted Flag-Infrastruktur: Flag-Speicher, Targeting-Logik und Runtime-Ownership in der eigenen Infrastruktur halten, statt auf eine gehostete Plattform angewiesen zu sein.
• Lokale Evaluation via typisierter SDKs: Flags in der App mit TypeScript-Paketen evaluieren, für schnelle, vorhersehbare Checks durch lokale Ausführung im Code.
• Progressive-Delivery-Steuerung: Features kontrollierten Gruppen (inkl. Prozent-Rollouts) ausrollen, statt Änderungen für alle auf einmal freizugeben.
• Granulares Targeting: Flags basierend auf spezifischem User-Targeting aktivieren, damit verschiedene Kohorten unterschiedliches Feature-Verhalten erhalten.
• REST-Control-Plane mit fokussiertem Surface Area: Einfache REST-API für Flag-Control-Plane und -Management, als Teil eines Monorepos mit dedizierten Rollen für Server, Dashboard, SDKs und Docs.
• Dashboard für Toggle und Rollout-Management: React-basiertes Admin-UI hilft Teams, Releases zu togglen und Rollout-Konfigurationen zu verwalten.

OpenFlags nutzen

1. Mit Dokumentation und Quickstart starten: Bereitgestellte Docs nutzen, um Server, Dashboard und SDKs in der eigenen Umgebung einzurichten.
2. SDK-Client in der App erstellen: Client mit API-URL, Project-Identifier und User-Identifier initialisieren.
3. Flags lokal in Anwendungs-Code evaluieren: SDK nutzen, um zu prüfen, ob ein Flag aktiviert ist (z. B. via flags.isEnabled("flag_name")), und Verhalten bedingt rendern.
4. Rollout-Konfiguration vom Control Plane aus verwalten: Dashboard und/oder REST-API für Rollout-Verhalten wie prozentuale Aktivierung oder gezielte Freigabe nutzen.

Anwendungsfälle

• Neue User Experience progressiv freigeben: UI oder Workflow hinter Feature Flag setzen und für kontrollierten User-Anteil aktivieren, statt für allen Traffic auf einmal.
• Beta-Test mit gezielten Usern durchführen: Feature für spezifische Kohorten aktivieren, um Verhalten zwischen Gruppen zu vergleichen, ohne den Rest zu beeinflussen.
• Blast Radius mit Prozent-Rollouts reduzieren: Änderung schrittweise ausrollen (z. B. an 35 % der User) und Rollout-Verhalten anpassen, ohne App neu zu bauen oder zu deployen.
• Flag-Checks in performance-sensitiven Apps schnell halten: Lokale Evaluation in der App für niedrige Latenz und konsistente Laufzeit-Checks.
• Ownership in eigener Infrastruktur behalten: Self-hosted Control Plane für operativen und Audit-Surface im eigenen Stack nutzen.

FAQ

• Ist OpenFlags self-hosted oder cloud-hosted? OpenFlags Cloud wird als „coming soon“ beschrieben, das aktuelle Angebot ist open source und self-hosted.

• Wie funktioniert die Feature-Evaluation? OpenFlags unterstützt lokale Evaluation via SDKs, sodass Flag-Checks im App-Code erfolgen, statt bei jeder Evaluation einen Remote-Call zu machen.

• Welche Rollout-Patterns werden unterstützt? Die Seite erwähnt progressive Delivery mit Prozent-Rollouts, granulasem Targeting und kontrollierter Freigabe.

• Welche Komponenten umfasst OpenFlags? Das Monorepo enthält einen Server (Bun-basierte API für Control Plane), ein React-basiertes Dashboard, TypeScript-SDK-Pakete und Dokumentation.

• Für welche Sprachen/Frameworks sind die SDKs ausgelegt? Die Seite hebt JavaScript-first SDK-Nutzung hervor und erwähnt Unterstützung für Bun, React, Next.js, Vite und Node-Apps.

Alternativen

• Gehostete Feature-Flag-Plattformen (SaaS): Diese zentralisieren in der Regel das Flag-Management in einem gehosteten Service. Im Vergleich zum self-hosted Control Plane von OpenFlags kann die Evaluation und operative Kontrolle stärker vom Vendor abhängen.
• Infrastructure-as-Code-basierte Rollouts (ohne dedizierte Flag-Evaluation): Teams können progressive Delivery mit Deployments, Routing oder Config-Toggles approximieren. Das unterscheidet sich von OpenFlags durch das Fehlen eines speziell für lokale Evaluation aufgebauten Feature-Flag-SDK-Workflows.
• Open-Source-Feature-Flag-Services mit anderen Architekturen: Alternative Open-Source-Systeme bieten ähnliche Konzepte (Flags, Targeting, Dashboards), jedoch mit anderen Abwägungen bei SDK-Ansatz, Control-Plane-API-Design oder der Handhabung der lokalen Evaluation.