engel75/bifrost
1
0
Fork 1
Code Issues Pull requests Projects Releases 10 Packages 1 Wiki Activity Actions
10 releases 10 tags
  • v1.5.11-ew-2 9e762af0fd

    v1.5.11-ew-2: private network fix
    All checks were successful
    Docker Build / docker (push) Successful in 7m2s
    Details
    Docker Release / release (push) Successful in 6m23s
    Details
    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