Si was wondering what the "best" approach is to get www working when using a custom domain in my worker?
Would it be this https://developers.cloudflare.com/pages/how-to/www-redirect/ ?
Would it be this https://developers.cloudflare.com/pages/how-to/www-redirect/ ?
Cloudflare Docs
Learn how to redirect a www subdomain to your apex domain (example.com).
Wyes follow that doc
BHey guys, How do I add a CPU time limit to the toml configuration file for Worker Paid Plan? What are the specific fields?
BThanks
0Hi, I was wondering how a worker codebase (TS) should be structured, more specifically how one would have multiple workers, can I just have different exports? I somehow can't find anything about this in the docs -- is the idea to give each worker its own codebase?
AHi, How many websocket connections can I have per day? and messages (without durable objects)? please
ACould someone please tell me the prices/limits for API cache and websockets (without durable objects), please, I can't find anything anywhere
RI recently tried the fun misadventure of taking my Pages site and putting it into a new account, which I didn't realize I had started the project as a Workers Assets project in the new account.. and lost a day trying to make that work. I eventually decided to start a new project in the new account and manually port everything over into the new working Astro project in the new account. I understand that this is definitely not the place to ask for an account->account site migration tool, that would be awesome, but this is not that place... so...
Because clearly Astro projects that were started on Pages will not run on Workers Assets just out of the box, and finding the new config differences is... opaque.
Is there a guide anywhere regarding moving a project from Pages to Workers Assets?
Thank you in advance for your help and insights!
Because clearly Astro projects that were started on Pages will not run on Workers Assets just out of the box, and finding the new config differences is... opaque.
Is there a guide anywhere regarding moving a project from Pages to Workers Assets?
Thank you in advance for your help and insights!
RGiven that the #pages-discussions channel is now archived, I presume that to be a tacit "Yes. Pages are now deprecated" answer. Thank you, that is a very relevant reference in this light.
RI genuinely wish I had been able to predict this deprecation of Pages into Workers Assets so many months ago when we designed our architecture... I did not realize how dependent we were on Pages specifically, and how disruptive it could be to lose the thing. I guess I knew that Pages have been running on Workers all along, so I didn't anticipate this could be so problematic, and I didn't think Cloudflare wouldn't have a migration guide at all in the event they decided to just end Pages, which they seem to be doing. I guess there was a reason it took Python 10+ years to deprecate Python 2.
We have an unconventional use case due to subdomains and DNS rules in coordination with Workers and Pages both and it's difficult to port without big effort, which we are having to undergo because we need to migrate to a separate account from the original developer's personal account. This is not a common use case in Cloudflare we are finding, or else there would be faculties for it. This seems like a strange oversight, to move a zone or site to a new account seems like it would be more common, but I can see how it's necessarily complex.
We are reconsidering Cloudflare dependency now. We are almost definitely not leaving Cloudflare, but it would be idiotic not to make a go-kit so to speak, and our CTO does have us pricing alternatives and designing migration and mitigation strategies. Uncertainty is bad. I can't place that blame on Cloudflare entirely maybe even at all, I simply don't know right now, but it's funny in the linked discussion there was a reference to bun 1.2 in the end there. And the argument against maintaining up to date bun support in Pages was that bun breaks backwards compatibility too frequently. I find that ironic in this case. I don't use bun for this reason, too.
Please forgive me if this is not relevant here, but it seemed directly relevant to discussion about Workers and Pages. I'm open to instruction and direction. Thank you.
We have an unconventional use case due to subdomains and DNS rules in coordination with Workers and Pages both and it's difficult to port without big effort, which we are having to undergo because we need to migrate to a separate account from the original developer's personal account. This is not a common use case in Cloudflare we are finding, or else there would be faculties for it. This seems like a strange oversight, to move a zone or site to a new account seems like it would be more common, but I can see how it's necessarily complex.
We are reconsidering Cloudflare dependency now. We are almost definitely not leaving Cloudflare, but it would be idiotic not to make a go-kit so to speak, and our CTO does have us pricing alternatives and designing migration and mitigation strategies. Uncertainty is bad. I can't place that blame on Cloudflare entirely maybe even at all, I simply don't know right now, but it's funny in the linked discussion there was a reference to bun 1.2 in the end there. And the argument against maintaining up to date bun support in Pages was that bun breaks backwards compatibility too frequently. I find that ironic in this case. I don't use bun for this reason, too.
Please forgive me if this is not relevant here, but it seemed directly relevant to discussion about Workers and Pages. I'm open to instruction and direction. Thank you.
Xhttps://developers.cloudflare.com/workers/runtime-apis/cache/#headers
Does cache.put support CDN-Cache-Control header (even when Cache-Control is present), or do I have to rewrite CDN-Cache-Control into Cache-Control on the response before putting it into cache (in a snippet)? docs aren't clear on this
Does cache.put support CDN-Cache-Control header (even when Cache-Control is present), or do I have to rewrite CDN-Cache-Control into Cache-Control on the response before putting it into cache (in a snippet)? docs aren't clear on this
Cloudflare Docs
Control reading and writing from the Cloudflare global network cache.
WYes it should
WTo be clear, Pages isn't going anywhere anytime soon and we will be making the migration between Pages -> Assets easier. A migration guide is in the works and we have no plans to make it a pain, we want to make it as easy as possible.
You can still make Pages projects on accounts today like you could before, you do not need to use Assets, we still see people onboard daily to Pages
You can still make Pages projects on accounts today like you could before, you do not need to use Assets, we still see people onboard daily to Pages
Wi wouldn't read into this, we did this for a 2 main reasons:
- We are always looking to reduce our channel count - it's the #1 feedback item we get -- "There's too many channels, it's overwhelming"
- We are aligning with how we as a platform are structing things, you will see we still have #pages-help and this is also Pages, we just dropped the whole dedicated section to align with the dashboard on a "Compute" section.
Wwe don't need a workers-discussions and pages-discussions under this section so we just aligned into one.
Xthanks, another quick q: it seems like workers have a rate limiting api available, but it needs to eb bound in wrangler config, so theres no way to get it in snippets?
WNo, Snippets don't have access to bindings at all today
WYou would need to use Rate Limit rules
Xthats what i do
ASince yesterday we always get the error npm too many Open files when deploying using workers auto Build. What‘s curious, we deploy the same codebase to three different Environments but it happens only with one?
AAren‘t able to deploy changes at the Moment.
RThank you. I appreciate your insight and kind explanations. This makes sense.
JFwiw I would still encourage folks to use Assets wherever possible over Pages. Cloudflare will almost certainly never officially deprecate Pages - but you can already see it’s slowly being abandoned, with many bindings still not supported, and the build image tooling versions aging rapidly.
JPages isn’t going anywhere - but if you’re starting something new, use Assets if you want to play with anything new Cloudflare is releasing. I’d be very surprised if any new bindings get added to Pages at this point.
RThis effectively confirms that we have to re-tool.
RI eagerly anticipate the migration guide. Our project is DOA without it. We have to find a platform asap.
JIf what you have today works, you don’t need to. But if you’re looking to use anything new that Cloudflare releases in future, then Pages is not a good choice today sadly.
RWe put months of work into Pages. It's not future proof anymore, you just confirmed. We cannot launch on it.
ROur project is DOA today. We must find a new and more stable platform. It will be Workers if we can figure it out. But if we have to rebuild, well, that is a cost and we will look for stability.
JSorry, that’s the reality of Pages today. It’s stable and highly functional with the features it has. But it has already been lagging behind Workers and I don’t anticipate that changing.
RNo, that's fine, it's true. I lamented using Pages to start. I didn't want to, but it was the direction we were pushed in, by Cloudflare's documentation.
JFwiw moving to Assets should be relatively straightforward. Functions aren’t a thing (which imo is a good move, they were always a weird Pages only thing), but static assets, _headers, _redirects etc. all exist now.
RIt's weird. There's some build configuration issue. You can replicate it easily. Create a new project on Pages using Astro. set it up so that it builds on push to Github. Then, use that repository as a Workers Assets project. There is no way you can configure it, that I have found in code or admin, that will build.
RSurely there is a way, I just haven't found it
JI don’t believe the Astro Cloudflare Pages adapter will work on Assets, but there’s an Astro adapter for Assets I believe
ROof. But! You can create a new Workers Assets project in the CF Admin, and push that to github, and then it will automagically build an Astro site every time you push to Github, just like with a Pages project.
JRYes, that is the guide I am referencing
RThat is how you get a fresh working Workers Assets Astro build, yes. That is good. How do you make a Pages Astro site do that?
RSo this is insightful, thank you. I'm a little at a loss as I seek to understand which adapter that is for Assets versus the common adapter for Pages. I think this could be key to making this work, however, and I'd be happy to contribute back to the guide if we can make this work somehow.
XIs the workers/snippets cache shared with the main cf http caches, or are they keyed differently internally?
SHow are folks here leveraging preview + production builds as 'staging' envs? Is that realistic? bonus: different env vars for preview vs production workers deployments?
Sim surprised by your experience. i moved a sveltekit project from pages to assets with less than 10 lines of code
Sbut yea the adapter naming is a bit weird now. for worker assets on sveltekit you still use the pages adapter. not the worker one
RYeah that's pretty much what I'm doing. Env vars for environments
RWild. I bet it's similar for Astro. I just can't find the worker adapter that's special. I might be special, too 
Swell in my case i created a brand new project using worker assets and just compared it to my pages project
RRight, yeah, that's pretty much been my workflow, too.
RIt's currently how I'm troubleshooting anyhow