10 releases 10 tags

RSS feed

• v1.5.11-ew-2 9e762af0fd

  Compare

  v1.5.11-ew-2: private network fix Stable

  engel75 released this 2026-06-09 10:03:19 +02:00 | 0 commits to 1.5.11-ew1 since this release

  Patch release auf top von v1.5.11-ew-1 mit demselben Production‑Bug‑Fix wie v1.5.10-ew-2.

  Was wurde gefixt

  fix(ew): always allow private network connections (9e762af0f)

  Beim ersten Production‑Deployment der ew-1 Branches bemerkt: alle list_models Calls gegen SGLang Server auf privaten Netzen (LAN, k8s, VPC) schlugen fehl mit failed to execute HTTP request to provider API.

  Root cause: der v1.5.10 Provider‑Interface‑Follow‑up reichte config.NetworkConfig.AllowPrivateNetwork durch upstream's neue ConfigureDialer(client, bool) Signatur. Default false aktiviert die upstream SSRF‑Defense, die alle RFC 1918 IPs blockiert (10.x, 172.16‑31.x, 192.168.x) — genau das Netz auf dem EW‑Backends laufen. Der Bug propagierte unverändert von v1.5.10 nach v1.5.11.

  Fix: true hartkodiert im EW Provider Init. EW ist per Spec 01 explizit für "locally hosted models" — der upstream Default macht für Cloud‑Provider (OpenAI, Anthropic, …) Sinn, nicht für EW. Operatoren mit public‑only EW Backends sind aktuell nicht unterstützt.

  Siehe Spec 01 "Network policy" und Spec 08 Nachtrag für den vollen Hintergrund.

  Container image

  forge.engelmann.me/engel75/bifrost:v1.5.11-ew-2
  

  Funktional identisch zu v1.5.11-ew-1, nur mit dem Dialer‑Fix. Empfohlene Produktions‑Version.

  Upgrade notes

  • Von v1.5.11-ew-1: trivialer Drop‑in. Keine Schema‑Änderung, keine neue Migration. Container neu pullen, Container neu starten — fertig.
  • Von v1.5.10-ew-2: Upstream v1.5.10 → v1.5.11 + 0 fork‑seitige Änderungen. Wenn du sowieso auf v1.5.11 upstream willst, wechsel direkt hierher.
  • Aus älteren Versionen (v1.5.7-ew-1, v1.5.8-ew-1): diese Releases haben den Bug nicht (der allowPrivateNetwork‑Parameter existierte upstream noch nicht). Wenn du sie aktuell nutzt: kein Handlungsbedarf, oder direkt auf v1.5.11-ew-2 upgraden.

  Andere ew-1 Branches

  Der gleiche Fix wurde auch auf 1.5.10-ew1 cherry‑picked und als v1.5.10-ew-2 released. Ältere Branches (1.5.3-ew1, 1.5.4-ew1, 1.5.7-ew1, 1.5.8-ew1) brauchen den Fix nicht.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.5.10-ew-2 165758b1d7

  Compare

  v1.5.10-ew-2: private network fix Stable

  engel75 released this 2026-06-09 09:58:05 +02:00 | 0 commits to 1.5.10-ew1 since this release

  Patch release auf top von v1.5.10-ew-1 mit einem Production‑Bug‑Fix.

  Was wurde gefixt

  fix(ew): always allow private network connections (165758b1d)

  Beim ersten Production‑Deployment der ew-1 Branches bemerkt: alle list_models Calls gegen SGLang Server auf privaten Netzen (LAN, k8s, VPC) schlugen fehl mit failed to execute HTTP request to provider API.

  Root cause: der v1.5.10 Provider‑Interface‑Follow‑up reichte config.NetworkConfig.AllowPrivateNetwork durch upstream's neue ConfigureDialer(client, bool) Signatur. Default false aktiviert die upstream SSRF‑Defense, die alle RFC 1918 IPs blockiert (10.x, 172.16‑31.x, 192.168.x) — genau das Netz auf dem EW‑Backends laufen.

  Fix: true hartkodiert im EW Provider Init. EW ist per Spec 01 explizit für "locally hosted models" — der upstream Default macht für Cloud‑Provider (OpenAI, Anthropic, …) Sinn, nicht für EW. Operatoren mit public‑only EW Backends sind aktuell nicht unterstützt.

  Siehe Spec 01 "Network policy" und Spec 08 Nachtrag für den vollen Hintergrund.

  Container image

  forge.engelmann.me/engel75/bifrost:v1.5.10-ew-2
  

  Funktional identisch zu v1.5.10-ew-1, nur mit dem Dialer‑Fix.

  Upgrade notes

  • Von v1.5.10-ew-1: trivialer Drop‑in. Keine Schema‑Änderung, keine neue Migration. Container neu pullen, Container neu starten — fertig.
  • Aus älteren Versionen (v1.5.7-ew-1, v1.5.8-ew-1): diese Releases haben den Bug nicht (der allowPrivateNetwork‑Parameter existierte upstream noch nicht). Wenn du sie aktuell nutzt: kein Handlungsbedarf, oder direkt auf v1.5.11-ew-2 upgraden falls du die v1.5.10/v1.5.11 upstream features brauchst.

  Andere ew-1 Branches

  Der Fix wurde auch auf 1.5.11-ew1 cherry‑picked und als v1.5.11-ew-2 released. Ältere Branches (1.5.3-ew1, 1.5.4-ew1, 1.5.7-ew1, 1.5.8-ew1) brauchen den Fix nicht.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.5.11-ew-1 64cb0bdaf8

  Compare

  v1.5.11-ew-1: EW fork on bifrost v1.5.11 Stable

  engel75 released this 2026-06-08 16:31:48 +02:00 | 1 commits to 1.5.11-ew1 since this release

  EW fork release based on upstream bifrost transports/v1.5.11.

  Tracking release — keine Feature‑Änderungen in der Fork gegenüber v1.5.10-ew-1. Zweiter Zero‑Conflict‑Port in Folge — siehe Spec 08 port log für Details.

  Contents

  Spec	Feature
  01	EW (SGLang/OpenAI-compatible) provider — chat/text completion (+ stream), embeddings, responses, speech (+ stream), transcription (+ stream), rerank, image gen/edit/variation, list_models with owned_by="everyware" override
  02	Per-key API toggles (EWKeyConfig.AllowedRequests) — restrict an EW key to a subset of operations
  03	OpenAI-conformant error envelope on /v1/... and /cursor/... routes + SGLang-aware error parser
  04	WhitelistedRoutes config also bypasses auth for inference routes (e.g. /v1/models) and the governance VK-required gate
  05	Dockerfile builds with all local plugins via go.work, Forgejo Actions workflows for branch + tag builds

  Port-Notes (was sich gegenüber v1.5.10 änderte)

  In der Fork: nichts. Upstream zwischen v1.5.10 und v1.5.11:

  • 12 substantielle Commits, davon nur 2 mit Overlap zu unserem Footprint (handlers/governance.go +11 Zeilen, governance_test.go) — beide Files, die unsere Fork nicht touched.
  • Keine neuen DB‑Migrationen in der Mitte unserer Ordering.
  • Keine API‑Drifts — die v1.5.10 Provider Interface Anpassungen (ConfigureDialer 2‑arg + Compaction stub) sind in der Fork bereits dauerhaft drin und propagieren automatisch.
  • Kein Go‑Bump — go.mod blieb auf 1.26.4 wie in v1.5.10.

  Alle 14 Cherry‑Picks liefen sauber durch, kein Follow‑up Commit nötig.

  Container image

  The Docker Release workflow publishes:

  forge.engelmann.me/engel75/bifrost:v1.5.11-ew-1
  

  Identical runtime semantics to upstream transports/v1.5.11 plus all of the above EW features. Built statically (CGO + sqlite_static), runs as non-root, healthcheck on /health. Build-Stage nutzt Go 1.26.4 alpine image.

  Branches

  Branch 1.5.11-ew1 tracks this release. Frühere ew1 releases (1.5.3-ew1, 1.5.4-ew1, 1.5.7-ew1, 1.5.8-ew1, 1.5.10-ew1) bleiben verfügbar. Cherry-pick-Pfad für die nächste upstream Version: Spec 07 — Port Runbook.

  Upgrade notes

  • Von v1.5.10-ew-1: trivialer Drop‑in. Keine fork‑seitige Schema‑Änderung und keine neue upstream Migration in der relevanten Reihenfolge. Symbol‑Set im Binary identisch (107 matches).
  • Von jeder älteren X.Y.Z-ew1 Version: in-place safe. Alle Migrationen sind idempotent über migrator_meta. Die akkumulierten upstream Migrationen aus v1.5.4 + v1.5.7 + v1.5.10 laufen automatisch.
  • Von upstream transports/v1.5.11 (kein EW bislang): beim ersten Boot werden die EW-Spalten in config_keys angelegt. Existierende Keys bleiben unangetastet.

  Verification

  • Alle Go test suites grün (handlers TestAuth, integrations, core/providers/ew, framework/configstore -short).
  • docker build clean ohne Anpassung.
  • Symbol-Check: 107 matches im Binary (alle 5 Specs detektiert, identisch zu v1.5.10).
  • Version string in /app/main ist exakt v1.5.11-ew-1.

  See Spec 08 — Version Port Log für die volle per-Version Historie.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.5.10-ew-1 80c262535c

  Compare

  v1.5.10-ew-1: EW fork on bifrost v1.5.10 Stable

  engel75 released this 2026-06-08 09:30:09 +02:00 | 1 commits to 1.5.10-ew1 since this release

  EW fork release based on upstream bifrost transports/v1.5.10 (commit b35e35da3, v1.5.9 übersprungen).

  Tracking release — keine Feature‑Änderungen in der Fork gegenüber v1.5.8-ew-1. Der Port war diesmal anspruchsvoller als die letzten (110 upstream Commits, 1 Konflikt + 2 API‑Follow‑ups) — siehe Spec 08 port log für Details.

  Contents

  Spec	Feature
  01	EW (SGLang/OpenAI-compatible) provider — chat/text completion (+ stream), embeddings, responses, speech (+ stream), transcription (+ stream), rerank, image gen/edit/variation, list_models with owned_by="everyware" override
  02	Per-key API toggles (EWKeyConfig.AllowedRequests) — restrict an EW key to a subset of operations
  03	OpenAI-conformant error envelope on /v1/... and /cursor/... routes + SGLang-aware error parser
  04	WhitelistedRoutes config also bypasses auth for inference routes (e.g. /v1/models) and the governance VK-required gate
  05	Dockerfile builds with all local plugins via go.work, Forgejo Actions workflows for branch + tag builds

  Port-Notes (was sich gegenüber v1.5.8 änderte)

  Im Code der Fork selbst: nichts. Aber upstream zwischen v1.5.8 und v1.5.10:

  • +8 neue DB-Migrationen (Model-Config Refactor: scope columns, customer budgets, FK constraints, governance migration). Standard-Resolution per Spec 06 — alle 8 vor unseren 2 EW-Migrationen einsortiert.
  • providerUtils.ConfigureDialer signatur change: zweiter bool Parameter für allowPrivateNetwork. EW Provider angepasst per Reference Pattern aus VLLM/OpenAI.
  • schemas.Provider interface: neue Compaction Methode. EW Provider liefert UnsupportedOperationError (SGLang hat keine native Compaction).
  • Go 1.26.3 → 1.26.4 in allen upstream go.mod. Dockerfile printf-String entsprechend gebumped (selbes Pattern wie beim v1.5.7 Port).

  Container image

  The Docker Release workflow publishes:

  forge.engelmann.me/engel75/bifrost:v1.5.10-ew-1
  

  Identical runtime semantics to upstream transports/v1.5.10 plus all of the above EW features. Built statically (CGO + sqlite_static), runs as non-root, healthcheck on /health. Build-Stage nutzt Go 1.26.4 alpine image.

  Branches

  Branch 1.5.10-ew1 tracks this release. Frühere ew1 releases (1.5.3-ew1, 1.5.4-ew1, 1.5.7-ew1, 1.5.8-ew1) bleiben verfügbar. Cherry-pick-Pfad für die nächste upstream Version: Spec 07 — Port Runbook.

  Upgrade notes

  • Von v1.5.8-ew-1: in-place safe. Die 8 neuen upstream Migrationen und unsere 2 EW Migrationen laufen alle idempotent über migrator_meta. Keine fork-seitige Schema-Änderung.
  • Von jeder älteren X.Y.Z-ew1 Version: in-place safe. Alle Migrationen sind idempotent.
  • Von upstream transports/v1.5.10 (kein EW bislang): beim ersten Boot werden die EW-Spalten in config_keys angelegt. Existierende Keys bleiben unangetastet.

  Verification

  • All Go test suites grün (handlers TestAuth, integrations, core/providers/ew, framework/configstore -short).
  • docker build clean nach Go 1.26.4 bump.
  • Symbol-Check: 107 matches im Binary (alle 5 Specs detektiert).
  • Version string in /app/main ist exakt v1.5.10-ew-1.

  See Spec 08 — Version Port Log für die volle per-Version Historie.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.5.8-ew-1 ddb8bfff03

  Compare

  v1.5.8-ew-1: EW fork on bifrost v1.5.8 Stable

  engel75 released this 2026-06-04 15:01:12 +02:00 | 0 commits to 1.5.8-ew1 since this release

  EW fork release based on upstream bifrost transports/v1.5.8 (commit 7c5ab44e2).

  Tracking release with no functional changes vs. v1.5.7-ew-1 — the new upstream v1.5.8 was a small delta (14 substantive commits) and the EW fork cherry-picked cleanly with zero conflicts (see Spec 08 port log).

  Contents

  Spec	Feature
  01	EW (SGLang/OpenAI-compatible) provider — chat/text completion (+ stream), embeddings, responses, speech (+ stream), transcription (+ stream), rerank, image gen/edit/variation, list_models with owned_by="everyware" override
  02	Per-key API toggles (EWKeyConfig.AllowedRequests) — restrict an EW key to a subset of operations
  03	OpenAI-conformant error envelope on /v1/... and /cursor/... routes + SGLang-aware error parser
  04	WhitelistedRoutes config also bypasses auth for inference routes (e.g. /v1/models) and the governance VK-required gate
  05	Dockerfile builds with all local plugins via go.work, Forgejo Actions workflows for branch + tag builds

  Container image

  The Docker Release workflow publishes:

  forge.engelmann.me/engel75/bifrost:v1.5.8-ew-1
  

  Identical runtime semantics to upstream transports/v1.5.8 plus all of the above EW features. Built statically (CGO + sqlite_static), runs as non-root, healthcheck on /health.

  Branches

  Branch 1.5.8-ew1 tracks this release. Earlier ew1 releases (1.5.3-ew1, 1.5.4-ew1, 1.5.7-ew1) remain available. Cherry-pick path for the next upstream version is documented in Spec 07 — Port Runbook.

  Upgrade notes

  • From v1.5.7-ew-1: trivial — no DB schema change in our fork, only upstream v1.5.7 → v1.5.8 changes (5 already-applied upstream migrations from v1.5.7 + no new EW migration). Drop-in container replacement.
  • From any earlier X.Y.Z-ew1 release: in-place safe. The two EW DB migrations (add_ew_key_config_columns, add_ew_allowed_requests_column) are idempotent via migrator_meta. Any intermediate upstream migrations apply automatically.
  • From upstream transports/v1.5.8 (no EW yet): on first boot the EW migrations create the new EW columns on config_keys. Existing keys are unaffected.

  Verification

  • Zero merge conflicts on the v1.5.7 → v1.5.8 cherry-pick.
  • All Go test suites green (handlers, integrations, core/providers/ew, framework/configstore -short).
  • docker build clean.
  • Symbol check confirms all 5 fork features baked into the binary (106 matches).
  • Version string in /app/main is exactly v1.5.8-ew-1.

  See Spec 08 — Version Port Log for the full per-version history.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.5.7-ew-1 db36805c5a

  Compare

  v1.5.7-ew-1: EW fork on bifrost v1.5.7 Stable

  engel75 released this 2026-06-04 13:14:35 +02:00 | 0 commits to 1.5.7-ew1 since this release

  EW fork release based on upstream bifrost transports/v1.5.7 (commit b4b95ff8a).

  Contents

  Spec	Feature
  01	EW (SGLang/OpenAI-compatible) provider — chat/text completion (+ stream), embeddings, responses, speech (+ stream), transcription (+ stream), rerank, image gen/edit/variation, list_models with owned_by="everyware" override
  02	Per-key API toggles (EWKeyConfig.AllowedRequests) — restrict an EW key to a subset of operations
  03	OpenAI-conformant error envelope on /v1/... and /cursor/... routes + SGLang-aware error parser
  04	WhitelistedRoutes config also bypasses auth for inference routes (e.g. /v1/models) and the governance VK-required gate
  05	Dockerfile builds with all local plugins via go.work, Forgejo Actions workflows for branch + tag builds

  Container image

  The Docker Release workflow publishes:

  forge.engelmann.me/engel75/bifrost:v1.5.7-ew-1
  

  docker run against this image is functionally identical to the upstream transports/v1.5.7 binary, plus all of the above EW features. Built statically (CGO + sqlite_static), runs as non-root user, healthcheck on /health.

  Branches

  Branch 1.5.7-ew1 tracks this release. Earlier ew1 releases (1.5.3-ew1, 1.5.4-ew1) remain available; cherry-pick path documented in Spec 07 — Port Runbook.

  Upgrade notes

  • From any prior X.Y.Z-ew1 release: in-place safe. The two EW DB migrations (add_ew_key_config_columns, add_ew_allowed_requests_column) are idempotent via migrator_meta. Upstream v1.5.4 → v1.5.7 added 4 new VK migrations (add_per_user_headers_*, add_mcp_client_tls_config, add_additional_attributes_to_pricing, drop_azure_api_version) — all also idempotent.
  • From upstream transports/v1.5.7 (no ew yet): on first boot the EW migrations create two new columns on config_keys (ew_url, ew_model_name, ew_allowed_requests_json). Existing keys are unaffected.

  Verification

  • All Go test suites green (handlers, integrations, core/providers/ew, framework/configstore -short).
  • docker build clean (build cache fresh + warm), image runs.
  • Symbol check confirms all 5 fork features baked into the binary.
  • Version string in /app/main is exactly v1.5.7-ew-1.

  See Spec 08 — Version Port Log for the conflict resolutions encountered during the v1.5.4 → v1.5.7 port.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.4.23-ew-4 8b6f8e1495

  Compare

  v1.4.23-ew-4 — fix Dockerfile to ship local plugin code Stable

  engel75 released this 2026-04-29 09:38:58 +02:00 | 0 commits to 1.4.23-ew since this release

  v1.4.23-ew-4

  Patch-Release auf v1.4.23-ew-3.

  Bugfix: WhitelistedRoutes-Bypass fürs Governance-Plugin landete nie im Image

  In v1.4.23-ew-3 haben wir den VK-Pflicht-Bypass im Governance-Plugin (Commit 55515ff37) committet, aber das gebaute Docker-Image hat den Bypass NIE ausgeliefert.

  Ursache: Der Dockerfile-Build erstellt einen go.work mit nur core/ und framework/. Alle Plugins — auch governance — werden über transports/go.mod aus dem Module-Cache (Upstream-Versionen, z. B. governance v1.4.39) gezogen. Lokale Plugin-Änderungen waren also unsichtbar für den Build.

  Folge: /v1/models lieferte trotz WhitelistedRoutes-Eintrag weiter 401 virtual key is required — die VK-Pflicht im Plugin lief gegen die alte Upstream-Version.

  Fix: Alle 8 lokalen Plugins (governance, litellmcompat, logging, maxim, mocker, otel, semanticcache, telemetry) werden ins Build-Image kopiert und in den Workspace aufgenommen. Damit baut go build jeden Plugin aus lokalem Source statt aus der pinned Module-Cache-Version.

  Was geändert wurde

  transports/Dockerfile:

  • COPY plugins/ /plugins/ ergänzt.
  • Workspace-Generation um alle 8 Plugin-Pfade erweitert:

    use (
        .
        /core
        /framework
        /plugins/governance
        /plugins/litellmcompat
        /plugins/logging
        /plugins/maxim
        /plugins/mocker
        /plugins/otel
        /plugins/semanticcache
        /plugins/telemetry
    )
    

  Warum betraf das nicht alle Änderungen?

  Frühere Patch-Releases haben funktioniert, weil ihre Änderungen in core/, framework/ oder transports/ lagen — diese drei Module sind seit jeher Teil der Workspace. Erst 55515ff37 (Bypass im Governance-Plugin) musste über plugins/governance/ deployed werden — und genau da hatte der Build die Lücke.

  Upgrade

  Nach diesem Image-Push: einmal pullen + neu starten. Die UI-Konfiguration bleibt unverändert (Whitelist-Eintrag z. B. /v1/models).

  Vollständiger Changelog

  v1.4.23-ew-3...v1.4.23-ew-4

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.4.23-ew-3 4bd6a4d97e

  Compare

  v1.4.23-ew-3 — public /v1/models via WhitelistedRoutes Stable

  engel75 released this 2026-04-28 18:39:16 +02:00 | 1 commits to 1.4.23-ew since this release

  v1.4.23-ew-3

  Patch-Release auf v1.4.23-ew-2.

  Highlight: Inference-Routen über WhitelistedRoutes öffentlich machen

  Das bestehende Setting Workspace → Config → Security → "Whitelisted Routes" greift jetzt auch für Inference-Endpunkte (z. B. /v1/models). Vorher griff es nur für /api/...-Dashboard-Routen.

  Anwendungsfall:

  1. „Password protect the dashboard" aktiviert, „Enforce virtual keys on inference" aktiviert.
  2. /v1/models (oder /v1/models*, /v1/*) unter „Whitelisted Routes" eintragen.
  3. curl http://bifrost/v1/models ohne Authorization-Header und ohne x-bf-vk-Virtual-Key liefert die Modellliste.

  Anonyme Aufrufe sehen die ungefilterte Modellliste — Virtual-Key-basiertes Filtering kann ohne Virtual Key naturgemäß nicht greifen.

  Was passiert ist

  Das Setting WhitelistedRoutes lebte schon, aber die Enforcement war auf zwei Schichten unvollständig:

  1. AuthMiddleware (Basic-Auth/Session-Token) prüfte die Whitelist nur in APIMiddleware (für /api/...), nicht in InferenceMiddleware (für /v1/...).
  2. Selbst wenn die AuthMiddleware durchließ, gab das Governance-Plugin unabhängig „virtual key is required" zurück, sobald „Enforce auth on inference" aktiv war.

  Beide Schichten respektieren jetzt die Whitelist.

  Was geändert wurde

  feat(auth): allow inference routes in WhitelistedRoutes config

  • transports/bifrost-http/handlers/middlewares.go: Match-Logik (exakt + *-Suffix-Wildcard) in isUserWhitelisted extrahiert. InferenceMiddleware ruft den Helper jetzt zusätzlich zu DisableAuthOnInference. APIMiddleware-Verhalten unverändert.
  • UI: Hilfetext und Placeholder im Security-Tab erwähnen Inference-Routen.

  fix(auth): propagate WhitelistedRoutes bypass into governance plugin

  • Neue Context-Konstante schemas.BifrostContextKeyAuthRouteWhitelisted in core/schemas/bifrost.go.
  • AuthMiddleware setzt das Flag, wenn die URL gegen die User-Whitelist matcht.
  • plugins/governance/main.go:evaluateGovernanceRequest checkt das Flag ganz vorne und gibt direkt DecisionAllow zurück — vor dem VK-Pflicht-Gate.

  fix(auth): strip query string before whitelist match

  • isUserWhitelisted strippt jetzt ?… vom URL, bevor sie matcht. Damit greift ein exakter Eintrag /v1/models auch bei Aufrufen wie /v1/models?provider=openai.

  Geänderte Dateien

  • core/schemas/bifrost.go — neue Context-Konstante.
  • transports/bifrost-http/handlers/middlewares.go — Helper, Inference-Whitelist, Query-String-Strip.
  • transports/bifrost-http/handlers/middlewares_test.go — Regression-Tests (5 Fälle inkl. Query-String).
  • plugins/governance/main.go — Bypass im Plugin.
  • ui/app/workspace/config/views/securityView.tsx — Hinweistext + Placeholder.

  Upgrade

  • Service neu starten, Docker-Image: forge.engelmann.me/engel75/bifrost:v1.4.23-ew-3 (wird durch Tag-Push gebaut).
  • Bestehende Whitelist-Einträge werden automatisch auch für Inference-Routen wirksam — keine Migration nötig.

  Vollständiger Changelog

  v1.4.23-ew-2...v1.4.23-ew-3

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.4.23-ew-2 43b2fc60f2

  Compare

  v1.4.23-ew-2 — owned_by override + Docker version fix Stable

  engel75 released this 2026-04-28 13:08:24 +02:00 | 4 commits to 1.4.23-ew since this release

  v1.4.23-ew-2

  Patch-Release auf v1.4.23-ew-1.

  Neuerungen

  EW-Provider: owned_by Override (feat)

  Die /v1/models-Antwort gibt für jedes Modell des EW-Providers jetzt owned_by: "everyware" zurück, unabhängig davon, was die SGLang-Backends melden. SGLang reicht typischerweise den ursprünglichen Hugging-Face-Owner durch (z. B. Qwen, meta-llama); für EW-Deployments ist der kanonische Eigentümer aber der Operator, nicht der Modell-Autor.

  Implementierung: Override in listModelsByKey direkt nach dem geteilten openai.ListModelsByKey-Call. Konstante EWModelOwner = "everyware" in core/providers/ew/ew.go. Regression-Test in list_models_test.go ergänzt.

  Bugfixes

  Docker-Build: doppeltes v in der Binary-VERSION (fix)

  Der Forgejo-Actions-Workflow docker-release.yml reicht den Git-Tag (z. B. v1.4.23-ew-1) als --build-arg VERSION=… weiter, das transports/Dockerfile setzte aber zusätzlich nochmal ein v davor (-X main.Version=v${VERSION}). Folge: Die Binary meldete ihre Version als vv1.4.23-ew-1.

  Behoben durch:

  • Default-ARG VERSION=v1.4.23-ew (mit v-Prefix).
  • ldflag jetzt -X main.Version=${VERSION} (kein zusätzliches v mehr).

  Makefile, Dockerfile.local und die GitHub-Action-Skripte lesen VERSION aus transports/version (Wert ohne v-Prefix) und behalten ihre v${VERSION}-Form bei — dort ist das v korrekt.

  Geänderte Dateien

  • core/providers/ew/ew.go — EWModelOwner-Konstante + Override-Loop in listModelsByKey.
  • core/providers/ew/list_models_test.go — Regression-Test für owned_by == "everyware".
  • transports/Dockerfile — doppeltes v entfernt.

  Upgrade

  Service neu starten und Docker-Image forge.engelmann.me/engel75/bifrost:v1.4.23-ew-2 ziehen (wird durch den Tag-Push gebaut).

  Vollständiger Changelog

  v1.4.23-ew-1...v1.4.23-ew-2

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads
• v1.4.23-ew-1 929fe7f562

  Compare

  v1.4.23-ew-1 — EW Provider + OpenAI-conformant errors Stable

  engel75 released this 2026-04-28 10:54:21 +02:00 | 6 commits to 1.4.23-ew since this release

  v1.4.23-ew-1

  Erstes Release des EW-flavored Bifrost-Forks. Setzt auf Upstream Bifrost v1.4.23 auf und ergänzt um den EW/SGLang-Provider, per-Key-API-Toggles sowie OpenAI-konforme Fehlerantworten auf den OpenAI-Compat-Routen.

  Highlights

  EW (SGLang) Provider

  • Neuer Provider ew für OpenAI-kompatible SGLang/EW-Instanzen
    • Per-Key-Konfiguration (ew_key_config.url, ew_key_config.model_name) — jede Key-Instanz routet auf einen eigenen Backend-Server
    • Round-Robin-Loadbalancing über mehrere SGLang-Backends
  • Streaming-Support für Chat, Text, Speech, Transcription
  • OpenAI-kompatible SpeechStream-Implementierung
  • SGLang-spezifischer Error-Parser (ParseSGLangError) — fängt sowohl die top-level ({"object":"error","message":...,"type":"BadRequestError","code":400}) als auch die streaming-wrapped ({"error":{...}}) Fehler-Shapes von SGLang ab und füllt den BifrostError mit der korrekten Message/Type

  Per-Key API Toggles

  Ein Operator kann pro EW-Key explizit steuern, welche APIs erlaubt sind:

  • ew_key_config.allowed_requests = null ⇒ alle APIs erlaubt (backwards compatible)
  • Explizite Whitelist für 16 EW-unterstützte APIs (Chat, Text, Responses, Embedding, Rerank, Speech, Transcription, Image-Gen/Edit/Variation, ListModels — jeweils inkl. Streaming-Varianten wo verfügbar)
  • Doppelte Durchsetzung:
    • Routing-Filter in selectKeyFromProviderForModel überspringt gesperrte Keys ⇒ Bifrost wählt automatisch einen anderen passenden Key
    • Defensiver Check in jeder EW-Provider-Methode liefert UnsupportedOperationError, falls der Key explizit per x-bf-key-id referenziert wird
  • UI-Toggles im Provider-Form (Workspace → Providers → EW Key)
  • Automatische DB-Migration add_ew_allowed_requests_column beim Start

  OpenAI-konforme Fehlerantworten

  Alle OpenAI-Compat-Routen liefern Fehler im OpenAI-Standardformat:

  {
    "is_bifrost_error": false,
    "status_code": 400,
    "error": {
      "message": "Requested token count exceeds the model's maximum context length of 196608 tokens. ...",
      "type": "invalid_request_error",
      "code": "context_length_exceeded",
      "param": "messages"
    },
    "extra_fields": {
      "provider": "ew",
      "model_requested": "minimax27",
      "request_type": "chat_completion_stream"
    }
  }
  

  • SGLang→OpenAI Type-Mapping: BadRequestError/BadRequest/DecodeError ⇒ invalid_request_error; InternalServerError/NotImplementedError ⇒ api_error; HTTP-Statuscodes (401/403/404/429) ⇒ authentication_error/permission_error/not_found_error/rate_limit_error.
  • Code-Heuristiken: „maximum context length" ⇒ context_length_exceeded; „no keys found" ⇒ model_not_found; pro Statuscode passende Defaults.
  • Bifrost-Diagnostik bleibt erhalten: is_bifrost_error, status_code und extra_fields an Top-Level (OpenAI-Clients ignorieren unbekannte Felder).
  • Vollständige Abdeckung: 45 ErrorConverter in integrations/openai.go, 2 in cursor.go, plus die nativen Pfade SendBifrostError/SendSSEError in handlers/utils.go.

  Bugfixes

  • Redaction-Lücke (framework/configstore/clientconfig.go): Beim Bauen der UI-Antwort wurden allowed_requests weggelassen, sodass beim Reload des Keys der Master-Switch auf „Allow All APIs" zurücksprang. ⇒ Behoben.
  • Native Streaming-Setup-Fehler: Wenn SGLang vor dem ersten SSE-Chunk einen 400 zurückgab, lief der Fehler durch SendBifrostError, das vorher den BifrostError 1:1 ausgab und die Integrations-ErrorConverter umging. ⇒ SendBifrostError/SendSSEError leiten jetzt durch ToOpenAIErrorEnvelope.

  Infrastruktur

  • Forgejo Actions Workflow (.forgejo/workflows/docker-release.yml): Baut Docker-Images automatisch auf v*-Tags und pusht nach forge.engelmann.me/engel75/bifrost:<tag>.
  • GitNexus MCP-Konfiguration für die Codebase.

  Wichtige Dateien

  Datei	Bedeutung
  core/providers/ew/ (NEU)	Kompletter EW-Provider inkl. errors.go (ParseSGLangError)
  core/schemas/account.go	EWKeyConfig.AllowedRequests
  core/bifrost.go	Routing-Filter für EW pro RequestType
  framework/configstore/tables/key.go + Migration	DB-Persistenz
  framework/configstore/clientconfig.go	Redaction-Bugfix
  transports/bifrost-http/integrations/utils.go	OpenAIErrorEnvelope, ToOpenAIErrorEnvelope, SGLang→OpenAI Mapping-Tabelle
  transports/bifrost-http/integrations/openai.go + cursor.go	ErrorConverter-Umstellung
  transports/bifrost-http/handlers/utils.go	SendBifrostError/SendSSEError durch Envelope geleitet
  ui/lib/types/config.ts, schemas.ts	TS-Typen + Zod-Schema für allowed_requests
  ui/app/workspace/providers/fragments/ewAllowedApisFields.tsx (NEU)	EW-spezifische API-Toggle-Komponente
  ui/app/workspace/providers/fragments/apiKeysFormFragment.tsx	Wiring des EW-Form-Bereichs

  Upgrade

  • Service neu starten — die DB-Migration läuft automatisch.
  • Bestehende EW-Keys behalten alle APIs erlaubt (Default allowed_requests = null).
  • Docker-Image: forge.engelmann.me/engel75/bifrost:v1.4.23-ew-1 (wird durch den Tag-Push gebaut).

  Bekannte Einschränkungen

  • Embedding-, Speech-, Transcription- (non-stream), Image-* haben keinen customErrorConverter-Slot in der OpenAI-Hilfsbibliothek. Dort werden Backend-Fehler weiterhin via ParseOpenAIError geparst — der Transport-Envelope normalisiert immerhin die JSON-Shape, aber bei tiefen Backend-Fehlern könnte die innere Message generisch sein („provider API error (status 400)") statt der originalen SGLang-Botschaft.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads