Cloudflare Rpc
You set up cloudflare rpc by linking two serverless workers with a service binding. This setup lets one worker call methods on another worker without public network hops. Teams use this approach to split large apps into smaller backend services. Still, broad service bindings often give calling workers full access to every exposed method. If one front-end worker gets compromised, it can trigger sensitive actions across the backend. How cloudflare rpc works under the hood Standard web calls sen
Rpc: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up cloudflare rpc by linking two serverless workers with a service binding. This setup lets one worker call methods on another worker without public network hops. Teams use this approach to split large apps into smaller backend services. Still, broad service bindings often give calling workers full access to every exposed method. If one front-end worker gets compromised, it can trigger sensitive actions across the backend.
How cloudflare rpc works under the hood
Standard web calls send data over public networks using slow text formats. Service bindings change this by linking two workers inside the same edge runtime. You define a main entrypoint class in your target worker to expose methods. The calling worker then invokes those methods directly as if they were local functions.
Both workers often run inside the same thread on the same edge server. The platform passes structured data objects between them with near-zero latency. You do not need to manage public URLs or external API keys for this link. The platform enforces the trust boundary based on your binding declarations at deploy time.
Developers can also pass object references across the binding to maintain state. This design makes it easy to build modular apps that still run fast. One worker can handle user logins while another worker runs database queries. Each piece stays small, focused, and easy for a single team to maintain.
What native bindings solve and what they leave open
Native service bindings solve the problem of network overhead and public exposure. Your internal worker does not need a public route on the internet. Only the specific workers listed in your account settings can invoke its methods. This setup blocks outside attackers from hitting your internal backend services directly.
Still, a binding acts as an all-or-nothing link between two workers. Once linked, the caller can invoke any public method on the target class. The native binding does not inspect the parameters inside each method call. It also does not check which human user or admin triggered the action.
Rpc: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
When a worker queries a database or internal API, another gap appears. The worker usually holds a static database key or token in its secret store. Every call through that worker uses the exact same high-level database role. Audit logs in the database only show the worker identity, not the team member.
Managing backend actions and sensitive data in flight
Real security requires checking what each request does before it hits your data store. Teams need to control which specific queries or commands can run in production. You also need a clear log of who triggered each backend task. Static worker secrets cannot give you this level of detail on their own.
Data privacy is another major concern when workers pass user records around. A backend query might return emails, phone numbers, card numbers, or national IDs. Without field-level checks, raw records flow straight back to the calling service. Data masking rewrites matched fields in results before they reach the caller. This keeps sensitive values out of logs, debug output, and client responses.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How does cloudflare rpc differ from a standard HTTP fetch binding?
A fetch binding requires you to format requests and parse responses like web traffic. The remote procedure call method lets you invoke functions and pass objects directly.
Do two linked workers need public routes to talk to each other?
No, the target worker can remain completely private without any public route. The calling worker reaches it through the internal runtime binding defined at deploy time.
How can teams protect sensitive fields returned to a worker?
Teams can apply data masking rules between the worker and the database. Masking rewrites matched fields like emails or card numbers in the query results.