Should I use railway.json or railway.toml?

Railway reads either format identically, so the choice is stylistic. JSON suits teams that already template JSON configs; TOML is more readable and comment-friendly. The generator produces the same settings in both and names the download railway.json or railway.toml to match your toggle.

What does the audit panel check?

It flags the mistakes that silently break deploys: a Dockerfile builder with a Nixpacks plan set (the plan is ignored), a healthcheck path missing its leading slash, an ON_FAILURE restart policy with no maxRetries (Railway then retries forever), and a Nixpacks build with no start command. It also notes cron jobs that still have a healthcheck and odd sleep-plus-replicas combinations.

When do I need the nixpacks.toml output?

Nixpacks auto-detects most runtimes, so a railway.json with a builder of NIXPACKS is usually enough. You only need a nixpacks.toml when you want extra system packages or to pin specific build and start phases. Enable the companion output and the generator emits a nixpacks.toml from your package list and build command alongside the main config.

What do the restart policy options mean?

ON_FAILURE restarts the service only on a non-zero exit, up to the maxRetries cap you set — without a cap Railway retries indefinitely, which the audit warns about. ALWAYS restarts on any exit and suits long-running workers. NEVER leaves a crashed service stopped, which fits run-to-completion and cron-style jobs.

How do region, replicas, and sleep affect my service?

Region pins the service to a specific Railway metal so it runs close to your users or data. numReplicas is only emitted when greater than one, scaling the service horizontally. sleepApplication scales a low-traffic service to zero between requests; it rarely pairs well with multiple replicas, which the audit notes.

Does this set environment variables or cron schedules?

No. Environment variables and the actual cron trigger are configured in the Railway dashboard, not in railway.json, which keeps secrets out of your repository. The cron field here is documentation only — it records the intended cadence so the config explains itself, while you set the real schedule in Railway.

Railway Config Generator

Model a complete Railway service visually and emit a valid railway.json or railway.toml — builder (Nixpacks or Dockerfile), build command, watch patterns and a Nixpacks package plan, plus a full deploy block with start command, healthcheck, restart policy, replicas, region and sleep. A live audit catches the mistakes that silently break deploys, and you can ship a companion nixpacks.toml in the same pass.

About this ToolHow it works, benefits & use cases

Railway reads its build and deploy settings from a railway.json or railway.toml file at your repo root, and this generator models the whole service so you can emit either format from one form. The build half covers the builder (Nixpacks or Dockerfile), a build command, watch patterns that limit rebuilds to changed paths, and an optional Nixpacks package plan for extra system dependencies. The deploy half covers the start command, a healthcheck path and timeout, the restart policy (on failure with a max-retries cap, always, or never), replica count, region, and whether the app sleeps when idle. Five presets cover a Node web service, a Dockerfile service, a worker, a cron-style job, and a static site. A live audit panel flags the mistakes that quietly break deploys, the config regenerates instantly as you type, and you can also emit a companion nixpacks.toml in the same pass.

How to Use

1Pick a preset (Node web service, Dockerfile service, Worker, Cron-style, or Static) to prefill a sensible build and deploy block.
2Choose the output format with the railway.json / railway.toml toggle.
3Set the builder to Nixpacks or Dockerfile; for Dockerfile builds enter the Dockerfile path, otherwise enter a build command.
4Optionally add watch patterns and, for Nixpacks, extra system packages plus a companion nixpacks.toml.
5Fill in the deploy block: start command, healthcheck path and timeout, restart policy and max retries, replicas, region, and sleep.
6Watch the audit panel for warnings, then copy or download the live config for your repo root.

Key Benefits

Emits valid railway.json or railway.toml from one model with a single toggle
Full build block: Nixpacks or Dockerfile builder, build command, watch patterns, and a Nixpacks package plan
Full deploy block: start command, healthcheck, restart policy with max retries, replicas, region, and sleep
Built-in audit flags ignored Nixpacks plans, missing healthcheck slashes, retry-forever policies, and missing start commands
Five presets covering web, Dockerfile, worker, cron, and static services
Optional companion nixpacks.toml generated from the same packages and build command
Pure in-browser generation with live preview, copy, download, and a shareable link

Common Use Cases

Bootstrapping railway.json for a Node web service with a healthcheck and bounded retries
Switching a service to Dockerfile-based builds with an explicit Dockerfile path
Configuring an always-on background worker with no HTTP healthcheck
Setting up a run-to-completion cron-style job with a NEVER restart policy
Pinning a service to a region and tuning replicas, sleep, and healthcheck timeouts

railway.json

Place at your repo root · JSON · updates live

{
  "$schema": "https://railway.com/railway.schema.json",
  "build": {
    "builder": "NIXPACKS",
    "buildCommand": "npm ci && npm run build"
  },
  "deploy": {
    "startCommand": "npm run start",
    "healthcheckPath": "/health",
    "healthcheckTimeout": 300,
    "restartPolicyType": "ON_FAILURE",
    "restartPolicyMaxRetries": 3
  }
}

Config looks valid

Start from a preset

Output format

Build

Builder

Auto-detected build — no Dockerfile required

Build command

Watch patterns (comma-separated, optional)

Only rebuild when these paths change.

Nixpacks packages (comma-separated, optional)

Extra system packages baked into the build via nixpacksPlan.

Also emit a companion nixpacks.toml

Generates a separate nixpacks.toml from your packages + build command.

Deploy

Start command

Healthcheck path (optional)

Healthcheck timeout (s)

Restart policy

Restart only on a non-zero exit (uses maxRetries)

Max retries

Replicas

Region

Cron schedule (optional, documentation)

Railway crons are set in the dashboard; this just notes the intended cadence.

Sleep application when idle

Scale to zero between requests on low-traffic services.

A service model, not a snippet

Railway reads railway.json or railway.toml from your repo root. This builder models the whole service — the build half (Nixpacks or Dockerfile, build command, watch patterns, a Nixpacks package plan) and the deploy half (start command, healthcheck, restart policy, replicas, region, sleep) — and emits valid output in either format live as you edit.

What the audit catches

A DOCKERFILE builder with a Nixpacks plan set (the plan is ignored).
A healthcheckPath missing its leading slash.
ON_FAILURE restart with no maxRetries — Railway retries forever.
A Nixpacks build with no startCommand to launch the service.

Was this tool helpful?

Share Your Experience

Help others discover this tool!

Share on

Railway Config Generator

How to Use

Key Benefits

Common Use Cases

Start from a preset

Output format

Build

Deploy

A service model, not a snippet

What the audit catches

Was this tool helpful?

Share Your Experience

Related tools

Frequently Asked Questions - Railway Config Generator