by marclave on 11/26/24, 1:34 PM with 52 comments
by jedberg on 11/26/24, 4:22 PM
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. :)
by huss97 on 11/26/24, 1:39 PM
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.
by orliesaurus on 12/2/24, 3:31 AM
by capiki on 12/2/24, 5:37 AM
by DanielKehoe on 12/2/24, 6:16 AM
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?
by cranberryturkey on 11/26/24, 1:38 PM
by gregpr07 on 12/3/24, 2:26 PM
by potamic on 12/2/24, 2:08 PM
by Oras on 11/26/24, 6:36 PM
Btw, there is inconsistency between pricing page and pricing on docs.
Pricing page for developers is $59 Pricing in docs for developers is $99
by benzguo on 12/2/24, 3:27 AM
by amelius on 12/2/24, 1:47 PM
by meiraleal on 12/2/24, 12:07 PM
by doritopope on 11/26/24, 4:37 PM
by puppycodes on 12/2/24, 4:37 AM
by tndibona on 12/2/24, 1:20 PM