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/

[leonceaklin]

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…

[nvti]

can you share your work?

[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: admin@example.com
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