AI agent infrastructure
Your agent writes code.
Run it on the node.
MCP tools, a REST API and a CLI for agents to deploy sandboxed scripts and containers onto fully-synced Ethereum nodes.
Untrusted code is the default, not the edge case
An agent that can write code is only useful if it can also run it. That is usually where the story gets uncomfortable: the code is unreviewed, the machine is yours, and the blast radius is everything the process can touch.
On BLAZED.sh every container executes isolated in userspace. Agent-generated code runs inside its own sandbox, not on the host. Syscalls stop at the sandbox boundary; the only door out is the local Ethereum node socket. If a deploy misbehaves, you kill one disposable sandbox and nothing else notices.
The API key your agent holds is scoped to its own account and resources, so handing an agent deploy access never means handing it the machine.
Two runtimes, one socket
JavaScript goes out as a script and is live in seconds. Everything else ships as a container. Both wake up with a fully-synced node already injected.
Scripts
JavaScriptThe agent writes Node.js, you paste it into the browser editor or push it over the API, and it is running against mainnet in seconds. ethers.js and web3.js are preinstalled, so generated code works without a build step.
// written by your agent, live in seconds
// ethers.js and web3.js are preinstalled
const provider = new WebSocketProvider(
"ws://blazed_infra_eth-execution:8545"
);
provider.on("pending", async (hash) => {
const tx = await provider.getTransaction(hash);
if (isTarget(tx)) await executeStrategy(tx);
});Containers
any OCI imagePython, Rust, Go, whatever the agent produces. Any Docker or OCI image deploys as-is, including from private registries with automatic image updates.
- Env vars and start command per deploy
- Volumes with mount paths for state
- TCP port forwarding, host ports auto-assigned
- Read logs back to the agent for the next iteration
Speak MCP, HTTP or shell
Three surfaces, one set of capabilities. Whatever your agent already speaks is the right way in.
MCP
agent-nativeThe BLAZED.sh MCP server exposes the whole platform as 15 tools that map one to one onto the API: create, stop and delete containers, write, update and run scripts, read logs, read port mappings. Point Claude, Cursor or any MCP client at it and your agent gets hands.
// one tool call from your agent
{
"tool": "blazed_create_container",
"arguments": {
"name": "mev-bot",
"image": "ghcr.io/you/mev-bot:v3",
"env": "RPC_URL=ws://blazed_infra_eth-execution:8545",
"ports": ["8080"]
}
}REST API
backend.blazed.shThe same surface over HTTPS for agents that speak raw HTTP. Bearer-key auth, create, list, get and delete for containers and scripts, plus run, stop, logs and ports as plain endpoints.
curl -X POST https://backend.blazed.sh/api/containers \
-H "Authorization: Bearer $BLAZED_API_KEY" \
-H "Content-Type: application/json" \
-d '{"name":"mev-bot",
"image":"ghcr.io/you/mev-bot:v3",
"env":"RPC_URL=ws://blazed_infra_eth-execution:8545",
"ports":["8080"]}'CLI
terminal-firstThe same single file, run without the mcp argument. Every platform action as a noun-verb command, --json on any of them for piping into jq, composable in loops, cron and CI.
$ blazed.sh script create watcher --file watch-mempool.js
$ blazed.sh script run <id> # live in seconds
$ blazed.sh container create mev-bot \
--image ghcr.io/you/mev-bot:v3 -p 8080
$ blazed.sh container logs <id> -f # back to the agentWhy co-location
Agent loops die in the network hop
Every observe and verify step in an agent loop is an RPC round-trip. Over a remote provider each one costs 50 to 500 milliseconds of internet, multiplied by every iteration. On BLAZED.sh the loop runs next to the node, so the same call returns in under 10 milliseconds and the mempool it watches is the node's own.
Frequently asked questions
Can I let an agent run code I have not reviewed?
That is the workload the platform is built for. Containers execute isolated in userspace, so agent-generated code runs inside its own sandbox rather than on the host. Every deploy is disposable, and the API key your agent holds is scoped to your account's resources. If the code does something unexpected, the blast radius is one sandbox you can stop with a single call.
Which languages can agent-generated code use?
Two runtimes. Scripts are Node.js, edited in the browser editor or pushed over the API, with ethers.js and web3.js preinstalled; they are the fastest path from agent output to running code. Containers take any Docker/OCI image, so Python, Rust, Go or anything else your agent produces runs as-is, with env vars, volumes and TCP port forwarding.
How does an agent control the platform?
Three equivalent surfaces. The BLAZED.sh MCP server exposes the platform as 15 agent tools that map one to one onto the API (create, list, get, stop and delete containers, read their logs and port mappings, create, update, run, stop and delete scripts) for Claude, Cursor and any MCP client. The REST API at backend.blazed.sh offers the same operations over HTTPS with Bearer-key auth. The CLI is the same single file run without the mcp argument, for agents and humans that live in a terminal.
What chain access does the deployed code get?
Every container and script is injected with a fully-synced Ethereum mainnet node reachable at ws://blazed_infra_eth-execution:8545. That means sub-10ms RPC round-trips, WebSocket subscriptions to logs and pending transactions, and a direct mempool view, with no shared rate limits. Most RPC methods cost 1 credit per call.
What does it cost to experiment?
The Free plan is 0 euro with 1M RPC credits and 1 script, enough to let an agent prototype against mainnet today. Containers start on the Beta plan at 75 euro per month with 5M credits, 1 container and 2 scripts. Usage is per-request credit accounting, so an idle agent costs nothing beyond the plan.
Give your agent a node
Free plan: 1M RPC credits and one script, no card required. Containers start on Beta.