OpenWorkers – Selbstgehostete Cloudflare Workers, implementiert in Rust

 (openworkers.com)
19 Punkte von GN⁺ 2026-01-02 | 1 Kommentare | Auf WhatsApp teilen
  • OpenWorkers ist eine Open-Source-Runtime, die JavaScript auf Basis von V8 ausführt und Edge Computing auf eigener Infrastruktur ermöglicht
  • Unterstützt KV-Speicher, PostgreSQL, S3/R2-kompatiblen Storage, Service Bindings sowie Umgebungsvariablen und Secrets
  • Bietet eine hohe Kompatibilität zu Cloudflare Workers, einschließlich wichtiger Web APIs wie fetch, ReadableStream und crypto.subtle
  • Einfaches Self-Hosting mit V8-Isolate-Sandbox, Cron-Scheduling und Deployment auf Basis von Docker Compose
  • Ein über rund 7 Jahre gewachsenes Projekt mit dem Ziel einer vendorunabhängigen JavaScript-Laufzeitumgebung

Überblick über OpenWorkers

  • OpenWorkers ist eine in Rust geschriebene Cloudflare-Workers-kompatible Runtime, die JavaScript mit V8 Isolates ausführt
    • Die Vorteile von Edge Computing lassen sich damit auch in einer eigenen Serverumgebung nutzen
    • Als Open Source veröffentlicht und frei verteil- und anpassbar

Hauptfunktionen

  • Über Bindings lassen sich verschiedene externe Ressourcen anbinden
    • KV-Storage: unterstützt get, put, delete, list
    • Anbindung an PostgreSQL-Datenbanken
    • Unterstützung für S3/R2-kompatiblen Storage
    • Einschließlich Service Bindings sowie Verwaltung von Umgebungsvariablen und Secrets
  • Web-API-Unterstützung
    • Stellt Standard-APIs wie fetch, Request, Response und ReadableStream bereit
    • Einschließlich crypto.subtle, TextEncoder/Decoder, Blob, setTimeout und AbortController

Architektur

  • Das System besteht aus nginx-Proxy, Dashboard, API, Logging-Service, Runner, PostgreSQL, NATS und Scheduler
    • Jeder Runner führt Code innerhalb eines V8 Isolates aus; es gelten Limits von 100 ms CPU und 128 MB Speicher
    • Enthält einen integrierten Scheduler mit Unterstützung für Cron-Syntax mit 5 oder 6 Feldern
    • Bewahrt Syntaxkompatibilität zu Cloudflare Workers

Self-Hosting

  • Das Deployment ist bereits mit einer einzelnen PostgreSQL-Datenbank und einer Docker-Compose-Datei möglich
    • Lässt sich einfach mit den Befehlen git clone, .env-Konfiguration und docker compose up starten
    • Einschließlich Verfahren für Migrationen und Token-Erstellung

Entwicklungshintergrund

  • Ein Projekt, das in etwa 7 Jahren Entwicklungsarbeit entstanden ist
    • Anfangs wurde mit vm2 für JS-Sandboxing experimentiert, später inspiriert vom Modell von Cloudflare Workers weiterentwickelt
    • Nach Deno-core inzwischen auf Basis von rusty_v8 neu geschrieben
  • Ziel ist der Aufbau einer eigenen Server-Laufzeitumgebung ohne Vendor Lock-in, die zugleich eine Developer Experience (DX) auf dem Niveau von Cloudflare Workers bietet
  • Künftig ist die Ergänzung von deterministischem Debugging durch Ausführungsaufzeichnung und Replay-Funktion geplant

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-02
Hacker-News-Kommentare

  • Das Konzept, die Power von Edge Computing auf die eigene Infrastruktur zu holen, ist interessant.
    Allerdings fühlt sich Self-Hosting auch etwas widersprüchlich zum eigentlichen Wesen von Edge Computing an.
    Das ist ein Modell, das nur möglich ist, weil große Anbieter wie Cloudflare weltweit mehr als 300 PoPs (Points of Presence) betreiben.
    Natürlich könnte man eine ähnliche Struktur auch durch die Kombination kleinerer, ethischerer Anbieter aufbauen, aber das bringt deutlich mehr Aufwand und Risiken mit sich.

    • Ich frage mich, ob man wirklich 300 PoPs braucht, um die Vorteile des Edge-Modells zu bekommen.
      Ich denke, etwa 10 in den wichtigsten Regionen könnten schon ausreichen.
    • Ich frage mich, ob ein Modell möglich wäre, bei dem dezentrale Host-Netzwerke zusammenarbeiten, um das Monopol von Cloudflare aufzubrechen.
      Gleichzeitig habe ich Bedenken, ob sich das sicher und zuverlässig koordinieren lässt.

  • Das Problem bei Sandbox-Lösungen ist, dass es eine starke Garantie geben muss, dass der Code nicht aus der Sandbox ausbrechen kann.
    Um das nachzuweisen, braucht man Testergebnisse zu verschiedenen Angriffsszenarien und eine ausführliche Dokumentation.
    Dokumentation auf diesem Niveau ist jedoch sehr selten, und tatsächlich ist es schwer, vertrauenswürdige Beispiele zu finden.
    Deshalb prüfe ich immer, ob es Fälle gibt, in denen große Unternehmen das tatsächlich in Produktionsumgebungen einsetzen und Security-Teams die Wartung übernehmen.

    • Stimme ich zu. KI steigert zwar die Produktivität, aber in einer Hochsicherheitsumgebung klingt die Aussage „mit Hilfe von Claude auf rusty_v8 neu geschrieben“ eher beunruhigend.
    • Einer der Gründe, warum die Cloudflare-Workers-Runtime sicher ist, liegt darin, dass sie die Synchronisierung mit dem V8-Mainline sehr konsequent beibehält.
      Teilweise werden V8-Releases dort sogar vor Chrome übernommen.
    • V8-Isolates bieten Speicherisolation und setzen Limits für CPU (100 ms) und Speicher (128 MB).
      Jeder Worker läuft als Isolate statt als separater Prozess, ähnlich wie im Cloudflare-Modell.
      Wenn man jedoch vollständig nicht vertrauenswürdigen Third-Party-Code verarbeitet, ist es besser, zusätzlich Container oder VMs als weitere Isolationsschicht einzusetzen.
      Dieses Sandboxing ist eher auf Ressourcenisolation als auf Sicherheit ausgerichtet.
    • Ich halte es für unrealistisch, so perfekte Garantien zu verlangen.
      Ein Security-Audit nach dem Muster „Wir haben es geprüft, es ist sicher, vertrauen Sie uns“ reicht dafür nicht aus.
    • Bei Cloudflare ist Sandbox-Sicherheit essenziell, weil User-Code bösartig sein kann.
      In einer Self-Hosting-Umgebung muss man sich über Sandbox-Escapes aber weniger Sorgen machen, weil dort ohnehin bereits Systemzugriff vorhanden ist.

  • Ich denke, das ist ein großartiges Projekt.
    Wenn workerd Open Source ist, frage ich mich, ob sich OpenWorkers dadurch unterscheidet, dass es eine vollständige Umgebung bereitstellt.
    Mich würde auch interessieren, ob es Unterschiede in der Runtime selbst gibt oder ob künftig ein Managed Service geplant ist.

    • Es gibt drei Hauptunterschiede.
      1️⃣ workerd liefert nur die Runtime, während OpenWorkers eine vollständige Plattform inklusive Dashboard, API, Scheduler, Logs und Bindings (KV, S3/R2, Postgres) bietet.
      2️⃣ workerd basiert auf C++, OpenWorkers auf Rust + rusty_v8 und ist dadurch einfacher und leichter zu hacken.
      3️⃣ Unter dash.openworkers.com gibt es bereits eine Managed-Version, inklusive Free Tier.
      Trotzdem ist Self-Hosting als First-Class Citizen konzipiert.

  • Der Kern von Cloudflare Workers ist die Abrechnung pro Funktion, aber bei Self-Hosting muss man die Hardware letztlich im Voraus bereitstellen.

    • Viele Unternehmen betreiben immer noch Server in eigenen Rechenzentren.
      Man muss nicht alles auslagern, und es ist gut, dass es vergleichbare Alternativen gibt.
      Solche Optionen helfen, die Einstiegshürde zu senken.

  • Ich habe früher viel an der Entkopplung von deno_core gearbeitet, daher kann ich nachvollziehen, warum auf rohes rusty_v8 umgestiegen wurde.
    In deno_core gibt es viel Legacy-Code, und bei Änderungen gingen oft Tests kaputt.

    • Danke! deno_core ist nach wie vor eine großartige Codebasis, deshalb pflegen wir es weiter als openworkers-runtime-deno.
      Für feinere Kontrolle über das Innere der Runtime sind wir aber auf rusty_v8 gewechselt,
      und später wollen wir auch fehlende Features wieder in die deno-Runtime zurückbringen.

  • Wenn ein Projekt hilft, Vendor Lock-in zu verringern, bin ich immer dafür.
    Ich hoffe, dass Cloud-Anbieter dadurch unter Druck geraten, ihre Preise wieder realistischer zu gestalten.
    Derzeit werden selbst für grundlegende Funktionen wie NAT überhöhte Gebühren verlangt.
    Natürlich ist die Cloud bequem, aber die hohen Kosten im Vergleich zu DIY sind das Problem.

    • Die Cloudflare-Workers-Runtime ist bereits Open Source: cloudflare/workerd
    • Ich mache mir Sorgen, dass die zuletzt gestiegenen RAM-Preise Self-Hosting noch schwieriger machen könnten.
      Wenn große Unternehmen Ressourcen monopolisieren, könnte es für Einzelpersonen schwerer werden, selbst zu hosten.
    • Die Formulierung, dass NAT „teurer als kostenlos“ sei, ist interessant.
      In vielen Ländern sind die Kosten des Eigenbetriebs in der Praxis aber noch höher.
      Es ist nicht mit der Installation getan; auch Wartungspersonal und Monitoring verursachen erhebliche Kosten.

  • Es wäre gut, in der Dokumentation anzugeben, welche Features aktuell nicht funktionieren und wie die Roadmap aussieht.

    • Guter Vorschlag! Noch nicht implementiert sind Durable Objects, WebSockets, HTMLRewriter und die cache API.
      Die nächste Priorität ist eine Debugging-Funktion für Execution Recording/Replay, und wir planen, der Dokumentation einen Roadmap-Bereich hinzuzufügen.

  • Das ASCII-Architekturdiagramm sieht auf Pixel + Firefox kaputt aus.
    Textbasierte Diagramme sind zwar charmant, aber in der Praxis ist es oft sinnvoller, eine als Bild gerenderte Version zu veröffentlichen.

    • Danke für den Hinweis! Ich habe das Problem behoben, indem ich eine vereinfachte ASCII-Version für Mobilgeräte hinzugefügt habe.
    • Auf meinem iPhone 11 mit Safari wird es perfekt gerendert.

  • Sowohl technisch als auch strukturell ist das eine hervorragende Produktidee.
    Mir gefällt besonders das Modell, ein Open-Source-Projekt eines großen Anbieters quasi mit Open Source zurückzuspielen.
    Statt dass sie Open Source nehmen und kommerzialisieren, geben wir ihr Modell als Open Source zurück — genau so ein Ansatz ist meiner Meinung nach richtig.

  • Es wirkt, als käme gerade wieder die Idee auf: „Was wäre, wenn wir die Cloud direkt auf unseren eigenen Rechnern hosten?“
    In letzter Zeit sieht man diesen Self-Hosting-Trend an mehreren Stellen.
    Das dazugehörige Vortragsvideo ist ebenfalls interessant.

    • Ich finde allerdings, dass man das dann kaum noch „Cloud“ nennen kann.
      Der Kern der Cloud ist Elastizität (elasticity).
      Man skaliert Instanzen je nach Bedarf hoch und runter und zahlt nur für das, was man nutzt.
      Self-Hosting bietet zwar bequeme Deployment-Tools, aber letztlich muss man die gesamten Serverkosten tragen.
      Bei konstanter oder vorhersehbarer Last ist das in Ordnung, andernfalls ineffizient.
      (Bildlich gesprochen ist das der Unterschied zwischen Busfahren und dem Besitz eines Vans.)
    • Der Wert von FaaS (Function-as-a-Service) liegt weniger im Wort „Cloud“ als in der Bereitstellung eines eventgetriebenen Frameworks.
      Entwickler können sich auf die Implementierung von Event-Handlern konzentrieren, und mit Queues oder dauerhafter Ausführung wird das noch leistungsfähiger.
      Letztlich ist FaaS ein High-Level-Tool, das Boilerplate-Code abstrahiert.