Railway has stopped new services adopting Config as Code ahead of the December 1 hard cutoff

Railway’s Config-as-Code retirement reached its first enforcement stage on August 28, 2026. Current Railway documentation now states unambiguously that new services cannot opt into Config as Code. Existing `railway.toml` and `railway.json` files continue working only for services that already use them, and December 1, 2026 remains the documented hard cutoff. This resolves an ambiguity in the original August 21 changelog, which said services in new projects would stop using Config as Code while new services in existing projects “should be fine.” Railway’s replacement remains the project-wide TypeScript Infrastructure-as-Code model at `.railway/railway.ts`, with CLI operations for initializing, importing current state, planning changes and applying them.

The migration window is now operational rather than hypothetical. Teams can no longer defer the architecture decision by creating another service on the old config model, and existing repositories have roughly three months to move before their legacy configuration stops being supported. The replacement also has different semantics: Config as Code applied per-service build and deploy overrides, while Railway’s IaC workflow represents project-level desired state. Builders should therefore treat migration as infrastructure-state work, not as a file-format conversion.

Railway’s current documentation says new services cannot opt into Config as Code. The only remaining supported use is for services that already have `railway.toml` or `railway.json` attached. Those legacy services retain the old behavior only until December 1, 2026.

Railway labels December 1 as the hard cutoff for existing Config-as-Code files. Teams that still depend on repository-defined build commands, pre-deploy commands, health checks, restart policies, environment overrides or other legacy settings need a tested replacement before that date rather than assuming the files will be ignored harmlessly.

The preferred model uses `.railway/railway.ts` and Railway’s TypeScript SDK. The CLI exposes `railway config init`, `pull`, `plan` and `apply`, allowing teams to import current Railway state, review a proposed infrastructure diff and apply project-wide changes. This is broader than the old per-service deployment-override model.

For an existing production project, the safest path is to pull current state into the TypeScript representation, inspect it against the live dashboard and run `railway config plan` before applying anything. Variables, services, databases, domains, replicas and other project resources can now participate in the desired-state model, so a mechanical TOML-to-TypeScript rewrite can miss important semantics.

The original launch wording left open whether a new service inside an existing project could continue adopting Config as Code after August 28. Railway’s current documentation now says simply that new services cannot opt in. Existing services already on Config as Code remain the only legacy exception until December 1.