The same routing engine as the binary — run by us. Point your app at a tenant endpoint, configure providers in a UI, and stop deploying, scaling, and patching a sidecar. Your team never handles raw provider keys again.
If your app already sits behind a hosted RPC gateway, you've already accepted the hop.
Cloud is the same zero-ops model — we run the routing engine, you configure providers in a UI — except the routing you're paying for is the same engine you can take self-hosted, free, any time. The binary and Cloud share one config, so there's no lock-in: start managed, move it in-house, or run both. It's a like-for-like swap, not a new hop.
Three ways to use the same engine. Start free, hand off operations when it makes sense.
You run the proxy. You keep your keys. Full routing intelligence, zero cost.
You run the binary; we host observability, cost analytics, and alerts.
We run the proxy too. You configure providers in a UI. No infrastructure to operate.
No sidecar to deploy, scale, or patch. Routing, failover, and health scoring run on our infrastructure, sized to your traffic.
Point your app at {tenant}.rpcplane.dev. One stable URL in front of all your providers — no localhost, no container.
Add providers, tune routing, set per-app policy from the dashboard. Changes apply without a redeploy.
Provider keys are stored encrypted and rotated instantly from the UI — no scrambling to redeploy every service when a key leaks.
Rate limits, budget caps, IP/origin allowlists, and method blocklists enforced at the edge — before a request ever reaches a provider.
Roles, audit log, and SSO (SAML / Okta / Azure AD) so access to your RPC layer is governed like the rest of your stack.
The full dashboard — health history, cost analytics, alerts — comes with it, nothing to wire up.
You still bring your own provider keys, so there are no per-request fees from us beyond the managed-service cost.
Identical routing strategies, circuit breakers, write broadcast, and HTTP/3 as the open binary — no behaviour to relearn.
Picture ten developers and four providers. Today that's forty places a raw key can leak — every .env, every CI job, every laptop — and offboarding one person means rotating all four. Managed cloud inverts it: admins add the four provider keys once, each service gets a scoped rp_live_ app token, and developers point at the tenant endpoint. No dev ever needs a per-provider account, and the underlying keys never leave the platform.
# before — every dev holds every provider key # 10 devs × 4 providers = 40 secrets to rotate service-a/.env RPC_KEY_A=... RPC_KEY_B=... service-b/.env RPC_KEY_A=... RPC_KEY_C=... ci/secrets RPC_KEY_D=... # after — one app token per service, keys held by admins export RPC_PLANE_TOKEN=rp_live_9f2c… all services → https://acme.rpcplane.dev # offboard a dev → revoke one token, rotate nothing
No platform engineer to own a sidecar fleet — let us run it.
Many services sharing providers; central key management and policy beats copy-pasting .env files.
SSO, audit, encrypted key storage, and per-app scoping for governed access to the RPC layer.
Same routing engine, run by us. Instead of deploying and scaling the sidecar, you point at a tenant endpoint and configure providers in a UI.
Yes. The binary is free and source-available under ELv2 and stays that way. Managed cloud is an optional convenience.
Provider keys are stored encrypted, scoped per app, and rotated centrally. Developers use a tenant endpoint and never handle raw keys.
It's on the roadmap. Join the waitlist to be notified and to help shape priorities.
Usage-based — you bring your own provider keys, so no per-request fees from us beyond the managed-service cost. Details before launch.
Yes — run the free binary today and migrate to managed cloud when it ships; same config concepts carry over.
Drop your email to get early access and help shape what ships first.