Name: railway-deploy
Author: yortyrh

Prompt file imported from yortyrh/resubuild (.cursor/commands/railway-deploy.md). Copyright stays with the author.

/opsx:railway-deploy

Walk the operator (or an LLM agent) through the release-1 Railway deploy target for resubuild.

This command is a thin wrapper around pnpm setup:env:prod --target railway (the extended env generator) and pnpm deploy:railway (the preflight check). It does not invoke railway up directly — the operator runs the two railway up --service <name> commands manually so they can watch the build log.

Use this command when: the operator wants to deploy resubuild to a managed Railway project connected to a cloud Supabase instance, reusing the existing apps/api/Dockerfile and apps/web/Dockerfile.

Prerequisites:

A Supabase project (cloud, not self-hosted) with:
- A media storage bucket
- A mcp-exports storage bucket (or adjust the MCP_EXPORT_BUCKET value)
Credentials from Supabase Dashboard → Project Settings → API:
- Project URL
- Anon key
- Service role key
The Railway CLI installed (npm install -g @railway/cli or brew install railway)
A Railway account (https://railway.com)

Step 1 — Collect credentials and write the manifest

When prompted, provide:

Supabase project URL
Supabase anon key
Supabase service role key (treated as confidential — never exposed in chat)
Storage bucket names (defaults: media and mcp-exports)

The command writes your credentials to prod-secrets.json in the workspace root. This file is gitignored. If a prod-secrets.json already exists on disk, the command reuses it and just verifies the required keys are present.

The manifest MUST set "DEPLOY_TARGET": "railway" so the generator bakes the production custom-domain defaults. If it does not, the operator can pass --target railway on the CLI in Step 3 (the manifest still wins).

Do NOT paste secret values directly into chat. Use the prompt fields or write a manifest file.

Step 2 — Dry-run review

The command runs the generator in dry-run mode first so the operator can review the output before any file is written:

pnpm setup:env:prod --target railway --from prod-secrets.json --dry-run

The four public-URL keys (CORS_ORIGIN, APP_URL, PUBLIC_API_URL, NEXT_PUBLIC_API_URL) MUST be visible as the production custom domains (https://app.resubuild.dev for the web app, https://api.resubuild.dev for the API), not docker compose placeholders. Review the output carefully before confirming.

If the dry-run output looks wrong, answer "no" and the file will not be written.

Step 3 — Confirm to write `.env.prod`

Only after the operator confirms, the command runs:

pnpm setup:env:prod --target railway --from prod-secrets.json

The script writes .env.prod and prints a one-line note about the production custom domains (the placeholders are gone — the values are now the real production custom domains, so no find-and-replace step is needed as long as the operator attaches the matching custom domains in the Railway dashboard).

Step 4 — Stop and confirm with the operator

The command stops here and asks the operator to confirm two more steps before they run them manually:

Run the preflight — pnpm deploy:railway confirms .env.prod is well-formed and prints the two railway up commands.
Create the Railway project + two services + paste Variables + attach custom domains + enable App Sleeping — see the .cursor/skills/railway-deploy/SKILL.md workflow for the per-service Variables split, the public-URL handshake, the custom-domain attachment, and the App Sleeping toggle (the toggle is the operator's signal that the service should scale to zero — it is a per-service dashboard setting, not a railway.json field).

This command does not call railway up. The operator runs the two railway up --service <name> commands themselves, one at a time, watching each build log.

Step 5 — Verify

After the deploys complete, the operator runs the two curl checks from the SKILL:

curl -f https://api.resubuild.dev/_health
curl -f https://app.resubuild.dev/

Files

SKILL (LLM agents): .cursor/skills/railway-deploy/SKILL.md
Service config: apps/api/railway.json, apps/web/railway.json
Build context exclusions: .railwayignore
Preflight wrapper: scripts/deploy-railway.mjs
Generator (extended with --target railway): scripts/setup-prod-env.mjs
Schema: scripts/lib/env-prod-schema.mjs
Full spec: openspec/changes/railway-deployment/specs/railway-deployment/spec.md

Quick reference

# Dry-run (review the public-URL placeholders)
pnpm setup:env:prod --target railway --from prod-secrets.json --dry-run

# Write .env.prod
pnpm setup:env:prod --target railway --from prod-secrets.json

# Preflight + print the two deploy commands
pnpm deploy:railway

# Verify after deploy
curl -f https://api.resubuild.dev/_health
curl -f https://app.resubuild.dev/

Install railway-deploy and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# /opsx:railway-deploy Walk the operator (or an LLM agent) through the release-1 Railway deploy target for resubuild. This command is a thin wrapper around `pnpm setup:env:prod --target railway` (the extended env generator) and `pnpm deploy:railway` (the preflight check). It does not invoke `railway up` directly — the operator runs the two `railway up --service <name>` commands manually so they can watch the build log. **Use this command when:** the operator wants to deploy resubuild to a managed Railway project connected to a cloud Supabase instance, reusing the existing `apps/api/Dockerfile` and `apps/web/Dockerfile`. **Prerequisites:** 1. A Supabase project (cloud, not self-hosted) with: - A `media` storage bucket - A `mcp-exports` storage bucket (or adjust the `MCP_EXPORT_BUCKET` value) 2. Credentials from Supabase Dashboard → Project Settings → API: - Project URL - Anon key - Service role key 3. The Railway CLI installed (`npm install -g @railway/cli` or `brew install railway`) 4. A Railway account (https://railway.com) --- ## Step 1 — Collect credentials and write the manifest When prompted, provide: - Supabase project URL - Supabase anon key - Supabase service role key (treated as confidential — never exposed in chat) - Storage bucket names (defaults: `media` and `mcp-exports`) The command writes your credentials to `prod-secrets.json` in the workspace root. This file is gitignored. If a `prod-secrets.json` already exists on disk, the command reuses it and just verifies the required keys are present. The manifest MUST set `"DEPLOY_TARGET": "railway"` so the generator bakes the production custom-domain defaults. If it does not, the operator can pass `--target railway` on the CLI in Step 3 (the manifest still wins). **Do NOT paste secret values directly into chat.** Use the prompt fields or write a manifest file. --- ## Step 2 — Dry-run review The command runs the generator in dry-run mode first so the operator can review the output before any file is written: ```bash pnpm setup:env:prod --target railway --from prod-secrets.json --dry-run ``` The four public-URL keys (`CORS_ORIGIN`, `APP_URL`, `PUBLIC_API_URL`, `NEXT_PUBLIC_API_URL`) MUST be visible as the production custom domains (`https://app.resubuild.dev` for the web app, `https://api.resubuild.dev` for the API), not docker compose placeholders. **Review the output carefully** before confirming. If the dry-run output looks wrong, answer "no" and the file will not be written. --- ## Step 3 — Confirm to write `.env.prod` Only after the operator confirms, the command runs: ```bash pnpm setup:env:prod --target railway --from prod-secrets.json ``` The script writes `.env.prod` and prints a one-line note about the production custom domains (the placeholders are gone — the values are now the real production custom domains, so no find-and-replace step is needed as long as the operator attaches the matching custom domains in the Railway dashboard). --- ## Step 4 — Stop and confirm with the operator The command stops here and asks the operator to confirm two more steps before they run them manually: 1. **Run the preflight** — `pnpm deploy:railway` confirms `.env.prod` is well-formed and prints the two `railway up` commands. 2. **Create the Railway project + two services + paste Variables + attach custom domains + enable App Sleeping** — see the [`.cursor/skills/railway-deploy/SKILL.md`](../skills/railway-deploy/SKILL.md) workflow for the per-service Variables split, the public-URL handshake, the custom-domain attachment, and the App Sleeping toggle (the toggle is the operator's signal that the service should scale to zero — it is a per-service dashboard setting, not a `railway.json` field). **This command does not call `railway up`.** The operator runs the two `railway up --service <name>` commands themselves, one at a time, watching each build log. --- ## Step 5 — Verify After the deploys complete, the operator runs the two `curl` checks from the SKILL: ```bash curl -f https://api.resubuild.dev/_health curl -f https://app.resubuild.dev/ ``` --- ## Files - SKILL (LLM agents): [`.cursor/skills/railway-deploy/SKILL.md`](../skills/railway-deploy/SKILL.md) - Service config: `apps/api/railway.json`, `apps/web/railway.json` - Build context exclusions: `.railwayignore` - Preflight wrapper: `scripts/deploy-railway.mjs` - Generator (extended with `--target railway`): `scripts/setup-prod-env.mjs` - Schema: `scripts/lib/env-prod-schema.mjs` - Full spec: `openspec/changes/railway-deployment/specs/railway-deployment/spec.md` ## Quick reference ```bash # Dry-run (review the public-URL placeholders) pnpm setup:env:prod --target railway --from prod-secrets.json --dry-run # Write .env.prod pnpm setup:env:prod --target railway --from prod-secrets.json # Preflight + print the two deploy commands pnpm deploy:railway # Verify after deploy curl -f https://api.resubuild.dev/_health curl -f https://app.resubuild.dev/ ```

{ "prompt": "# /opsx:railway-deploy\n\nWalk the operator (or an LLM agent) through the release-1 Railway deploy target for resubuild.\n\nThis command is a thin wrapper around `pnpm setup:env:prod --target railway` (the extended env generator) and `pnpm deploy:railway` (the preflight check). It does not invoke `railway up` directly — the operator runs the two `railway up --service <name>` commands manually so they can watch the build log.\n\n**Use this command when:** the operator wants to deploy resubuild to a managed Railway project connected to a cloud Supabase instance, reusing the existing `apps/api/Dockerfile` and `apps/web/Dockerfile`.\n\n**Prerequisites:**\n\n1. A Supabase project (cloud, not self-hosted) with:\n - A `media` storage bucket\n - A `mcp-exports` storage bucket (or adjust the `MCP_EXPORT_BUCKET` value)\n2. Credentials from Supabase Dashboard → Project Settings → API:\n - Project URL\n - Anon key\n - Service role key\n3. The Railway CLI installed (`npm install -g @railway/cli` or `brew install railway`)\n4. A Railway account (https://railway.com)\n\n---\n\n## Step 1 — Collect credentials and write the manifest\n\nWhen prompted, provide:\n\n- Supabase project URL\n- Supabase anon key\n- Supabase service role key (treated as confidential — never exposed in chat)\n- Storage bucket names (defaults: `media` and `mcp-exports`)\n\nThe command writes your credentials to `prod-secrets.json` in the workspace root. This file is gitignored. If a `prod-secrets.json` already exists on disk, the command reuses it and just verifies the required keys are present.\n\nThe manifest MUST set `\"DEPLOY_TARGET\": \"railway\"` so the generator bakes the production custom-domain defaults. If it does not, the operator can pass `--target railway` on the CLI in Step 3 (the manifest still wins).\n\n**Do NOT paste secret values directly into chat.** Use the prompt fields or write a manifest file.\n\n---\n\n## Step 2 — Dry-run review\n\nThe command runs the generator in dry-run mode first so the operator can review the output before any file is written:\n\n```bash\npnpm setup:env:prod --target railway --from prod-secrets.json --dry-run\n```\n\nThe four public-URL keys (`CORS_ORIGIN`, `APP_URL`, `PUBLIC_API_URL`, `NEXT_PUBLIC_API_URL`) MUST be visible as the production custom domains (`https://app.resubuild.dev` for the web app, `https://api.resubuild.dev` for the API), not docker compose placeholders. **Review the output carefully** before confirming.\n\nIf the dry-run output looks wrong, answer \"no\" and the file will not be written.\n\n---\n\n## Step 3 — Confirm to write `.env.prod`\n\nOnly after the operator confirms, the command runs:\n\n```bash\npnpm setup:env:prod --target railway --from prod-secrets.json\n```\n\nThe script writes `.env.prod` and prints a one-line note about the production custom domains (the placeholders are gone — the values are now the real production custom domains, so no find-and-replace step is needed as long as the operator attaches the matching custom domains in the Railway dashboard).\n\n---\n\n## Step 4 — Stop and confirm with the operator\n\nThe command stops here and asks the operator to confirm two more steps before they run them manually:\n\n1. **Run the preflight** — `pnpm deploy:railway` confirms `.env.prod` is well-formed and prints the two `railway up` commands.\n2. **Create the Railway project + two services + paste Variables + attach custom domains + enable App Sleeping** — see the [`.cursor/skills/railway-deploy/SKILL.md`](../skills/railway-deploy/SKILL.md) workflow for the per-service Variables split, the public-URL handshake, the custom-domain attachment, and the App Sleeping toggle (the toggle is the operator's signal that the service should scale to zero — it is a per-service dashboard setting, not a `railway.json` field).\n\n**This command does not call `railway up`.** The operator runs the two `railway up --service <name>` commands themselves, one at a time, watching each build log.\n\n---\n\n## Step 5 — Verify\n\nAfter the deploys complete, the operator runs the two `curl` checks from the SKILL:\n\n```bash\ncurl -f https://api.resubuild.dev/_health\ncurl -f https://app.resubuild.dev/\n```\n\n---\n\n## Files\n\n- SKILL (LLM agents): [`.cursor/skills/railway-deploy/SKILL.md`](../skills/railway-deploy/SKILL.md)\n- Service config: `apps/api/railway.json`, `apps/web/railway.json`\n- Build context exclusions: `.railwayignore`\n- Preflight wrapper: `scripts/deploy-railway.mjs`\n- Generator (extended with `--target railway`): `scripts/setup-prod-env.mjs`\n- Schema: `scripts/lib/env-prod-schema.mjs`\n- Full spec: `openspec/changes/railway-deployment/specs/railway-deployment/spec.md`\n\n## Quick reference\n\n```bash\n# Dry-run (review the public-URL placeholders)\npnpm setup:env:prod --target railway --from prod-secrets.json --dry-run\n\n# Write .env.prod\npnpm setup:env:prod --target railway --from prod-secrets.json\n\n# Preflight + print the two deploy commands\npnpm deploy:railway\n\n# Verify after deploy\ncurl -f https://api.resubuild.dev/_health\ncurl -f https://app.resubuild.dev/\n```", "variables": [], "notes": "Walk the operator (or an LLM agent) through the release-1 Railway deploy target for resubuild.", "metadata": { "source": { "provider": "github-cursor-commands", "repository": "https://github.com/yortyrh/resubuild", "path": ".cursor/commands/railway-deploy.md", "ref": "02f6e31fa5567ad7a17438074f4dba3dc5133140", "url": "https://github.com/yortyrh/resubuild/blob/02f6e31fa5567ad7a17438074f4dba3dc5133140/.cursor/commands/railway-deploy.md", "key": "yortyrh/resubuild/.cursor/commands/railway-deploy.md" } } }

railway-deploy

About

/opsx:railway-deploy

Step 1 — Collect credentials and write the manifest

Step 2 — Dry-run review

Step 3 — Confirm to write `.env.prod`

Step 4 — Stop and confirm with the operator

Step 5 — Verify

Files

Quick reference

Install railway-deploy and it becomes one more candidate the router can pick - when it fits.

Use it

Manifest

Reviews

About

/opsx:railway-deploy

Step 1 — Collect credentials and write the manifest

Step 2 — Dry-run review

Step 3 — Confirm to write .env.prod

Step 4 — Stop and confirm with the operator

Step 5 — Verify

Files

Quick reference

Install railway-deploy and it becomes one more candidate the router can pick - when it fits.

Use it

Manifest

Reviews

Step 3 — Confirm to write `.env.prod`