Error when trying to host 3.0 Demo on Cloudflare Pages (Edge Runtime)

[todor0v]

Upon trying to host the 3.0 Demo on Cloudflare Pages I get this error:

The following routes were not configured to run with the Edge Runtime:
  - /api/[...slug]
  - /api/graphql-playground
  - /api/graphql
  - /admin/[[...segments]]
Please make sure that all your non-static routes export the following edge runtime route segment config:
  export const runtime = 'edge';

If I add the nodejs_compat flag to CF compatibility flags and export const runtime = 'edge' to the appropriate Payload page.ts and route.ts files (even though I know I shouldn't), I get Module not found: Can't resolve 'path' (fs and stream) all connected to node_modules/atomically and node_modules/busboy.

In the demo video @jmikrut mentioned that we are close to Edge Runtime support. I assume I have those errors because we are not there yet.

[jmikrut]

Correct, we're not there just yet. But - this is super interesting. What are the steps that you're following to deploy to Cloudflare Pages?

I will convert this to a discussion on the main Payload repo so we can track conversation accordingly.

[todor0v]

@jmikrut Thank you for all the suggestions! Here are roughly the steps that I took:

1. I took my existing Next.js 14 project that was hosted on Vercel
2. I used npx create-payload-app@beta to install Payload. This pretty much worked on Vercel out of the box. The only change I had to make was to add revalidatePath on afterChange so the content changes are visible as soon as you make any from the panel:

(Home.ts)

hooks: {
   afterChange: [
      ({ req, doc }) => {
         revalidatePath("/");
      },
   ]
}

3. I am using the Payload local API to get my data. I also added authentication using Next Auth (5 beta) that supports running on edge and a custom auth strategy. All of that worked on Vercel.
4. I used the Cloudflare Full-stack Next.js guide in order to host Next.js on its own on Cloudflare Pages. I then merged with my Payload branch.
5. I added the nodejs_compat comparability flag to the CF Functions.
6. I used bun. It actually worked better than node. (though I do get a message: "The project is set up for bun but it is currently being run via npm")
7. I got the original "following routes were not configured to run with the Edge Runtime" error.
8. I added export const runtime = "edge"; to the layout.tsx file inside app/(payload).
9. I ran into the original errors: Module not found: Can't resolve 'path' (fs and stream)

I am pretty sure that this will be possible at some point. Like you mentioned in the video, Payload is already the proper size. Now the compatibility issues are left.

[kimstewartca]

Hi, were you able to get Payload v3 running on Cloudflare Pages? I am experiencing the same build error in Cloudflare Pages, and as of right now I can only get it working on Vercel.

[todor0v]

@kimstewartca Unfortunately no. As I understand from @jmikrut some changes will be required in Payload 3.0 but it should be possible in the future.

[jmikrut]

@todor0v — what database adapter were you using? No errors from the DB adapter?

[todor0v]

@jmikrut I will write the full steps I went through in a bit. I am using the mongooseAdapter. I have not faced any errors there. Or at least I don't think the errors I see are from that.

[frederichoule]

@todor0v — what database adapter were you using? No errors from the DB adapter?

Most serverless database providers have a serverless driver that we can use, for example https://github.com/neondatabase/serverless for Neon/PostgreSQL

By using a serverless driver + the S3 plugin (or any other cloud), there's no reason Payload can't run on the edge.

[cortopy]

that's the theory, but sadly it's not the reality. I tried exactly that: neon db + r2 for storage and I still couldn't make it work with cloudflare. There were so many errors even when previewing in local environment!

The reason for that is that next js is notoriously bad for hosting outside of Vercel. It seems to me that by picking Next JS as the framework, Payload has already limited the product to where it could be hosted.

There are new initiatives that Cloudflare is involved with like opennextjs, but is still not enough as per my time trying it out

[frederichoule]

that's the theory, but sadly it's not the reality. I tried exactly that: neon db + r2 for storage and I still couldn't make it work with cloudflare. There were so many errors even when previewing in local environment!

The reason for that is that next js is notoriously bad for hosting outside of Vercel. It seems to me that by picking Next JS as the framework, Payload has already limited the product to where it could be hosted.

There are new initiatives that Cloudflare is involved with like opennextjs, but is still not enough as per my time trying it out

That's unfortunate. Hopefully the team can manage to get that running on all edge runtimes.

Some interesting reading:

• https://developers.cloudflare.com/pages/framework-guides/nextjs/ssr/supported-features/ (edit: most new features on Next uses the Node.js runtime, so @cloudflare/next-on-pages is not a good path forward)
• https://opennext.js.org/cloudflare

I'll probably end up hosting Payload on Vercel, there's no real alternative.

[jmikrut]

One more thought here for anyone who is interested in testing further on this.

If you add a fallback for fs, stream and path to your next.config.js file's Webpack config, you might be able to get around these issues.

[jmikrut]

I think you'd want to do that on the server and not for client. The server code is what is executed in cloudflare workers.

Also, I wouldn't expect this to work right away - I'd just expect a different error. Because we do indeed use fs still in certain cases, but I think we might be able to work around those one by one.

Last note - Mongoose actually is not compatible with Cloudflare Workers as far as I know. If you do want to deploy on Cloudflare, you might have to use Postgres - but let me know!

[todor0v]

@jmikrut That is correct yes. Has to be on the server! I had to keep going until I see a different error 😆

webpack: (config, { isServer }) => {
   if (isServer) {
      config.resolve.fallback = {
      fs: false,
      stream: false,
      path: false,
      os: false,
      crypto: false,
      tty: false,
      readline: false,
      child_process: false,
      worker_threads: false,
   };
}

Now I get the following for both path and os:

node:os
Module build failed: UnhandledSchemeError: Reading from "node:os" is not handled by plugins (Unhandled scheme).
Webpack supports "data:" and "file:" URIs by default.
You may need an additional plugin to handle "node:" URIs.

As for the database. Even though in the CloudFlare docs they do have a guide for MongoDB, that still uses a rest API, whereas I just want to provide Payload with the database URL. So that is correct. I will need to move to Postgres if I want it hosted on CF D1. However, I should be able to use a connection to Atlas for now. Nevertheless if I do get any errors that are connected to the database, I am prepared to switch to Postgres. I actually started that process. I saw that the Payload Postgres Adapter on the beta branch is using Drizzle so I made sure to install that since it should be supported on D1. Let me know if you believe that I should move to Postgres first and then try to fix the fs, stream etc error.

[jbwashington]

@todor0v just a heads up, i'm using Postgres adapter and running into the same problems with payload 3.0 beta and Nextjs 14:

13:56:14.290 | ⚡️ 	The following routes were not configured to run with the Edge Runtime:
-- | --
13:56:14.290 | ⚡️ 	  - /admin/[[...segments]]
13:56:14.291 | ⚡️ 	  - /api/[...slug]
13:56:14.291 | ⚡️ 	  - /api/graphql-playground
13:56:14.291 | ⚡️ 	  - /api/graphql
13:56:14.291 | ⚡️ 	  - /[slug]
13:56:14.291 | ⚡️ 	  - /posts/[slug]
13:56:14.291 | ⚡️ 	  - /projects/[slug]
13:56:14.291 | ⚡️
13:56:14.291 | ⚡️ 	Please make sure that all your non-static routes export the following edge runtime route segment config:
13:56:14.291 | ⚡️ 	  export const runtime = 'edge';

[janus-reith]

I'm wondering, has someone been successful yet with Deploying Payload to CF Pages yet after setting runtime = 'edge' on all routes and using Drizzle, or are there other roadblocks that maybe surfaced after that?

[todor0v]

@janus-reith As explained in the steps I took here. You can use export const runtime = "edge"; in the layout.tsx file inside app/(payload). This way it will apply to all routes. However, this doesn't fix the later dependencies issues.

[janus-reith]

Related: brianc/node-postgres#3206

[aretrace]

@jmikrut, is there a loose timeline for official serverless Cloudflare support?

[internalG]

It seems all nextjs + postgres projects hit this edge wall now.

[0xRapid]

I think this is surely one of the more interesting approaches, I only came around payload today and I was instantly thinking of hosting it in cloudflare, would love more out of the box support though!

[BohdanK-W32]

Sure thing, looks like a must-have for now.
Also, PayloadCMS 3 don't have an image optimization API for now. Hope it will be added soon, so we can use other providers, not sharp only (which is impossible on Cloudflare, due to multi-threading requirement for sharp).

[rcotrina94]

Maybe using Cloudflare Images?

[ammi1378]

I tried it and uploading to Cloudflare R2 worked well on my machine, unfortunately i didn't had the time to deploy it on cloudflare pges or workers. '@payloadcms/storage-s3' package works great for this.

it would be good to be able to disable payload image optimzation and let cloudflare take over it by using their images service which i belive is compatible with their R2 service.

i'm willing to investigate in this subject if someone from the team could guide me. @jmikrut

[parsadotsh]

I think adding a flexible and simple "url" resizer option, i.e. just redirect the image to another service like "https://resizer.site.com/?image=link.to.image.com&size=400,800" that handles resizing. Then developers can implement their own service using libraries like https://github.com/fineshopdesign/cf-wasm (or this could be integrated too!)

https://github.com/fineshopdesign/cf-wasm On cloudflare at least, doesn't work for huge files but it's definitely usable for the majority of cases.

[frederichoule]

I think adding a flexible and simple "url" resizer option, i.e. just redirect the image to another service like "https://resizer.site.com/?image=link.to.image.com&size=400,800" that handles resizing. Then developers can implement their own service using libraries like https://github.com/fineshopdesign/cf-wasm (or this could be integrated too!)

https://github.com/fineshopdesign/cf-wasm On cloudflare at least, doesn't work for huge files but it's definitely usable for the majority of cases.

That would be excellent.

I tried it and uploading to Cloudflare R2 worked well on my machine, unfortunately i didn't had the time to deploy it on cloudflare pges or workers. '@payloadcms/storage-s3' package works great for this.

it would be good to be able to disable payload image optimzation and let cloudflare take over it by using their images service which i belive is compatible with their R2 service.

i'm willing to investigate in this subject if someone from the team could guide me. @jmikrut

Their images service is good and works well, but gets pretty costly for bigger websites. We currently have a 1,000$/month bill, and 950$ of it is for image processing, the rest for Workers. I think a "URL" resizer option would be more flexible, and then you can use Cloudflare Images if you want to.

[Vichp]

@jmikrut, any news on when Payload could run on the Edge Runtime, thus being able to be hosted on Cloudflare Pages? Thanks

[denolfe]

Now that this OpenNext issue has been resolved. We recently did some re-investigation into this.

It appears there are some issues with the Pino logger, and all DB adapters running in this environment. We'll be diving deeper into this, but it may require rethinking some of our DB adapters or introducing a new one for this runtime.

I clearly remember the Payload team promised to implement the uploads adapters to remove direct dependency on sharp before 3.0 stable release

@BohdanK-W32 Sharp actually did become optional, you do not need to pass it into your config. You obviously lose all sharp capabilities when doing this, though. Worth noting that we have dynamic resizing of images on our roadmap.

[nvti]

@denolfe I tried OpenNext with Cloudflare Worker on some of my projects but realized it has many bugs and lacks support.
Cloudflare Pages is more stable to work with NextJs but supports only Edge runtime.

[BohdanK-W32]

@BohdanK-W32 Sharp actually did become optional, you do not need to pass it into your config. You obviously lose all sharp capabilities when doing this, though. Worth noting that we have dynamic resizing of images on our roadmap.

Yup, but no alternate upload adapters though

[jynzo94]

I'm waiting for it too.

[MojoCreator]

Hono.dev would have been a better option. Hono with Drizzle/D1 + Pages + Workers on Cloudflare is a beast. We have been watching for Payload + Cloudflare progress on this front for close to 3 years........still watching.

[franz101]

Is there a fork? I feel like with durable storage upload could be solved?

[miguderp]

OpenNext with the Cloudflare adapter is now in 1.0-beta (https://x.com/CloudflareDev/status/1909598450871652398).
I wonder if this unlocks a few things?

Also, I reckon it's useless now that you guys are building on Turbopack but there's also this https://blog.cloudflare.com/introducing-the-cloudflare-vite-plugin/

[eortegaz]

I was able to get it running with opennext on cloudflare using turso (sqlite/libsql) as database and an s3-compatible storage provider today. However I randomly get errors saying: Error: Neon: unsupported Linux architecture. Seems like there is some issue with libsql in my case but it works 90% of the time. No idea yet why it randomly doesn't work sometimes. Haven't looked at emailing yet…

Can you reproduce your process?

[leonceaklin]

I made a minimal example here that uses opennext: https://github.com/leonceaklin/payload-cloudflare-test
And here's the deployed version of it: https://payload-cloudflare-test.zebrapig.workers.dev/admin
Login: [email protected]
Password: admin
If it doesn't work, just reload a few times.

[janus-reith]

Error: Neon: unsupported Linux architecture

I wonder if that might be related to Neon the database provider somehow and maybe compatibility code is injected mistakenly

[PeteJStewart]

It seems other than this issue with Error: Neon: unsupported Linux architecture, it is possible to run Payload on Cloudflare workers!
However, the error is quite a big issue, as it seems to bin quite often due to that.
I've looked through the git history, and can't find anything that references that error, so unless it's in a binary, it's somewhat of a mystery!

I would love to get this working fulling, so if there are any thoughts on what might be making the issue, that would be great!!

[PeteJStewart]

I've been doing a little more digging, and it would seem this is more a Cloudflare Workers error, rather than coming from payload.

I think the issue is due to the way '@libsql/client' & 'drizzle-orm/libsql' are imported.

payload/packages/db-sqlite/src/connect.ts

Lines 4 to 6 in 3701de5

	import { createClient } from '@libsql/client'
	import { pushDevSchema } from '@payloadcms/drizzle'
	import { drizzle } from 'drizzle-orm/libsql'

Here is a similar issue where the solution was to import the web versions.

tursodatabase/libsql-client-ts#303

import { createClient } from '@libsql/client/web';
import { drizzle } from 'drizzle-orm/libsql/web';

instead of:

import { createClient } from '@libsql/client';
import { drizzle } from 'drizzle-orm/libsql';

I assume this would need to be a new sqlite package, though, as this is different to how most servers would want to run it.

[leonceaklin]

Hi Pete Thank you for taking a look at this! All I know is that I am running the libsql client without problems in production in a Hono project on Cloudflare Workers which is why I‘m not sure if the library should be replaced. I think the @libsql/client package should be compatible in general. Don‘t have any Idea where the Neon library is used.

…

On Fri, 9 May 2025 at 14:11, Pete Stewart ***@***.***> wrote: I've been doing a little more digging, and it would seem this is more a Cloudflare Workers error, rather than coming from payload. I think the issue is due to the way ***@***.***/client' & 'drizzle-orm/libsql' are imported. https://github.com/payloadcms/payload/blob/3701de5056d7b19c860bced6cc14c963cce7a5ae/packages/db-sqlite/src/connect.ts#L4-L6 Here is a similar issue where the solution was to import the web versions. tursodatabase/libsql-client-ts#303 <tursodatabase/libsql-client-ts#303> import { createClient } from ***@***.***/client/web';import { drizzle } from 'drizzle-orm/libsql/web'; instead of: import { createClient } from ***@***.***/client';import { drizzle } from 'drizzle-orm/libsql'; I assume this would need to be a new sqlite package, though, as this is different to how most servers would want to run it. — Reply to this email directly, view it on GitHub <#6110 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AENIFDW6AXZ5DUD4VNQJOWL25SLOXAVCNFSM6AAAAABG6S4PNSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMBYHEZTGNA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[PeteJStewart]

I agree, in that I think I've also used it like that on Hono in the past, but I can't find any documentation about that now.
However, on the Cloudflare docs for connecting to Turso from a Cloudflare Worker:
https://developers.cloudflare.com/workers/tutorials/connect-to-turso-using-workers/#write-your-worker

They also use "@libsql/client/web", so I'm pretty sure that is the issue here.
It kind of make sense that it would use the web client due to how Cloudflare workers works.

I think it's just a case of create a new db-cloudflare-sqlite package and switching these out, and then we would have a working Cloudflare deployment.

I think it would then also be nice to make a D1 package, but that's a slightly different task.
Happy to help put this together.

[LubomirGeorgiev]

When is the OpenNextJs/Cloudflare support expected to arrive?

[BohdanK-W32]

Are there any news on that topic?

I'm pretty sure, I'm not the only one being tired of "VPS vs 20$/user Vercel serverless" choice (VPS obviously), when Cloudflare Pages & Workers exist.

Alternative to sharp (file processing adapters API to support Cloudflare Images or any other external service for file processing purposes) and Cloudflare support is a must.

TBH Payload's reliance on open-source (semi-proprietary) Next.js (Vercel) is the worst part of the Payload CMS. It brings all the worst parts of Next.js to such a nice product, but anyway not the Next.js is a blocker rn

[galcsikgyozo]

They said they got it working recently, and that they will release a template in beta soon:
https://x.com/paulpopus/status/1925971496863776986

[BohdanK-W32]

@galcsikgyozo, thanks!
Didn't see this one, hope it will be working as expected, PayloadCMS on Cloudflare with D1 & R2 would be a game changer. Hope file adapters API would be delivered this year and all the blockers would be resolved!