Bring your own agents running anywhere, build with them from anywhere, and share sessions with anyone
Start with your existing coding agent, add several more, and make them all accessible from anywhere on the web.
Secure WebSocket tunnel
Run a secure bridge from any host
Run the CLI on any host to open a secure tunnel, and get a whole dev environment for that host accessible from anywhere.
End-to-end encryption
End-to-end encryption to the browser
Run the CLI bridge in end-to-end mode so session traffic between your host and the web app stays encrypted with keys you control—you can bring your own key pair or generate one from the CLI. End-to-end encryption explains setup for individuals and teams.
Any agent, anywhere
Work with any agent that supports the Agent Client Protocol (ACP), including open ones like OpenCode and OpenClaw, or frontier agents like Claude, Codex, Cursor. Supported agents.
Multiple agents in parallel
Run different agents on different hosts at the same time—each opens its own bridge—while everything lands in one shared workspace so you can switch tools without losing context.
Connect any agent, and get a dev environment tailored for the new agentic lifecycle
The new agentic lifecycle is less about writing code by hand and more about reviewing, understanding, and testing what the agent builds.
The agent to build next iteration
Review, understand, and test the iteration
BuildAutomaton brings together tools tailored for building with this new agentic lifecycle to any browser, working with any bridged agent.
Prompt and follow any agent from any device
Prompt any agent, switch between agents instantly, do it across agent providers, frontier and open, local and in the cloud.
Share a session instantly with a secure link
Share sessions with stakeholders via a secure link and control who has access.
Rate limit middleware for public API
In progressAdd token-bucket rate limiter per API key and a simple usage dashboard.
I'll add rate limiting middleware and wire it to Redis. I'll create a new middleware file that implements token-bucket per API key, then update the API routes to use it. I'll also add a simple usage dashboard so you can see request counts per key.
Create file
Create file
Middleware file is in place. Now I need to check the existing API structure and apply the middleware to the v1 items routes. I'll look at how other middleware is applied in this codebase so the pattern is consistent.
Update file
Update file
Routes are updated. I'll add the retry-after header to the 429 response so clients know when to retry, and double-check that the Redis key TTL is set correctly for the sliding window.
Update file
Update file
Summary of what was done:
-
New middleware (
api/src/middleware/rate-limit.ts): Token-bucket rate limiter keyed by API key. Uses Redis in production and in-memory in dev. Default 100 requests per minute per key; 429 responses include aRetry-Afterheader. -
API integration (
app/api/v1/items/route.ts): The v1 items routes (GET, POST, DELETE) now run through the rate limit middleware. Unauthenticated or missing-key requests skip limiting. -
Dashboard: A minimal usage view was added so you can see request counts per key over the last 24h. You can expand this later with charts or export.
If you want to tweak limits, Redis key prefix, or add more routes, say what you’d like changed.
Rate limit middleware for public API
In progressWho can access
Add token-bucket rate limiter per API key and a simple usage dashboard.
I'll add rate limiting middleware and wire it to Redis. I'll create a new middleware file that implements token-bucket per API key, then update the API routes to use it. I'll also add a simple usage dashboard so you can see request counts per key.
Create file
Create file
Middleware file is in place. Now I need to check the existing API structure and apply the middleware to the v1 items routes. I'll look at how other middleware is applied in this codebase so the pattern is consistent.
Update file
Update file
Routes are updated. I'll add the retry-after header to the 429 response so clients know when to retry, and double-check that the Redis key TTL is set correctly for the sliding window.
Update file
Update file
Summary of what was done:
-
New middleware (
api/src/middleware/rate-limit.ts): Token-bucket rate limiter keyed by API key. Uses Redis in production and in-memory in dev. Default 100 requests per minute per key; 429 responses include aRetry-Afterheader. -
API integration (
app/api/v1/items/route.ts): The v1 items routes (GET, POST, DELETE) now run through the rate limit middleware. Unauthenticated or missing-key requests skip limiting. -
Dashboard: A minimal usage view was added so you can see request counts per key over the last 24h. You can expand this later with charts or export.
If you want to tweak limits, Redis key prefix, or add more routes, say what you’d like changed.
Review agent written code by glancing through changes quickly
Skim through files that changed, and get summaries of what changed in each, so you can focus your attention where needed.
Rate limit middleware for public API
In progressAdd token-bucket rate limiter per API key and a simple usage dashboard.
Introduces token-bucket limits per API key, Redis-backed counters, and 429 responses with Retry-After.
Routes GET, POST, and DELETE for v1 items through the shared rate-limit middleware.
Adds a small GET endpoint that returns per-key usage snapshots for the dashboard.
Rate limit middleware for public API
In progressAdd token-bucket rate limiter per API key and a simple usage dashboard.
Introduces token-bucket limits per API key, Redis-backed counters, and 429 responses with Retry-After.
Routes GET, POST, and DELETE for v1 items through the shared rate-limit middleware.
Adds a small GET endpoint that returns per-key usage snapshots for the dashboard.
Rate limit middleware for public API
In progressAdd token-bucket rate limiter per API key and a simple usage dashboard.
Introduces token-bucket limits per API key, Redis-backed counters, and 429 responses with Retry-After.
Routes GET, POST, and DELETE for v1 items through the shared rate-limit middleware.
Adds a small GET endpoint that returns per-key usage snapshots for the dashboard.
Work with your local agent anywhere.
Session, diffs, and live preview in one place—less tunnel juggling and screenshot ping-pong.
Frequently asked questions
- What types of agents are supported?
- BuildAutomaton uses the Agent Client Protocol (ACP), so it supports any agent that implements ACP—including Cursor, Claude Code, Codex CLI, Kiro, and more. See our Supported agents docs for the full list and compatibility notes.
- How do I set up a bridge?
- Run the CLI on the machine you want to make accessible. After installing Node.js, run
npx @buildautomaton/cli(or install the CLI globally). The bridge stays connected until you stop the CLI. See our Getting started guide for full steps. - What does it cost?
- We have a flat subscription fee for BuildAutomaton—see our Pricing page. Your local agents (Cursor, Claude Code, etc.) are priced separately by their providers; you’ll need a subscription for those separately.
- How is the local bridge secured?
- The bridge requires authentication. Only authenticated users can access the resources that the bridge makes available.