Come think of it, the comment you mentioned could be all that needs to be added to the documentation
Come think of it, the comment you mentioned could be all that needs to be added to the documentation honestly
Zhey y'all... I've recently moved to using cloudflare pages with nextjs 14 instead of vercel. I have a functions folder which isn't being picked up automatically for deployment - is this because each of those folders have their own wrangler.toml?
Zthis isn't a complaint BTW, I prefer this feature. just wandering if that's something I can depend on in future...?
J
TYou shouldn't use
functionsCreate custom request handlers for a given route using the Web's Request and Response APIs.
Hnext-on-pages(or any SSR framework) will generate functions for you, which overrides anything you put in the folder yourself. You need to use Next's API Routes instead of the functions folder
Next.js supports API Routes, which allow you to build your API without leaving your Next.js app. Learn how it works here.
HOh, you meant static Next? Then the functions folder should work fine
MHi i'm struggling to understand how i can fix this error, does anyone know how i can resolve it? sorry im new 
JThat is an error from the Next.js build, so I would recommend making an issue on Next.js repo.
JNext.JS 15 requires nodejs version 18.18.0, but Cloudflare's is 18.17.1
When I change NODE_VERSION env variable, it just does not change it. Anyone knows how to fix this?
When I change NODE_VERSION env variable, it just does not change it. Anyone knows how to fix this?
HWait, so do you mean you want to host your project on a different service?
HThe Edge Runtime is a Worker, if that is what you mean
HNo part of the Cloudflare platform can run full Node in a user-facing way if that is what you mean
ZNot quite my question. I have real workers indirectly associated with the nextjs api handlers written previously. These functions are not being automatically picked up when the build process runs. I'm hoping that this behaviour continues. I don't want to re-write them as NextJS API routes... yet.
TYou should try OpenNext CloudFlare adapter. It allows you to use node runtime but it still has limitations and it's actively being developed
IBit confused what you mean. When deploying a Next.js site with Pages, it won't deploy a Worker alongside it... you can either use Next.js API routes or a worker that's deployed seperately (not in CI). Pages won't deploy the Workers for you.
IIf you mean a function as in Pages Functions then Lewis is correct, the /functions folder is completely ignored when using next-on-pages and you'll have to either move to a Next.js API route or use a seperately deployed Worker.
ZOK great - that clears up my confusion but not yours 
This is by far the best outcome - what wasn't clear is if /functions is ignored or not with next-on-pages. If it is, that's ideal for me though I would love it if I could bundle up CI deployments with specific workers in the /functions folder in the future. More of an 'opt-in'. The reason for this was previously I was using Vercel and hated their edge functions, preferring the Cloudflare workers for mostly everything that wasn't specific to the exact domain I was building in. Now that I'm on Cloudflare for everything I can make this delineation a bit more strict based on application affinity than infrastructure affinity.
This is by far the best outcome - what wasn't clear is if /functions is ignored or not with next-on-pages. If it is, that's ideal for me though I would love it if I could bundle up CI deployments with specific workers in the /functions folder in the future. More of an 'opt-in'. The reason for this was previously I was using Vercel and hated their edge functions, preferring the Cloudflare workers for mostly everything that wasn't specific to the exact domain I was building in. Now that I'm on Cloudflare for everything I can make this delineation a bit more strict based on application affinity than infrastructure affinity.
RDid you get help yet?
TMoving question as I have deployed next on workers...
JIs there a way to use
npm install --force when deploying next to cloudflare pages?JOn vercel, I'm able to override just the install command:
JThat option is not present on cloudflare
KKI'm getting this error. Any solution?
Wconsistently getting it?
K
Wlet me escalate it up
DHey everyone does anyone know where can I read about multi tenant project with cloud flare and nextjs
Danyone tried nextjs 15 on pages?
FNot yet supported, only 13 and 14 are so far -> https://developers.cloudflare.com/pages/framework-guides/nextjs/ssr/supported-features/
Dyeah I saw is not supported, but didnt expect it either to be officially listed considering it's so new
FWell, then try out and find out?
Dye I will probably do, just trying 14 for now. Then will see
FThere are some neat things is 15, but I think I'll wait until React 19 is out
DI was using canary already for some other project I have on remix and was thinking giving it a shot
Dis normal that my deploy appear on the pages.dev subdomain but not on the linked domain yet (linked domain appear as active already on the pages dashboard of cloudflare)
FNot tried pages yet, but for simple static asset only worker I know this works to deploy a static website ->
Dyeah specially canary, "use cache" looks dope
DSomething is off with my deploy It only works when I have the log streaming enabled o.O
D
HMight be hard for me to phrase it for you (it means that note would include a statement about where those products are heading in terms of support - which is usually something that triggers internal discussions around the phrasings 
). But feeling helpful I tried. Realized it's hard not to turn it into a deprecation notice though, but it's still nice to be open with this info to all the users from the beginning, so putting a PR for the last suggestion: https://github.com/cloudflare/cloudflare-docs/pull/17788
"We will continue support this solution, but our long-term support and new development will focus on deploying Next.js apps to..." messes up the meaning of the original phrasing though, but it'll change anyway before the PR get's merged, it always does
). But feeling helpful I tried. Realized it's hard not to turn it into a deprecation notice though, but it's still nice to be open with this info to all the users from the beginning, so putting a PR for the last suggestion: https://github.com/cloudflare/cloudflare-docs/pull/17788"We will continue support this solution, but our long-term support and new development will focus on deploying Next.js apps to..." messes up the meaning of the original phrasing though, but it'll change anyway before the PR get's merged, it always does
GitHub
Summary
People starting out new projects should easily see where the support for different products are heading. To avoid some friction. Got this info from the next-on-pages discord and it was sugg...
People starting out new projects should easily see where the support for different products are heading. To avoid some friction. Got this info from the next-on-pages discord and it was sugg...
Hhttps://github.com/cloudflare/cloudflare-docs/pull/17788 You can help phrase it better (or completely different) by commenting on the PR I did now.
D@fry69 lol I forgot I used next15 xD
Dguess that's the issue