Railway, Part 2 of 3: Making Agent-Driven Infrastructure Safe to Change

An agent that can deploy itself can also destroy its database

Give an agent access to infrastructure, and a destructive database action becomes a foreseeable failure. That is the opening problem in Part 2 of the Railway conversation. Growing confidence in coding agents makes safe iteration loops more necessary: better code generation still needs a surrounding system that contains mistakes.

The proposed programming model places natural language above deterministic software. A skill describes a procedure or intended behavior, then calls code, applications or other static structures to carry it out. Natural language could become another layer in the progression from assembly through C, C++ and JavaScript, while intent remains grounded in executable logic.

Three artifacts must remain close enough to constrain one another: - Specification: describes the system’s intended behavior. - Implementation: expresses that behavior in code. - Tests: provide executable checks against it. When the specification and tests agree but the implementation diverges, the proposed loop reconciles the code against them. The mechanism is continuous reconciliation; theories of software factories become useful only when someone implements that loop.

Self-deployment needs cheap, disposable environments

One participant describes giving a personal agent access to Railway’s command-line interface, or CLI, imagining that it could provision infrastructure and add capabilities to its own environment. The Railway representative reports a working self-deployment setup: install the CLI inside a workload running on Railway, let the workload modify itself while authenticated in its environment, and invoke deployment from within it. Provisioning whatever new infrastructure an agent needs remains the broader ambition.

The envisioned infrastructure review loop extends that setup: 1. Copy the environment safely, with access to resources needed for the experiment, such as a Postgres instance. 2. Make and assess a change in the disposable copy. 3. Present the result for human review, iterating again when feedback requires changes. 4. Apply the approved result upstream, or discard an unsuccessful attempt. This remains a proposed workflow. The representative acknowledges substantial rough edges in Railway’s agent deployment experience and invites feedback about failures.

Cheap experiments require both low idle cost and fast feedback. Consider the representative’s hypothetical fleet of 1,000 machines, each allocated four virtual CPUs and 16 GB of RAM: reserving that capacity for every agent attempt quickly becomes expensive. The desired deployment unit starts quickly and charges for actual use, making unsuccessful attempts inexpensive to discard.

Railway’s stated thesis combines long-running, stateful Linux execution with usage-based billing. Users should have network, compute and storage, run workloads indefinitely, and avoid paying for statically provisioned capacity they do not use. An agent experiment may need a complete computer and persistent state without needing a fixed allocation throughout its lifetime.

Heroku’s inheritance and the migration gap

Railway’s representative reports migration inquiries from recognizable companies still using Heroku. Asked why Heroku stagnated, the representative offers a speculative explanation: a compute business outside Salesforce’s customer-management focus must compete internally for budget, attention and alignment as well as externally for customers. Heroku’s public messaging is treated as ambiguous, with no definitive shutdown timetable established in the conversation.

Both participants remember Heroku as an early deployment on-ramp, helping them move from uploading files to servers toward a managed deployment workflow. Railway’s ambition extends that role to how people build, deploy and eventually monetize software.

A familiar deployment cycle does not imply feature-for-feature migration. At the time of the conversation, Railway lacks Heroku Pipelines; its environment system offers an approximation. Some workflows therefore need to change, reflecting infrastructure primitives the company says it designed with agents in mind.

Temporal: one user journey, many states

Temporal, a system for managing workflows, enters through a historical example from its precursor, Cadence. A participant whose experience spans almost ten years across both systems recalls Uber trip workflows that stayed active until a ride or rental ended. Pausing a rental in a particular zone could add a charge; ending the trip completed the workflow. This describes the earlier architecture, without asserting what Uber runs today. The programming appeal is to express an entire user journey, top to bottom, as one function.

Agents need a related capability: track whether a task is complete before proceeding, while managing the workflow dynamically. Temporal is described as powerful in production, but changes must preserve deterministic replay—replaying the workflow’s history must remain consistent. A developer who lacks the full picture of the journey and its accumulated state can break that consistency.

The reported deployment pipeline runs on Temporal, including pre-commit hooks, signaling and queuing. As it grew, the work increasingly involved mapping an expanding state machine back onto workflow behavior. The participant had built state-machine implementation and testing infrastructure at Uber and describes beginning similar work again.

Two operational burdens follow: - Changes without full context: a developer can invalidate state, introduce nondeterminism or launch excessive activities. - Manual capacity tuning: activity-slot limits become another operational control. The participant argues that capacity should scale with available memory and virtual CPU resources.

If leaving Temporal, the participant would consider an internal workflow engine and mentions existing internal efforts. This is a hypothetical migration preference. Asked whether such an engine could be casually built with coding agents, the response insists on testing. Another participant argues that existing libraries and explicitly mapped state machines make custom workflow abstractions feasible.

Build systems must accommodate arbitrary workloads

Railway’s internal stack is primarily TypeScript, Rust and Go, with some C for networking and volume-related hooks. TypeScript powers the dashboard, while substantial workflow logic is planned to move from the dashboard stack into the infrastructure stack.

Railpack determines dependencies from source code. Its predecessor, Nixpacks, was built on Nix. The representative identifies a practical problem with that approach: combining different package versions can expand package storage and container images enough to complicate real workloads.

Another participant proposes content addressing and caching as remedies. The response accepts their theoretical value but argues that supporting arbitrary workloads complicates runtime-specific optimization. Across a large user base and heterogeneous machines, those optimizations become difficult without separating specific runtimes, a constraint the team wanted to avoid.

The representative reports work on content-addressable filesystems intended to load data lazily from arbitrary locations and page it into memory. The discussion gives the intended behavior, without performance measurements or availability details.

Faster generation shifts the bottleneck toward deployment

After winter break, the representative pushed the company to use coding tools more aggressively. The accompanying rule is delegate generation, retain architectural judgment: ask an agent to write code, review it, and reconcile the result until it matches the intended implementation. In this view, architectural knowledge becomes more valuable as manual code production becomes less necessary.

Building block storage from scratch supplies the consequential example. Engineers can use their experience and research knowledge to guide agents through designs and large test benches. The speaker characterizes test authoring and side validation as effectively free, without measuring their cost. The proposed advantage is the ability to explore a substantial future design before committing the existing system to it.

The representative sees deployment as a major constraint on faster delivery, alongside financial scrutiny of token spending and limited inference capacity. A Formula One allocation model could emerge: exceptionally capable agent users receive expensive compute budgets to explore and validate a direction, while the same spending may not make sense for less adept users.

Earlier validation has reportedly moved some roadmap expectations from years to months. Once a future design appears viable, the team can skip intermediate implementations and move toward it more directly. These are revised delivery expectations, not reports of completed shipments.

The discussion offers two ways to evaluate that spending: - Business impact: another participant argues that token budgets should be judged against the roadmap’s expected return, much as sales spending is judged against revenue. - Work reaching production: the representative proposes the percentage of tokens that end up in production as a deliberately crude measure. An internal backlog of unmerged pull requests illustrates the gap between generating changes and delivering them.

A questioner then advances a stronger thesis: pull requests could become prompt requests, and code review could become less necessary if other safeguards exist. That remains the questioner’s proposal; the representative’s guidance explicitly retained review of agent-written code.

Operational tools must work beyond one service

An AI system performing site reliability engineering remains aspirational here. The immediate question is which operational tools it would need. Railway’s work spans several stages: - Central Station already serves template maintainers, supporting deployment, maintenance and feedback, with broader access intended incrementally. - Incident tooling reveals forming incidents quickly, according to the representative, who declines to claim that incident clustering is solved. - An internal feature-flagging engine is intended for eventual release, with no date given.

The commercial logic is to expose tools built for internal needs when they can help customers and turn an operational cost into revenue. But working for one service is an insufficient release condition. A prototype may fail across multiple services and require repeated rebuilding; those failures help determine which foundational work should come first.

For core initiatives, the representative describes a deliberate progression from one service to multiple services and then across an environment. Releasing capabilities that work only in narrow configurations creates fragmented experiences and additional support load.

Feature flags control which users receive a change, making them useful for incremental rollouts. One participant argues that agents will need them and recalls Uber’s need to remove accumulated flags. The Railway representative had tried to sell a simpler LaunchDarkly-style product before Railway, but encountered an adoption gap: small customers did not care about flags, while larger customers required substantial supporting infrastructure and scale.

The prediction is that faster AI-assisted development brings those controls into smaller companies sooner. Teams need to define a change’s blast radius—the scope of its possible impact—and be able to shadow it for selected users. The representative’s thousandfold acceleration language describes an expected future, not a measured speedup: the software development lifecycle first compresses, then expands to include new activities.

Cloneable environments challenge “cattle, not pets”

One participant introduces “cattle, not pets”: treat infrastructure instances as replaceable members of a fleet rather than uniquely precious machines. The representative proposes a different condition: uniquely maintained environments could be practical if they were comprehensively cloneable. Losing an instance would become recoverable from its snapshot.

The proposed workflow captures the whole filesystem, loads it lazily, iterates on that environment and eventually merges its filesystem into production. This could remove some setup now expressed through Dockerfiles and Ansible scripts. The proposal leaves state handling and merge semantics unresolved; another participant suggests cataloging the different forms of state in a virtual machine and developing dedicated solutions for each.

The representative expresses willingness to work as deep as the kernel’s networking stack, modifying it if necessary to support this model. That is engineering intent, rather than a report of a completed kernel change.

Scaling the company demands attention at other layers too: getting customer information through support to the engineer who built a feature, making iteration safe, and conveying useful dashboard context to users. At the infrastructure layer, the representative also raises an open architectural question about orchestration: how much should it behave like a real-time operating system versus a feedback control system?

Founder focus depends on clarity and ownership

The solo-founder approach described here has no fixed percentage split between technical work and go-to-market work. It depends on sustained interest across the business and technical stack. The product ambition reaches down to a concrete desired experience: keep a user’s SSH connection alive through snapshotting, so working on the environment feels like ordinary iteration on a virtual machine.

Complementary technical and customer-focused co-founders can work well when their ownership is clearly separated. The representative raises a potential tie-breaking problem with two founders; another participant points out that the CEO can hold the deciding vote, a resolution the representative accepts.

The advice about working more depends on the state of the problem: - When direction is clear: additional effort can help realize the vision. - When direction is uncertain: disconnect and write about the company’s position, goals and problems to gain clarity.

The personal routine described is intense weekday work, Saturday disconnection and Sunday-afternoon writing and planning. It is offered as something that works for the speaker. Advice should be absorbed without becoming binding; experience determines which lessons remain useful. The speaker also argues that society has made failure expensive, discouraging people from departing from established paths.

An independent cloud needs its own thesis

The closing discussion returns to a condition on the agent forecast: broad adoption depends on sufficient inference capacity. The representative expects agents to become a dominant way of expressing and implementing ideas over the following decade, provided enough capacity becomes available.

For Railway, future GPU expectations are distinct from current plans. At the time of the conversation, the company is staying focused and has no plans to offer GPUs. The representative nevertheless strongly expects a vertically integrated build-and-deploy platform eventually to need that compute capability.

Railway had reportedly reached the point of running entirely in its own data centers, then pulled back from that level because of rapid growth. At the time of the conversation, the vast majority of workloads were still running in its own bare-metal data centers. Building an independent cloud requires substantial new engineering, and deeper platform reliability remains an explicit goal.

The strategic commitment is to build around an independent core thesis. Railway’s representative describes drawing heavily on research papers while deliberately avoiding copying the largest cloud providers. Copying their infrastructure, the argument goes, would make Railway converge toward them over time and weaken its ability to compete.