You'd want to add a heartbeat request every <60s in order to keep the browser alive to avoid startin
You'd want to add a heartbeat request every <60s in order to keep the browser alive to avoid starting new ones. Crazy.
MYep. The problem isn't keeping it alive for a minute but if it's okay to keep it alive for forever. And if so why is that the best practice, seems hacky.
It doesn't make sense that CF needs to charge $0.10 to spin up/spin down a browser rendering instance for 60 seconds but will let you keep it up all month for $0.10 as long as you interact with it once every 60 seconds. The economics just don't make sense.
It doesn't make sense that CF needs to charge $0.10 to spin up/spin down a browser rendering instance for 60 seconds but will let you keep it up all month for $0.10 as long as you interact with it once every 60 seconds. The economics just don't make sense.
JAgreed. Unless it's basically free for them to have it sit idle... but if that's the case, why automatically turn them off after 1 minute?
MYeah or just make the session pricing low enough so that it makes sense to spin up/spin down as needed rather than relying on hacks to avoid a $4k bill.
JDo CF devs monitor this channel? Or is it only community members speculating? 
AIt's a very puzzling situation. I'm basically waiting until it's sorted out before I implement anything with the Browser Rendering API
HHey there when using the Browser Rendering API, I ran into a cloudflare challenge on a website I wanted to access lol. Is there anyway to wait/bypass that? Or is this a goner? Thanks!
HHey Dan did stealth work out for you?
DI haven't tried it, I don't think anyone answered my question on pricing so I didn't try it
DI think that's the point, they don't want bots
HThat's a bummer... will probably have to work a way around then. Thanks for answering bro!
VIs this supposed to work on Pages function?
PHey @jasonlfunk, currently, on the free plan, each account can initiate up to 100 browser sessions per month.
For the Paid plan (included in Workers), each account can initiate up to 500 sessions/month with the capability to run 10 concurrent sessions. Additional sessions on this plan are billed at $0.10 each, and additional concurrent sessions costs $1.00 each.
Each account can start up to two new browser sessions every minute. Note that if a browser instance remains idle, with no commands issued for 60 seconds, it will be terminated, thus making room for a new available instance.
Durable Object enables the creation of a "continuous browser session". This approach allows for the reuse of a browser instance without incurring costs for starting a new session, though charges for the Durable Object apply
For the Paid plan (included in Workers), each account can initiate up to 500 sessions/month with the capability to run 10 concurrent sessions. Additional sessions on this plan are billed at $0.10 each, and additional concurrent sessions costs $1.00 each.
Each account can start up to two new browser sessions every minute. Note that if a browser instance remains idle, with no commands issued for 60 seconds, it will be terminated, thus making room for a new available instance.
Durable Object enables the creation of a "continuous browser session". This approach allows for the reuse of a browser instance without incurring costs for starting a new session, though charges for the Durable Object apply
UBased on this message I assume you work at CF. As an fyi you can run the
/cfrole command to get the cloudflare employee role JI understand. I think the outstanding questions are this:
1) Is it a problem to keep a browser session open indefinitely? (by using alarms/cron to keep it active).
2) How many pages can a single browser session reasonably have open at a time? (If my app is processing 100 requests per second, can they all be sent to a single session? Should they be split up over multiple sessions?)
1) Is it a problem to keep a browser session open indefinitely? (by using alarms/cron to keep it active).
2) How many pages can a single browser session reasonably have open at a time? (If my app is processing 100 requests per second, can they all be sent to a single session? Should they be split up over multiple sessions?)
PWe are currently in beta and things might change, but 1) As shown on the previously mentioned blog post, it's acceptable to keep the session active. 2) I'll need to verify and follow up regarding your second question, but it seems the limitations will likely be tied to memory capacity, which can vary with each use-case
JGreat, thanks for the information.
VDoes this means, it cost me $3,880 per month for single URL screenshot every minute?
For example, if I have a worker capturing a website screenshot on every minute scheduled CRON.
(43,800 minutes/session * $0.10 per session) - 500 free session = $3,880
It's going to be super expensive
that way. What are other suggestion?
For example, if I have a worker capturing a website screenshot on every minute scheduled CRON.
(43,800 minutes/session * $0.10 per session) - 500 free session = $3,880
- Assuming a new session will be created each time the scheduled function starts.
It's going to be super expensive
that way. What are other suggestion?PHey @Vikash [Agenty], consider using Durable Object as a way to reuse the open sessions. Please take a look at this blog post, as the example seems quite similar to your use-case: https://blog.cloudflare.com/running-serverless-puppeteer-workers-durable-objects/
The Cloudflare Blog
We’ve heard from developers that configuring and maintaining their own serverless browser automation systems can be quite painful. The Workers Browser Rendering API solves this
VIf I use durable object and keep setting the alarm. Does that mean my session will never expire? Because I am using CRON so it will keep warming up every minute
VAlso, any way to track cost/sessions in beta?
PMostly, note that the Durable Object might be terminated in some instances, such as if it is idle for 30 seconds, if it hits memory limits or when we put out new releases
PNot something we offer at the moment, but we are exploring this possibility
DHello, I would like to request access to the browser rendering API. Thanks!
ZPut your account ID in browser-rendering-apiBrowser Rendering API Beta Access
DThanks!
JWow, I joined this Discord to learn more about the Browser Rendering API. And I'm shocked about the pricing! 
For 5 USD i can execute a simple docker container, that might does not scale, but that wouldn't introduce a private bankruptcy...
For 5 USD i can execute a simple docker container, that might does not scale, but that wouldn't introduce a private bankruptcy...
UBy following this guide, you will create a Worker that uses the Browser Rendering API along with Durable Objects to take screenshots from web pages …
Uis the example code above correct? The browser instance is unconditionally closed in fetch(), which makes the durable object useless for the next call
U@Pedro
Uactually this example seems to have lots of mistakes 
Jhave you figured out how it should be implemented instead?
Uat a minimum:
- remove the
linebrowser.close() - check that the browser is connected every fetch (
), and reinstantiate it if notthis.browser.isConnected() - do not call newPage() every fetch, instead check the browser instance and see if it has the number of pages you need already, from last time
- add an await to the setAlarm call
state.blockConcurrencyWhile()Hey @uk, this blog post might be a better example of what you're trying to achieve: https://blog.cloudflare.com/running-serverless-puppeteer-workers-durable-objects/
The Cloudflare Blog
We’ve heard from developers that configuring and maintaining their own serverless browser automation systems can be quite painful. The Workers Browser Rendering API solves this
Uat first glance this is the same code as the linked doc
JOk, I'm completely confused. From what I see here, and from the lack of responses from Cloudflare, the browser rendering API looks like a dangerous endeavor. It won't scale on high load due to the limitations and it's potentially super expensive
PHey @haushoppe, I believe this was previously addressed, mentioning the use of Durable Object as a way to reuse a browser instance without incurring costs for starting a new session
JBut @uk has pointed out that the examples are broken, and the discussion was about keeping the instances running via a cronjob - otherwise it gets expensive
P@haushoppe, we'll review the provided example and update it if necessary. However, the key takeaway is that it's possible to reuse the browser instance without additional costs associated with initiating a new session
JYes, but I have to keep it active within 60 seconds or so. If I somehow fail to update it correctly, then new instances will spawn up and make me poor... 
BHi all, I also have a question about the pricing.
Quoted from the blog post:
If you create a new browser session every 60 seconds, that means 24 hours * 60 minutes = 1440 sessions per day if you have continuous traffic (at least a request per minute...). If you multiply this by 30 days, that would be 43.200 sessions * 0.10$ = $4320
That seems extremely expensive to me, especially if you only have a couple of requests per minute? I argue that running on own infrastructure would be way cheaper, or am I misunderstanding something here?
Quoted from the blog post:
We’ve spoken to many customers deploying a Puppeteer service on their own infrastructure, on public cloud containers or functions or using managed services. The common theme that we’ve heard is that these services are costly – costly to maintain and expensive to run.
If you create a new browser session every 60 seconds, that means 24 hours * 60 minutes = 1440 sessions per day if you have continuous traffic (at least a request per minute...). If you multiply this by 30 days, that would be 43.200 sessions * 0.10$ = $4320
That seems extremely expensive to me, especially if you only have a couple of requests per minute? I argue that running on own infrastructure would be way cheaper, or am I misunderstanding something here?
BAnd this already assumes you are using a durable object to limit the concurrent sessions to #1
BI love the convience so far, but am a little worried about the pricing, how definite are those numbers?
JYeah, the pricing here really doesn’t seem to be competitive, even when compared to more premium solutions such as https://www.browserless.io.
It would be really nice to hear some clarifications and thoughts around the pricing as it exists today, for how it was determined.
It would be really nice to hear some clarifications and thoughts around the pricing as it exists today, for how it was determined.
Try Browserless, one of the best web automation tools for free. Implement web scraping, PDF generation & headless browser automation easily.
USeems browserless allows a lot more concurrency but the charge per session can be more than cloudflare if you keep the session alive with durable objects
You could in theory do 15,000 sessions ($25 on browserless) with a single session on cloudflare ($0.10).
You could in theory do 15,000 sessions ($25 on browserless) with a single session on cloudflare ($0.10).
UAnd the more requests you do keeping a session alive the cheaper it becomes compared to browserless
UMain difference there is you sort of have to manage the load of the durable objects yourself a bit
JIn my opinion, any product that requires a user to scaffold something like a DO to manage things themselves to ensure their pricing doesn’t explode is a really bad design for serverless and the rest of Cloudflare’s product stack.
ZThis is my largest issue with the current pricing. For it to be at all competitive, you need to manage it state fully, which is so opposed to the rest of the product stack
BHow so? I thought a session can live a maximum of 60 seconds as a limit?
BAh wait, you have to keep it warm