113 points | by marclave1 week ago
Related story: Way back in the day, PayPal was just getting started, and decided eBay transactions would be their perfect customer. The only problem is that eBay didn't allow scraping. So they built an entire proxy infrastructure to go around eBay's rules and scrape them.
It worked. It worked so well, eBay bought PayPal.
The side effect of this is that I got control of the PayPal proxy infrastructure since I was on the security team for both eBay and PayPal after the acquisition.
We used that proxy farm to scrape the rest of the web looking for fake eBay sites (because they would block traffic from eBay's IPs) and we had the guys who built it help us build proxy defense for eBay and PayPal.
So this could work in your favor, if you manage to constantly scrape a large target who might want to buy you. :)
Tying into your concern, keeping IPs fresh and high quality will definitely be a balancing act as we get bigger. It'd be one today too if we were to try to offer super granular location controls because there's only so many proxies in X state, let alone X city. Currently, we get to aggregate & QA from multiple proxy providers, so our total pool is 300M+ IPs in the US and so far we've had a 99.95% rate of getting a fresh IP address in a session. So so far so good :)
As for that last point, I guess we'll see what the future has in store for us :P
With our proxy service this is built for at least the length of a session (up to 24 hours).
over the last year or so, we’ve built quite a few AI apps that interact with the web and noticed - a. it was magical when you could get an llm to use the web and it worked and b. our browser infra was the source of 80% of our development time. Maintaining our browser infrastructure became its own engineering challenge - keeping browser pools healthy, managing session states and cookies, rotating proxies, handling CAPTCHA solving, and ensuring clean process termination. We got really good at running browser infrastructure at scale, but maintaining it was still stealing time away from building our actual products. So we wanted to build the product we wish we had.
Steel allows you to run any automation logic on our hosted instances of chromium. When you start a dedicated browser session you get stealth, proxies, and captcha solving out of the box. We do this by exposing websocket and http endpoints so you can connect to these instances with puppeteer, playwright, selenium(in beta), or raw CDP commands if you’re built like that.
Behind the scenes, we host several browser instances and route incoming connection requests to one of these instances. Our core design principle was to allow for every session to have its own dedicated browser instance + resources (currently 2gb vram and 2gb vcpu) while still allowing for quick session creation/connection times. Our first thought was to have separate nodes running in a Kubernetes cluster, but the cost of hosting warm browser instances would be expensive (which would be reflected in the pricing), and the boot times would be too slow to handle the scale that some customers required. We got around this by deploying our browser instance image on a firecracker VM, taking advantage of the lightning-fast boot times and ability to share a root FS.
Today, we’re open-sourcing the code for the steel browser instance, with plans to open-source the orchestration layer soon. With the open-source repo, you get backwards compatibility with our node/python SDKs, a lighter version of our session viewer, and most of the features that come with Steel Cloud. You can run this locally to test Steel out at an individual session level or one-click deploy to render/railway to run remotely.
We're really happy we get to show this to you all, thank you for reading about it! Please let us know your thoughts and questions in the comments.
After playing a popular indi game (Kenshi) I was wondering about the very simple automation interface the game relies upon. Why not a virtual world (with interfaces attaching any external source) in which business logic agents interact through the available interfaces of the environment, and other agents. Though tbh, I imagine the entire environment as implemented in layers of YAML style schemas and profiles. So all data, whether in a datastore, active instance, streamed or serialized can be related to in the same way. An envelope with attributes and content specified by the type attribute. The only code would then be the rendering environment, and whatever these agents call for stream processing.
Sort of a gamification of automation, though what can’t be beat is dead simple account of what any one thing is doing at a given time.
The concept of agents running wild with only schemas of how to interact with their environment + one another is something I’ve thought about a lot. With current models, I guess this would just be function calling or forced JSON outputs, but I think it would make for some very interesting results.
With Steel, we’re really just providing a way to do something similar to the “rendering engine” in this scenario but with the web. So agents can interface with their environments (websites) very easily and at scale (which comes with its own difficulties wrt deloying/managing)
Is the interface between Steel, or Puppeteer/Playwright/Selenium, something that might be implemented in the new Anthropic Model Context Protocol, so there's less custom code required?
We also have more AI-specific examples, tutorials, and an MCP server coming out really soon (like really soon).
You can keep an eye out on our releases on discord/twitter where we'll be posting a bunch of these example repos.
(I am one of the authors!)
We don't compete with Puppeteer/Playwright/Selenium but we're focused on solving the problem of hosting Chromium browsers in the cloud.
The workflow jump we've seen ourselves and from customers is that it's pretty straightforward to build these scripts locally, but the moment you want to run them in prod, you now need to deal with a ton of overhead around packaging up to docker, resource management, scaling, etc. We want to make that trivial :)
Let’s say we want to add web automation to our app, and we've set up a single instance of Chrome hosted on a server somewhere that we connect to and drive with Puppeteer. Great, now we need to ensure incoming requests/sessions are managed properly (>1 active session). If we have a ton of active requests, this becomes annoying because now the resources on our server are being eaten up — so we would need to scale horizontally (or vertically) but now that comes with potential downtime and cold start issues. If we decide to keep this instance of Chrome running 24/7 then we need to bake in resource management to handle memory leaks and connection issues. If we don’t keep them alive, then this comes with significant cold start times (10s+).
Now, let’s say we want to support a real-time scraping use case that requires multiple browsers in parallel. At this point, we would need to use something like Kubernetes with warm pods or maybe lambdas/cloud run. But even those have their own set of challenges/costs. Managing Kubernetes can get complicated and expensive quickly, especially if you’re not already using it for your app. On the other hand, serverless options like Lambda or Cloud Run introduce latency issues (cold starts) and often don’t provide the flexibility you need for long-running sessions or custom configurations.
Then, beyond the infra, we'll probably need to build capabilities to not get stopped out by anti-bot measures like proxy mgmt, fingerprint rotation, captcha solving, etc.
Pretty quickly, as you grow, a small-scale project can turn into a pretty big maintenance project. Building parsers/agents/scripts is hard enough, so we're hoping to make the infra side as easy as possible.
It does just so happen that it ends up being useful for non AI apps as well
If it's a login page that gets redirected to when you try to access a page on your browser, then theoretically you should be able to do that with the open source repo and custom AI logic.
Having to constantly fill out those login pages (especially for networks that expire) is such a pain so would love to use this myself lol
So an AI that can fill in the WiFi login page should be able to do it without opening a browser.
Btw, there is inconsistency between pricing page and pricing on docs.
Pricing page for developers is $59 Pricing in docs for developers is $99
great catch on pricing mismatch, just fixed, thank you :)
https://scalar.com https://github.com/scalar/scalar
(disclaimer: im the co-founder & ceo of scalar)
As for the infra, it’s not totally free—our managed service is there for anyone who doesn’t want the hassle of hosting and scaling everything themselves (although it does have a generous free plan). Going open-source just gives people the choice: run it yourself if you want full control, or use our managed option for convenience and scale. It’s all about making browser automation more accessible without forcing people into one path.
We'll probably take a deeper look at this in the next few weeks and expand on what we work with vs what we don't.
So you would just need to add some wrapper code and call those actions using a model of your choice.
We're working on more examples and guides that show how you can do this, so keep an eye out on our releases or hop in the discord and you should see some specific examples very soon!
Curious, what made you think browser extension first? :)
It would be cheaper (free?) and easier to maintain, one could even use the chatgpt.com or claude.ai web app as API.