API calls, and in fact for Workers for Platforms (different from regular Workers) that's the only wa
API calls, and in fact for Workers for Platforms (different from regular Workers) that's the only way to bind things to user workers.
IFor regular Workers you can also do it via API.
IKeep in mind in both cases it will result in a redeploy of your Worker so it might take a few seconds to propagate globally/your worker will be reset.
Ryah its for WfP so i could deploy then bind , i cant deploy with things binded already
Rty
TBig WFP announcement today 
https://blog.cloudflare.com/browser-rendering-api-ga-rolling-out-cloudflare-snippets-swr-and-bringing-workers-for-platforms-to-our-paygo-plans
TLDR: WFP is coming down to our paid plan on April 16th!
https://blog.cloudflare.com/browser-rendering-api-ga-rolling-out-cloudflare-snippets-swr-and-bringing-workers-for-platforms-to-our-paygo-plansTLDR: WFP is coming down to our paid plan on April 16th!
The Cloudflare Blog
Browser Rendering API is now available to all paid Workers customers with improved session management
SHi friends, new to workers for platforms! What is the story on letting users manage secrets for their workers they upload? Like if my user wants to access their own database from their worker what is best practice for managing that? Thank you for the help!
BVery happy to see Workers for Platforms will be available to everyone!
I want to build a multi-tenant service with Workers for Platforms, but I don't know what I should do with the database.
I have two options: One D1 database for all customers and One D1 database for each customer.
For the first option, I think there will be challenges for data security and I think the size will grow over 10GB quickly (since what I want to do is heavy on data).
For the second option, there are two problems. First, each account can only have 5000 D1 databases, and I think I will go over this limit since I will offer a free tier service. I also found it's not easy to dynamically create D1 database and attach it to my worker script. Second, If one day I need to do a database migration, I will have to do the migration for all databases, and it'll definitely not be easy.
Do you have any suggestions for what I should do?
I want to build a multi-tenant service with Workers for Platforms, but I don't know what I should do with the database.
I have two options: One D1 database for all customers and One D1 database for each customer.
For the first option, I think there will be challenges for data security and I think the size will grow over 10GB quickly (since what I want to do is heavy on data).
For the second option, there are two problems. First, each account can only have 5000 D1 databases, and I think I will go over this limit since I will offer a free tier service. I also found it's not easy to dynamically create D1 database and attach it to my worker script. Second, If one day I need to do a database migration, I will have to do the migration for all databases, and it'll definitely not be easy.
Do you have any suggestions for what I should do?
UCurrently durable objects are the best tenant based db you can use. D1 is still working on exposing easier tenant based structure.
Uand fwiw the database limit on d1 can easily be raised (its also 50k not 5k)
RHow do you assign worker routes to a customer's domain, if they add their domain (we set it via Cloudflare for SaaS ) Can we then add Worker Routes to the custom domain they added
UIf you want all customer domains to go to the same worker its pretty easy just gotta add these 3 worker routes (https://dash.cloudflare.com/?to=/:account/:zone/workers):
Example:
<zone-name>/*None*.<zone-name>/*None*/*<worker to route to>Example:
UIf you only want to specify a specific customers domain then you would just enter their domain in the workers routes.
Note that you can only have like 3,000 worker routes defined iirc
mycustomer.com/*my-worker-for-customerNote that you can only have like 3,000 worker routes defined iirc
KThe same as Wrangler, you bundle it (i.e with esbuild) before uploading it
KHello, about the pricing for individual scripts, my assumption is the pricing covers storage of the worker code. is this correct?
Kif that is the case, has the idea of more fine grained pricing for the storage that the workers take been brought up? I'm imagining a pricing model of
x per 1GB instead of x per script.
x per 1GB instead of x per script.
UA static cost per script is easier to calculate which is why it’s that way
Kyeah makes sense, thanks
KIf i create a user script and delete it after a week does that incur the whole 0.02 charge?
WWe would need to add a way of saying it's a Workers for Platforms script. Probably most likely is having secret put under wrangler dispatch-namespace so you'd do
wrangler dispatch-namespace secret put <secret-name>cc: @tanushree │ Workers PM
Ryeah i was curious on the same, if we can store secrets for a customers worker
WYeah in the UI we don't let you modify script bindings iirc
WYou can use the API but yeah we should add to wrangler for sure
BYou need to do it by API, but as Walshy said we should add an namespace option to wrangler similar to the deploy script
Here's an example of the API method
Here's an example of the API method
RWhat are the list of type For that
Dhere's some of them that are documented: https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/reference/metadata/
I usually check wrangler's source code for the others
I usually check wrangler's source code for the others
RTy
Ris it stll not advised to do 1 namespace per "customer" ?
UA namespace can have unlimited scripts you should be giving them tags if you want to list by a customer or saving in your own db
Ryah ive seen mixed , some recommended 1 per customer other ssaying do all on same one and use tags.. if i wanted a user to have their own "kvs" those would all just be on the same namespace also right?
PKV is different to workers for platforms, and you can only have 100 KVs in your account unless you request a limit increase.
Unless you have less than 100 users or can get an increase approved, you are best to either use one KV and prepend a customer ID to each key, or you could also utilize Durable Object's Transactional Storage API, which works on WfP and is similar to a KV (just not as good performance wise).
Unless you have less than 100 users or can get an increase approved, you are best to either use one KV and prepend a customer ID to each key, or you could also utilize Durable Object's Transactional Storage API, which works on WfP and is similar to a KV (just not as good performance wise).
ROk that's good too so one for all customers
TExited to get this out! We're just waiting for a release in the afternoon (US time), after then it will be available
D
THaha the anticipation builds. It's coming!! We're waiting on another team's release (I'm told its in progress)
TYou'll see a new tab in the dash under "Workers & Pages"
TI can spare you - I'll shout on discord once it's up!
Bkeeps refreshing the dashboard
TSorry to dissapoint y'all. Our team has a snag with the release and they're still working on it. I'll be sure to follow up here once we're in the clear
