chore(deploy): add railway.json build and deploy config

[SantiagoDePolonia]

What

Adds railway.json so a GoModel service deployed on Railway picks up sane build and deploy settings.

Why

Railway templates themselves are composed in the dashboard, but a service deployed from this repo reads railway.json at the root for its build and deploy config. Without it Railway autodetects the builder and runs no healthcheck at all — a deploy is marked live the moment the container starts, not when the gateway can actually serve traffic.

Choices

• builder: DOCKERFILE — use the Dockerfile we already maintain instead of letting Railpack autodetect a Go build, so container deploys match local/compose deploys.
• healthcheckPath: /health/ready rather than /health. Readiness probes storage (required → 503) and the Redis cache (optional → degraded), and deliberately excludes upstream provider reachability (internal/server/readiness.go:44), so a provider outage can't fail a deploy or pull a healthy instance out of rotation. It's also auth-exempt (internal/server/http.go:194), so it works with GOMODEL_MASTER_KEY set, and its probes are capped at 2s so it can't stall behind async model discovery.
• restartPolicyType: ON_FAILURE with 10 retries — a clean exit shouldn't be restart-looped.
• No healthcheckTimeout — Railway's default is fine; no reason to pin a number we'd have to maintain.
• No requiredMountPath — considered forcing a volume at /app/data so SQLite survives redeploys, but it would also force a pointless volume on STORAGE_TYPE=postgres/mongodb deployments. Left to the template/service config instead.

Validated against https://railway.com/railway.schema.json (which is additionalProperties: false, so unknown keys would be rejected).

Impact

None for existing users — the file is inert unless deployed on Railway. This is groundwork for publishing a GoModel template to the Railway marketplace, which is a separate dashboard step.

Summary by CodeRabbit

• Chores
  • Added deployment configuration for Railway environments.
  • Builds now use the project’s Dockerfile.
  • Deployments verify service readiness through a health check endpoint.
  • Failed deployments automatically restart, with up to 10 retry attempts.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 7c73c5b8-4d39-44d5-8977-166b9952f101

📥 Commits

Reviewing files that changed from the base of the PR and between 23cdb25 and e764a1e.

📒 Files selected for processing (1)

• railway.json

---

📝 Walkthrough

Walkthrough

Adds a railway.json deployment configuration using the project’s Dockerfile, /health/ready readiness checks, and automatic restart behavior with up to 10 retries.

Changes

Railway deployment

Layer / File(s)	Summary
Railway build and deployment settings railway.json	Defines the Railway schema, Dockerfile-based build, readiness healthcheck path, and failure restart policy with 10 maximum retries.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Poem

A rabbit hops past Docker’s door,
“Health checks ready!” it cheers once more.
Ten retries tucked beneath its hat,
Railway knows exactly where it’s at.
Deploys with a whisker-light start!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the addition of Railway build and deployment configuration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore/railway-config

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[greptile-apps]

Confidence Score: 5/5

Safe to merge with minimal risk.

The change is a small, inert deployment config file. The referenced Dockerfile exists, and /health/ready is registered and auth-exempt.

No files require special attention.

T-Rex Logs

What T-Rex did

• Fetched the railway schema and validated railway.json syntax; the first in-script AJV attempt failed because the local AJV tool was not installed, but the schema fetch completed successfully.
• Validated railway.json against railway.schema.json using AJV CLI; the command returned railway.json valid with EXIT_CODE 0.
• Checked the Docker-based build references; Dockerfile exists and railway.json config uses builder: DOCKERFILE with healthcheckPath: /health/ready and the relevant restart policy keys.
• Verified that the readiness route /health/ready is defined in code and registered with a GET handler, with /health/ready listed in authSkipPaths.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "chore(deploy): add railway.json build an..." | Re-trigger Greptile}