Dora NodaOn August 21, Railway's changelog #0304 contained a sentence worth reading twice: "we are speeding towards a world where builds don't exist and your application is just live." Three weeks later, on September 11, the EU Cyber Resilience Act's vulnerability reporting obligations took effect, requiring manufacturers to report actively exploited vulnerabilities in their products on a clock measured in hours. One industry is deleting the build step. The other just made the paperwork the build step produces a legal requirement. This post is about that collision: a concrete inventory of what dies with the build — the digest to pin, the SBOM to audit, the provenance to verify, the artifact to roll back to — and why a self-hosted git-push PaaS keeps the build in the loop even when skipping it looks faster.
What Railway actually announced
Fairness first: Railway's frustration is real, and anyone who has watched a deploy queue stall behind a build farm feels it. The changelog opens with "we hear you on the annoyance about builds" and notes that "a lot of the new announcements we have here use pure VMs for your workloads." The context is a burst of agent-shaped product: Cloud Agents that run coding harnesses in VMs reachable from web, terminal, or phone, a dev.new prototype app builder on the same VM substrate, and anonymous provisioning — build a site or database without an account, with 60 minutes to claim it.
The thesis sentence lands exactly where you'd expect: "Deployment is still the slowest step," and builds are a large share of why.
Strip away the marketing cadence and the technical claim is straightforward: instead of turning your git push into an OCI image through a build pipeline and then scheduling that image, put the workload on a VM and mutate it into the running state directly. No Dockerfile evaluation, no layer push, no waiting. Your application is just live.
The appeal is obvious. The question is what you traded for the speed. A build step was never just a format conversion from source to runnable. It was the moment your platform produced evidence: what went in, what came out, and a fingerprint binding the two. Delete the step and you delete the evidence. Here is the inventory.
What dies with the build
Every row in this table is something a standard OCI-image pipeline emits today, mostly by default, and something a mutate-the-VM deploy has no equivalent for:
| Artifact | What it does | Build-based deploy | Buildless VM deploy |
|---|---|---|---|
Image digest (sha256:…) | Immutable fingerprint of exactly what is running | Every push produces one; deploys pin it | No digest — "what's running" is whatever the VM's filesystem currently contains |
| SBOM (SPDX/CycloneDX) | Machine-readable list of every component inside | Emitted by BuildKit and attached to the image via OCI referrers | Nothing to attach it to; the component set drifts with every in-place change |
| SLSA provenance | Signed record of how the artifact was built: source commit, builder, inputs | mode=max records the full build; verifiable with cosign verify-attestation | No build, no provenance — there is no build event to attest |
| Signature (Sigstore/cosign) | Binds artifact to a builder identity via keyless OIDC | Baseline hygiene in 2026; one command to verify | Nothing immutable to sign; a signature over a mutable disk is stale on arrival |
| Vulnerability-scan target | A fixed artifact a scanner can grade before it ships | Scan the image, gate the deploy on the result | The scan target changes under you; results expire with every live mutation |
| Reproducible artifact | Same inputs, same bytes — anyone can rebuild and compare | Attested, rebuildable from the pinned commit | Unreproducible by construction; the run state was never derived from inputs alone |
| Rollback unit | A previous known-good artifact that still exists | Old digest sits in the registry; redeploy it | Roll back to what? A disk snapshot fuses code with state (more below) |
None of these rows is exotic tooling. This is what docker/build-push-action with default provenance plus a Sigstore signing step — the setup thousands of repos run as unremarkable CI hygiene in 2026 — hands you for free. The buildless world doesn't replace any of them with something better. It mostly proceeds as if you won't need them.
Maybe that gamble made sense in 2021. It makes considerably less sense in the month the CRA's reporting clock started ticking.
The CVE-triage test
Imagine the disclosure that ruins a Tuesday: a critical remote-code-execution flaw in a widely used library, actively exploited in the wild. Under the CRA, if your product is in scope and the vulnerability is actively exploited, your first notification to the authorities is due within 24 hours of becoming aware. The clock doesn't care about your deploy architecture. So the question is purely operational: how fast can you answer "which of my running services contain the vulnerable component?"
With per-image SBOMs, this is a database query. Every running service maps to an image digest; every digest carries an SBOM listing its components and versions. You grep the fleet's SBOMs for the package name and get the affected service list in minutes.
That leaves the rest of your 24 hours for the part that actually matters: patching, rebuilding, and redeploying pinned digests whose provenance proves the fix is what's running. The audit trail writes itself because the build wrote it.
With live-mutated VMs, this is an archaeological expedition. There is no canonical component list because there was never a build event that froze one. Each VM's filesystem is the accumulation of an initial provision plus every later mutation — package installs, agent-applied patches, hand-run fixes during the last incident.
Answering "does this box contain libfoo 2.4.1 or 2.4.2" means inspecting every box, and the answer for a box inspected at 9am may be stale by noon if an agent session touched it in between. Your 24 hours evaporate into SSH sessions and dpkg -l output diffed by hand, and the report you file is a survey, not an attestation.
This is the same reason the US Executive Order 14028 pushed SBOMs for federal software years ago: incident response at scale is a data problem before it is an engineering problem, and the build is where the data gets captured. A platform that deletes the build doesn't just lose a deployment convenience. It loses the ability to know, provably and quickly, what it is running — in the exact month regulators started fining you for not knowing.
The rollback test
The second thing the build gives you is the cheapest disaster recovery in the industry: redeploy the previous digest. The old artifact still exists in the registry, byte-identical, with its SBOM and provenance intact. Rollback is a forward operation to a known state, and it touches only code — your database, queues, and object storage are separate systems with their own lifecycle. This separation is the entire point of immutable infrastructure: the unit of deployment carries no state, so replacing it is safe and total.
Now consider the buildless VM. The natural rollback primitive is a disk snapshot — and a disk snapshot cannot distinguish your application code from everything else on that disk. Roll back the snapshot and you roll back the local queue depth, the SQLite file, the uploaded assets, the agent session state, everything the box accumulated since the snapshot was taken. The alternative is forward-fixing the live box: mutate it back toward the previous state by hand or by agent, which is precisely the snowflake-server workflow the industry spent fifteen years escaping — Martin Fowler's original snowflake server warning reads like a deploy runbook for this architecture.
There is a subtler failure too: partial rollback. With immutable artifacts, "version N-1" is a complete, coherent thing. With a mutated VM, version N-1 is a story you tell about what the box used to look like, reconstructed from shell history and memory. Nobody has ever confidently paged through shell history at 3am.
Snapshots are a backup strategy, not a deploy strategy. Conflating the two means every rollback is also a data decision, made under pressure, with no artifact to fall back on when the decision is wrong.
When skipping the build is right — and why bex keeps it
None of this means the buildless thesis is wrong everywhere. It is right in exactly the places where provenance has no value because nothing persists: ephemeral agent sandboxes torn down after a task, Railway's own 60-minute anonymous prototypes, scratch VMs for trying an idea before lunch. When the workload's lifetime is measured in minutes and its blast radius is one developer's experiment, the audit trail costs more than it protects. Railway's VM substrate looks well aimed at that world, and the honest version of the thesis — "prototypes shouldn't wait for pipelines" — is hard to argue with.
Production is the other world. Production workloads persist, face the internet, hold user data, and now answer to regulators who ask what runs where and expect a machine-readable answer. For those workloads, the build is not overhead. The build is the audit trail: the one moment where source, dependencies, and configuration are frozen into a signed, scanned, attributable artifact before the internet can touch it.
That is why a self-hosted git-push PaaS keeps BuildKit in the loop even when skipping it looks faster. The cost of a build — a few minutes of compute on machines you already own — buys the digest you pin, the SBOM you query during the next disclosure, the provenance you show an auditor, and the previous artifact you redeploy when the current one misbehaves. Self-hosting makes this cheaper, not harder: your builder runs on your fleet, your registry sits next to it, and no per-minute build billing ever tempts you to delete the step that produces your evidence.
Railway is optimizing for the time between idea and live. That is a worthy thing to optimize — for prototypes. For everything that outlives the demo, keep the build. The few minutes it costs are the cheapest compliance, incident-response, and rollback insurance your platform will ever buy.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
