rivet-dev/open-orange

What it does

OpenOrange is a runtime and deployment tool that runs an existing Cloudflare Workers project on AWS, Google Cloud, Azure, or your own machines with no application changes. It reads the same wrangler.jsonc, wrangler.json, or wrangler.toml configuration and implements the Workers API on Node.js instead of workerd, mapping each Cloudflare service onto Rivet Actors. Durable Objects become Rivet Actors with their own SQLite databases, and object SQLite state is backed by S3 through the Rivet control plane (architecture).

The trade-off it targets is Cloudflare's memory, CPU, connection, and storage ceilings, plus metering on long-running Durable Objects. The project claims lower compute and storage costs on raw cloud machines, with a published cost model. It is aimed at teams already on Workers who want to move off Cloudflare, keep the Wrangler workflow, and optionally self-host the whole stack.

Quickstart

Prepare a Worker project with a Wrangler config file (or use the hello-durable-object example), Node.js 22 or later, and pnpm. Deploying additionally requires Docker. The CLI is installed with:

pnpm add -g open-orange

Then, from the Worker project directory, start the local runtime:

orange dev

The Worker is served on http://127.0.0.1:8787; each Durable Object runs as a Rivet Actor with its local SQLite database under .open-orange/ (quickstart). To deploy, authenticate, link a cluster, and push the Worker:

orange login
orange link --cluster <cluster-name>
orange deploy

A successful deploy prints the application name and its public URL. The deploy guide covers Rivet Cloud, BYOC, and self-hosting; orange deploy --dry-run --outdir out produces a Dockerfile and build context without calling an API for manual image builds.

Compatibility and constraints

Binding support is uneven. KV, D1, Rate Limiting, Queues, Cron Triggers, and Hyperdrive are described as drop-in; Durable Objects, Cache, Workflows, Tail Workers, and Worker Loader are partial with known differences; R2, Workers AI, Send Email, Browser Rendering, and Sandbox are pluggable and need a configured provider. Analytics Engine drops data points, and Vectorize, Images, Media, Stream, Pipelines, AI Search, mTLS certificates, VPC, and legacy blobs are unsupported and throw on use (bindings). Teams should check the compatibility results for the specific services they use.

Data migration is not uniform: orange migrate moves Durable Objects with zero downtime, D1 databases are interrupted for a few minutes during copy, and R2 buckets are moved with S3-compatible tools such as rclone or aws s3 sync (migration guide). Node.js 22 and pnpm are required, deployment uses Docker, and self-hosting depends on deploying the Rivet control plane and worker nodes separately for your platform (self-host). The project is Apache-2.0 licensed and not affiliated with Cloudflare.

HotRepo's take

OpenOrange appeared on HotRepo's new-project board on 2026-11-12, listing 107 stars and 3 forks within a growth window of roughly 17.5 hours, landing in the TypeScript category. That is a fast first-day signal for a project whose pitch depends on backends and migration paths rather than a visual demo, but one snapshot does not establish a sustained trend.

What the technical material makes worth watching is the scope: it replaces not just the runtime but the surrounding services, and its own binding table admits several partial or unsupported pieces. The drop-in claim for a real Worker will stand or fall on that table and on the migration story for D1 and R2, not on the launch-day star count.