Steel Speaks Rust and Go

Jun 24, 2026

San Francisco

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:

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:

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.

For browser automation, start with Go examples for chromedp, rod, and Playwright, or Rust examples for chromiumoxide and headless_chrome. They show the handoff from a Steel session to the CDP tool, then release the session from the SDK.

For direct Steel APIs, use the Rust and Go variants of scrape, profiles, auth context, credentials, extensions, and files. These cover the parts that usually become local glue: logged-in state, credential fill, extension attachment, file upload, screenshot, PDF, and scrape.

For agent frameworks, there are Go recipes for Genkit, Eino, LangChainGo, Google ADK, and MCP, plus Rust recipes for Rig, Swiftide, and MCP. The computer-use recipes cover Claude, OpenAI, and Gemini in Rust and Go too.

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.