Steel Speaks Rust and Go
Steel Speaks Rust and Go
Steel Speaks Rust and Go
/
/
San Francisco
San Francisco
/
/
JunHyoung Ryu
JunHyoung Ryu
Launch Week v3 -> Day 03 / 05
A lot of agent infrastructure is written in Rust and Go: edge runtimes, orchestration layers, services where latency matters, the backend jobs that have to run again tomorrow. Until now, if you lived in that world, you had to maintain your own bindings against the Steel API.
Not anymore. Steel now has native Rust and Go SDKs.
This is where Launch Week v3 has been heading: Stealth Browser for the runtime, Dedicated IPs for stable network identity, and now Rust and Go SDKs for the services doing the work.
Why we built native SDKs
We felt the gap ourselves. We rewrote our own CLI in Rust, and we kept running into the same thing our customers did: Rust and Go both have real browser tooling, chromiumoxide on the Rust side and chromedp or rod on the Go side, but there was no Steel client for either. So we built both.
How the SDKs work
The latest Rust and Go SDKs are typed API clients for Steel. They cover the resources a workload usually needs: sessions, profiles, credentials, files, extensions, screenshots, scraping, PDFs, and the session computer endpoint.
The SDK handles the Steel side of the loop. Create a Steel session from Rust or Go, set profile and proxy options in the same client, then pass the returned WebSocket URL to the CDP tool you already use: chromiumoxide, chromedp, rod, or something else. When the run is done, release the session from that same SDK.
Both also plug into our computer API, so CUA agents can use OS-level actions through the same client.
In Rust, the session lifecycle stays in one client:
1
2
3
4
5
6
7
use steel::Steel;
let client = Steel::new(std::env::var("STEEL_API_KEY")?);
let session = client.sessions().create(steel::SessionCreateParams::default()).await?;
println!("CDP: {}", session.websocket_url);
client.sessions().release(&session.id, steel::SessionReleaseParams::default()).await?;
The Go version keeps the same shape, with context and explicit errors:
1
2
3
4
5
6
7
8
client := steel.NewClient(os.Getenv("STEEL_API_KEY"))
session, err := client.Sessions.Create(ctx, steel.SessionCreateParams{})
if err != nil {
return err
}
fmt.Println("CDP:", session.WebsocketURL)
_, err = client.Sessions.Release(ctx, session.ID, steel.SessionReleaseParams{})
Rust is async-first. Go is context-first. Both keep session, proxy, and response config typed. If you’ve used the TypeScript or Python SDK, the loop will feel familiar. It does not cover every helper yet; v1 is about creating sessions, configuring them, handing off the CDP URL, and releasing them without leaving Rust or Go.
Cookbook examples are live
We also shipped the examples around the SDKs, because the client alone is not where the integration work ends.
Browser automation
These show the handoff from a Steel session to the CDP tool, then release the session from the SDK.
chromedp in Go
rod in Go
Playwright in Go
chromiumoxide in Rust
headless_chrome in Rust
Direct Steel APIs
These cover the parts people usually had to wrap themselves: logged-in state, credential fill, extension attachment, file upload, screenshot, PDF, and scrape.
Agent frameworks
Genkit in Go
Eino in Go
LangChainGo in Go
Google ADK in Go
Rig in Rust
Swiftide in Rust
Computer use
Get started
Rust package: steel-rs on crates.io
Rust source: github.com/steel-dev/steel-rust
Go package: github.com/steel-dev/steel-go on pkg.go.dev
Go source: github.com/steel-dev/steel-go
Cookbook: docs.steel.dev/cookbook
Try the loop in the stack you already ship, then tell us which language support or helper surface you need next.
Questions? Discord or @steeldotdev.
This post is Day 3 of Steel Launch Week v3. See the full week at steel.dev/launch-week.
Launch Week v3 -> Day 03 / 05
A lot of agent infrastructure is written in Rust and Go: edge runtimes, orchestration layers, services where latency matters, the backend jobs that have to run again tomorrow. Until now, if you lived in that world, you had to maintain your own bindings against the Steel API.
Not anymore. Steel now has native Rust and Go SDKs.
This is where Launch Week v3 has been heading: Stealth Browser for the runtime, Dedicated IPs for stable network identity, and now Rust and Go SDKs for the services doing the work.
Why we built native SDKs
We felt the gap ourselves. We rewrote our own CLI in Rust, and we kept running into the same thing our customers did: Rust and Go both have real browser tooling, chromiumoxide on the Rust side and chromedp or rod on the Go side, but there was no Steel client for either. So we built both.
How the SDKs work
The latest Rust and Go SDKs are typed API clients for Steel. They cover the resources a workload usually needs: sessions, profiles, credentials, files, extensions, screenshots, scraping, PDFs, and the session computer endpoint.
The SDK handles the Steel side of the loop. Create a Steel session from Rust or Go, set profile and proxy options in the same client, then pass the returned WebSocket URL to the CDP tool you already use: chromiumoxide, chromedp, rod, or something else. When the run is done, release the session from that same SDK.
Both also plug into our computer API, so CUA agents can use OS-level actions through the same client.
In Rust, the session lifecycle stays in one client:
1
2
3
4
5
6
7
use steel::Steel;
let client = Steel::new(std::env::var("STEEL_API_KEY")?);
let session = client.sessions().create(steel::SessionCreateParams::default()).await?;
println!("CDP: {}", session.websocket_url);
client.sessions().release(&session.id, steel::SessionReleaseParams::default()).await?;
The Go version keeps the same shape, with context and explicit errors:
1
2
3
4
5
6
7
8
client := steel.NewClient(os.Getenv("STEEL_API_KEY"))
session, err := client.Sessions.Create(ctx, steel.SessionCreateParams{})
if err != nil {
return err
}
fmt.Println("CDP:", session.WebsocketURL)
_, err = client.Sessions.Release(ctx, session.ID, steel.SessionReleaseParams{})
Rust is async-first. Go is context-first. Both keep session, proxy, and response config typed. If you’ve used the TypeScript or Python SDK, the loop will feel familiar. It does not cover every helper yet; v1 is about creating sessions, configuring them, handing off the CDP URL, and releasing them without leaving Rust or Go.
Cookbook examples are live
We also shipped the examples around the SDKs, because the client alone is not where the integration work ends.
Browser automation
These show the handoff from a Steel session to the CDP tool, then release the session from the SDK.
chromedp in Go
rod in Go
Playwright in Go
chromiumoxide in Rust
headless_chrome in Rust
Direct Steel APIs
These cover the parts people usually had to wrap themselves: logged-in state, credential fill, extension attachment, file upload, screenshot, PDF, and scrape.
Agent frameworks
Genkit in Go
Eino in Go
LangChainGo in Go
Google ADK in Go
Rig in Rust
Swiftide in Rust
Computer use
Get started
Rust package: steel-rs on crates.io
Rust source: github.com/steel-dev/steel-rust
Go package: github.com/steel-dev/steel-go on pkg.go.dev
Go source: github.com/steel-dev/steel-go
Cookbook: docs.steel.dev/cookbook
Try the loop in the stack you already ship, then tell us which language support or helper surface you need next.
Questions? Discord or @steeldotdev.
This post is Day 3 of Steel Launch Week v3. See the full week at steel.dev/launch-week.
All Systems Operational