Railway: Making Application Changes Cheap and Safe — Part 1 of 3

Deploy once, then keep changing safely

Deploying a Postgres instance or a GitHub repository gets an application running. Changing it safely can require reconstructing services and production data in staging. Railway’s ambition is to make that ongoing evolution easier, starting with deployment through a visual canvas or a conversation with Claude. This Latent Space conversation follows the infrastructure decisions behind that ambition.

The proposed mechanism is versioning the environment alongside the software: track changes, clone services and production data, validate a modification separately, then bring it back. Railway’s critique of layering Docker, Kubernetes, Ansible scripts and other tools is that the layers can accumulate operational complexity, making each subsequent change harder.

The engineering background recounted here moves from frontend work porting Wolfram Mathematica, through a brief period at Bloomberg, to distributed-systems work migrating Uber’s Jump Bikes systems onto Cadence. The connecting principle is to pursue whatever infrastructure depth the user experience requires. At Railway, that has meant operating physical servers and, during the week of the recording, patching its own Linux kernel fork for a storage layer intended for agent workloads. The patches remained internal, with upstream contribution undecided.

Versioning also raises a question about how changes reach users. The critique of GitHub’s fork-and-merge workflow is that it fragments connections to upstream development and treats changes as merged or unmerged. A more speculative alternative is a continuous stream of changes with progressive rollout. Railway connects its deployable templates and open-source kickback program to making small software components easier to version over time.

The proposed rollout rule is concrete: start where failure has the smallest impact, then expand. In the hypothetical comparison, a casual developer receives a patch before JPMorgan. Real-world testing is unavoidable, but the consequences of failure differ sharply between users.

The free tier forced an economic reset

Railway’s early acquisition strategy was intensely personal. Its website’s support link led to Discord; the speaker kept it open on a second monitor with notifications enabled, ready to greet rare arrivals while trying to get the first hundred users to return. Responding to every request, however, risked turning the product into a consultancy.

Railway describes two recurring phases of product development: - Expansion: add features and test new use cases. - Consolidation: improve the core experience and remove features that no longer fit the intended customers.

The free tier drove the reported 2022–2023 growth surge while attracting unwanted workloads such as crypto miners. The approximate financial recollection is stark: roughly $500,000 lost per month, about $20 million in the bank and perhaps $50,000 in monthly revenue. Railway temporarily cut off free users and spent roughly two years rebuilding the economics. Broad access depended on a sustainable business.

At the time of the conversation, Railway reported 35 employees, approximately three million users and around 100,000 new users per week; the user counts were not defined as active or paying customers. The preference was to build systems rather than continually add headcount, although rapid growth made that difficult: feature requests and breakages competed with improvements to the underlying system. A growing business-customer mix was also bringing more weekday activations.

Parallel agents need capacity and coordination

Railway initially treated agent workflows as a customer-acquisition channel. Over approximately the six months preceding the conversation, it began prioritizing agents as a mechanism for building and deploying software. Its long-term thesis treats natural language as another programming abstraction: an AI market correction or inference bottleneck would not invalidate the direction, just as the dot-com crash did not eliminate the internet’s importance.

The prospect of running thousands of agents introduces two distinct constraints: - Execution economics: both model inference and the compute used to execute agents’ work must become efficient. Even resource sharing would leave substantial execution demand before counting inference. - Coordination: agents need to version changes safely and know when to request human intervention. Poor escalation behavior could overwhelm people with interruptions.

Railway’s architectural response is control over networking, compute, storage and orchestration. It says it largely avoids Kubernetes to retain precise control over workload placement, including opportunities for memory reuse. Operating its own servers is intended to improve performance and make large parallel workloads economically feasible. The thousand-agent scenario remains an ambition here, without a demonstrated workload or benchmark.

Owned hardware earns margins; cloud capacity absorbs growth

The physical setup uses colocation: rent power and a cage in a facility, fill it with racks and servers, and arrange internet connectivity. Railway procures machines through manufacturers and resellers including Supermicro and Dell. It reports an approximately three-month payback period for owned hardware compared with rented cloud capacity, against a roughly four-year depreciation horizon. The underlying cost assumptions are unspecified, so this is Railway’s claimed economics rather than a general rule for leaving the cloud.

Railway still uses cloud bursting—renting additional compute when needed—through AWS, GCP and other providers. As its own space and power become available, it moves workloads onto its servers, reusing the migration system originally built to move off public clouds.

A capacity shortage exposed why that flexibility matters. At the start of the year discussed, an upstream provider could not increase quota quickly enough, and its hardware was slower. Railway reports rebuilding its network overlay over a weekend to span Oracle, AWS, its own infrastructure, GCP and an unnamed fifth provider. Scarce compute forced tighter instance packing and contributed to reliability problems, which Railway said had passed by the recording. Acquiring capacity had become a reliability dependency.

Several financial tools support this operating model: - Owned-server margins subsidize cloud bursting. Railway reports margins around 70% on its hardware, without specifying the accounting basis. - Hardware-secured debt buys servers. This borrowing is distinguished from venture debt, allowing equipment purchases to use financing suited to the assets. - Equity buys strategic capabilities as well as cash. The fundraising argument is to choose investors who address the company’s next constraint; if the company becomes more valuable, equity sold early becomes correspondingly expensive.

The resulting business thesis is conditional: revenue can grow approximately with compute capacity if building and deploying remains easy. That makes the speed of deploying capital consequential. Investor selection follows the same progression: product-building autonomy and advice early, operational help at Series A, then enterprise-sales expertise. An aligned board lets the company concentrate on execution rather than repeatedly debating direction.

An ambitious destination still needs an engineering demonstration

The discussion of space-based data centers distinguishes an unresolved engineering problem from physical impossibility. The skeptical position is that dissipating the required heat in a vacuum may be solvable, but the speaker has not seen a convincing demonstration. Another participant raises possible physical bounds without establishing that they prohibit the idea.

That leaves an investing dilemma: an apparently implausible proposal could be infeasible or a real breakthrough. Betting on future invention differs from demonstrating feasibility, and the answer may take a decade to emerge.

Familiar operations at unfamiliar concurrency

Agents need many of the same development capabilities as humans: - Versioning and incremental tests: try changes in stages, potentially using existing feature flags. A versioning mechanism beyond Git is predicted, though its form remains unsettled. - Queryable observability: use traces, logs and metrics to ask what happened, when it happened and which steps failed. - Working environments that can be changed and copied: networking, compute, storage, file iteration and filesystem snapshots support the work itself.

The central claim is that agents compress familiar workflows into much higher rates and concurrency. Branching and forking remain recognizable operations, but performing thousands of them can invalidate assumptions elsewhere in the stack. The speaker predicts bottlenecks in etcd and suggests networking may need something beyond Envoy; these are architectural expectations, not measured comparisons.

The design consequence is replaceability as bottlenecks move. Improving parallel execution can expose a different constraint, so components must be replaceable. Adding agents is itself bounded: when one participant proposes more agents for code review and vulnerability checks, the response warns that repeated additions eventually encounter an inference constraint. No quantitative limit is given.

Give agents the controls to finish each iteration

A command-line interface (CLI) gives an agent commands for operations such as deploying code and retrieving logs. Railway’s interface argument is that a large set of options burdens people and agents differently: controls a person finds cumbersome can give an agent useful ways to query dynamic information and complete a task. Telemetry should reveal where agents get stuck and guide targeted additions to the interface.

Iteration time is the optimization target. Railway follows the journey from a first successful build to an endpoint and logs, then through repeated changes to code and infrastructure. Its internal aspiration is for users to wait on intelligence rather than compute: infrastructure delays should not dominate the time needed to complete a change.

The more ambitious prediction is that the push, pull and rebuild cycle eventually disappears. A developer or agent would make a small change, work against separate versions of the database and infrastructure, then merge it into a live environment immediately. This remains a desired future workflow.

The canvas shifts from making changes to understanding them

One participant proposes that the CLI will matter more than Railway’s visual canvas in its next growth phase. The response gives the canvas a different responsibility: shift from an input surface to an output surface. Agents use commands to change infrastructure; people use the canvas to understand those changes and decide whether to approve requests.

The canvas is also envisioned as shared system context. A person should be able to drill down from a project into services, functions and code, following a hierarchy that exposes how the parts fit together. This reduces dependence on finding the one employee who understands a microservice. Such structured context is presented as a foundation for much larger systems, described as hyperstructures.

The corresponding criticism of Slack and Discord is that collaboration relies too heavily on repeated message passing and interruptions. Railway’s concrete response is Central Station, an in-house system that groups user feedback and customer-support information into clusters. A developing incident can then become a focused discussion with an estimate of how many users are affected.

Context also determines who receives the issue. A networking problem can be routed to relevant engineers, then commits can help narrow responsibility to a particular component. Railway says this aggregation and routing is no longer manual, avoiding dependence on someone choosing the right persistent chat channel.

A cache incident shows why rollout scope matters

Railway describes publishing real-time platform metrics through publish/subscribe, allowing observers to receive updates instead of repeatedly polling with cron. Its preference for building publicly extends to incident reports, where the team uses both praise and criticism to improve how it explains failures and repairs.

A recent cache-invalidation incident illustrates the limits of pre-release testing. Railway attributes it to an unnamed upstream provider behaving differently from its documentation. Central Station surfaced user reports that caches were not invalidating, and the team says it immediately disabled the change. Staging coverage and tests had missed the edge case; Railway subsequently hardened the affected systems.

Progressive rollout limited exposure, according to the discussion, which puts the impact at approximately 3,000 people without precisely defining the affected-user measure. Railway nevertheless favors broad disclosure when a small subset is affected: notify potentially affected users, investigate the cause and explain what will improve. It connects that practice to honor, one of its company values.

The proposed versioning model offers two ways for customers to receive changes: - Choose when to adopt a version: update to a specific platform version at the customer’s own pace. - Receive a gradual rollout: expand exposure over weeks, beginning with illustrative cohorts such as 0.1% and then 1%.

The speaker calls this nondeterministic version control: users encounter changes at different stages rather than all switching at once. Railway says it already starts rollouts with users for whom changes have lower impact and delivers them to larger companies later. Automatically detecting failures inside customer applications would likely also require integration with customers’ observability systems.

AI reliability agents need somewhere safe to be wrong

The closing discussion considers AI agents doing site reliability engineering (SRE): investigating operational problems and proposing production fixes. The concern is the long tail of complex cases. Even if most suggestions are sound, a plausible-looking fix can still cause an incident after human approval. Approval cannot substitute for infrastructure that makes testing safe.

The envisioned workflow is built into the platform: an agent identifies the services relevant to a hypothesis, copies them and tests its proposed change in those copies. Ideally, it receives a read-only production copy, with personally identifiable information marked for transformation when data is cloned or read. The aim is to make safe experimentation easy; these facilities remain desired behavior rather than a completed validation system demonstrated here.

That workflow depends on testing close to production while containing the consequences. Local, staging and production environments can drift until a successful test says too little about the live system. Railway’s proposed answer is built-in service forks and storage capabilities that narrow those differences and make changes easier to validate.

Part 1 ends with continued skepticism toward AI SREs operating without those foundations. Safe ways to copy volumes and validate changes are prerequisites; an unconstrained agent could otherwise destroy a production database. The warning concerns what could happen when the underlying operations are unsafe, not a reported incident.