Deploy and Host an Agent Workbench on Railway

An agent with the three things an agent actually needs: tools it discovers over MCP, a sandbox to run code in, and a memory that survives the conversation.

Four services, already wired to each other. One of them is public.

About Hosting an Agent Workbench

This catalogue is full of agents. OpenClaw alone is installed more than 15,000 times, and several others are in the thousands. Every one of them is a single container: the agent, and whatever it can reach on the open internet.

What is missing is everything around it. Among the four hundred most-installed templates there is not one where an agent is connected to a tool server, a place to execute code, and a memory it keeps. The parts exist separately — an MCP server here, a sandbox there, pgvector somewhere else — and joining them is a day of protocol documentation, private-network addresses and permission flags, for a result that looks obvious afterwards.

The parts here are ordinary. The wiring is the product.

Common Use Cases

• An assistant over your own data — it reads the database through a tool rather than being handed a dump, and computes answers instead of estimating them.
• A place to run what a model wrote — code generated on demand, executed where a runaway loop costs nothing and a stray fetch fails.
• Something that gets less repetitive over weeks — what it worked out on Monday is found again on Friday, in different words, in a different session.

Dependencies for Agent Workbench Hosting

Deployment Dependencies

• An OpenAI-compatible model endpoint — a provider directly, or a gateway in front of several
• Postgres with pgvector — sessions, memory and spend
• Code sandbox — Deno's permission model, Python as WebAssembly
• Template source

Implementation Details

• Memory is not the transcript. The last few turns are replayed; everything older is found by meaning. Embeddings are computed locally with all-MiniLM-L6-v2, so memory costs nothing per turn, works before a model key is added, and what the agent remembers never leaves the deployment.
• Tools arrive over MCP, not through imports. The agent asks the tool server what it can do and hands the answer to the model. Point MCP_URL somewhere else and the agent gains those tools without a rebuild.
• The sandbox has no public domain. Deno denies network, filesystem, environment and subprocesses; Python is CPython compiled to WebAssembly. The right boundary for code your own model wrote, which is careless rather than hostile — and not a virtual machine, which is what code from strangers needs.
• The fetch tool refuses private addresses. An agent with http_get inside a private network is request forgery waiting to happen: every other service is one hop away and needs no credentials. The guard resolves the hostname and judges the address, because a public name with a private A record is the same attack.
• SQL runs in a read-only transaction, so Postgres refuses the write and no cleverness in a generated query gets past it. A ten-second statement timeout handles the cross join a model will eventually write.
• Spend is priced per call and checked before the next one. The failure mode of an agent is not one expensive request, it is a loop nobody was watching. With several replicas two calls can pass the check at once, so this is a brake rather than a ledger — and it is said that way in the repository too.
• Private services bind ::. Railway's private network is IPv6; a socket on 0.0.0.0 has no address there, and the symptom is a connection refused that reads like a crash.

The repository carries scripts/verify-workbench.sh. Its central check writes a fact into a table the agent has never been told about and asks for the SHA-256 of it: answering needs the tool server, which is the only way to read the table, and the sandbox, which is the only way to get the hash exactly right. It then asks again in a new session, where nothing but memory carries the answer. This template was published only after that script passed against a deployment created from the template itself.

One thing to know before deploying: /chat needs a model key, and nothing else does. The sandbox, the tools and the memory all answer on a fresh deployment, so it can be checked before you have decided which provider to pay.

Why Deploy an Agent Workbench on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying an agent workbench on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.