Best approach to expose internal Payload instance to another Cloudflare Worker using Service Bindings?

[AliSananS]

Hey team,
I’m experimenting with a Worker-native setup using Payload + @opennextjs/cloudflare.

Architecture goal:

• CMS runs as a dedicated Worker (Payload instance)
• Frontend SSR runs as a separate Worker
• Use Cloudflare Service Bindings for internal calls (no HTTP hops, no external endpoints)

Cloudflare Workers allow this pattern: a Worker can expose methods and another Worker can call them like normal functions. For example:

export default {
  fetch: handler.fetch,
  foo: async (args) => `Hello: ${args}`,
}

Service bindings
Custom worker with opennext

Then from a different frontend Worker:

const result = await env.CMS.foo("bar"); // "Hello: bar"

This works perfectly for simple functions.

---

What I’m trying to do

Expose a Payload instance from the CMS Worker so the frontend Worker can call internal APIs directly:

• getPayload() instance
• server-only utils (auth, validation, queries, user lookup, etc.)
• avoid making everything go through HTTP routes

---

Problem

When exporting the Payload instance in the custom Worker:

• bundling breaks because of dependencies like file-type, sharp, Node streams, etc
• Essentially anything Payload depends on during init causes a Workers-incompatible crash

Even if I don’t use these features (image processing disabled), simply exposing the instance causes bundling issues.

---

Questions

1. Is this pattern unsupported on purpose?
   i.e. Should Payload only be accessed through HTTP routes when deployed to Workers?

2. Is there a recommended way to expose internal operations from Payload Worker → another Worker, beyond HTTP endpoints?

3. If we want a fully Worker-native monorepo:

   • Payload Worker → internal methods
   • Frontend Worker → calls those methods via bindings
     What’s the best strategy to avoid dependency/bundling hell?

---

Context

I’ve already discussed this with the @opennextjs/cloudflare team.
Their architecture allows splitting concerns across Workers, and service bindings do not add extra request counts.

Payload on Workers is already in a great place, especially with current work happening around OpenNext + Cloudflare runtime.
Just looking to understand whether direct Worker-to-Worker service access (without public fetch endpoints) is a realistic first-class approach or fundamentally against the current architecture.

---

NOTE: Yes, there is an easy option to make fetch requests to the payload worker using env.CMS.fetch("/api/query"), but I'm trying to use the local API as it is easier to query data compared to Rest-API.
This method still has zero latency as a service method call.

Thanks