Backend Agent

Your senior backend engineer — from code to production-live in one session

What it does

Reads the existing codebase first, then writes every production config file (Dockerfile with multi-stage build, railway.toml, .env.example, GitHub Actions CI, Makefile, DEPLOYMENT.md) in one commit. If a Railway token is provided, it creates the project, connects the repo, sets environment variables, triggers the deployment, polls until live, hits the health check, and hands back a complete deployment report.

What it can do

Codebase Analysis Before Any Config

Reads the repository structure, entry point file, and existing configs before writing a single line. Identifies the language and framework, the port the server binds to, existing health check endpoints (or creates one if missing), and every environment variable the service needs. Nothing is guessed.

“Read our repo and tell me what's needed before we can deploy to Railway”
“Audit our existing Dockerfile and infra configs — what's wrong and what needs fixing?”
“Identify all the environment variables our API needs so I can set them up before deploying”

Production-Grade Config Suite

Writes 6 production files in one commit to a branch: a multi-stage Dockerfile (builder + minimal runtime, non-root user, layer caching, HEALTHCHECK instruction), .dockerignore, railway.toml (builder, health check path, restart policy), .env.example (every required variable documented with purpose and whether it has a safe default), a GitHub Actions CI workflow (lint → test → build → Docker build check), and a Makefile with dev/build/test/docker-run commands. Everything arrives as a PR.

“Write production infra configs for this Fastify API — Dockerfile, CI, railway.toml, .env.example”
“Our Dockerfile has no health check and runs as root — fix it to production standards”
“Write a multi-stage Dockerfile for this Python FastAPI service targeting python:3.12-slim”

End-to-End Railway Deployment

Creates the Railway project, connects the GitHub repo (enabling auto-deploy on push), sets all non-secret environment variables, triggers the initial deployment, and polls the deployment status every 30 seconds until it succeeds or fails. Deployment report includes the Railway project URL, service URL, and a table of which environment variables still need to be set manually in the Railway dashboard.

“Deploy our API to Railway from scratch — create the project, connect the repo, set env vars, deploy”
“Set up auto-deploy on Railway for this service and confirm the first deployment succeeds”
“Create a staging environment on Railway for this service and deploy the current main branch”

Deployment Failure Diagnosis and Recovery

When a deployment fails, reads the actual Railway deployment logs (not just "build failed"), identifies the specific error (wrong COPY path, missing dependency, port mismatch, missing env var), fixes the Dockerfile or config, commits the fix, redeploys, and confirms recovery. Never guesses the cause before reading the logs.

“Our Railway deploy keeps failing — read the logs, find what's broken, fix it, and redeploy”
“The Docker build succeeds locally but fails on Railway — diagnose and fix it”
“The service deployed but the health check is failing — investigate and resolve it”

Health Check Verification

After a successful deployment, hits the service's health endpoint and confirms HTTP 200. If the health check fails, reads the response body to diagnose application-level errors (database not connected, missing config, crash on startup). Only reports "deployment successful" after a confirmed live health check.

“Confirm our newly deployed service is actually healthy and responding correctly”
“The Railway deploy shows success but our monitoring says it's down — investigate”
“Run a full health check suite against the deployed API and report the results”

Deployment Documentation

Writes DEPLOYMENT.md with the exact steps to deploy this service from scratch, including every required environment variable with its description, the Railway project setup process, how to run locally with Docker, and a runbook for common operational tasks (restart, rollback, view logs, update env vars).

“Write a deployment runbook for our API so any engineer on the team can redeploy it”
“Document the full deployment process including all the environment variables and where to get them”
“Create onboarding docs so a new engineer can get this service running locally and deploy to staging”

Good for / not for

Great for

Deploying a new service to Railway for the first time
Fixing broken Docker builds or Railway deployment failures
Upgrading a basic Dockerfile to production standards (multi-stage, non-root, health check)
Setting up CI/CD for a service that has none
Deploying the output of the Code Generator or Architect agents to production
Getting a deployment runbook written when the person who set up the service is no longer available

Not the right fit for

Deploying to AWS, GCP, or Azure (that's the Infrastructure Agent)
Database provisioning and migrations (that's the Database Agent)
Application-layer bugs — the agent fixes deployment config, not your business logic
Services that require manual Railway team configuration not exposed via the API

Example tasks

“Read our Fastify API repo and deploy it to Railway — write the Dockerfile, set up CI, create the Railway project, and confirm the health check passes”
“Our Docker build keeps failing on Railway — read the logs, find the cause, fix the Dockerfile, and redeploy”
“Write production-ready infra configs for this Node.js monorepo: multi-stage Dockerfile, railway.toml, .env.example with all variables documented, and GitHub Actions CI”
“Set up a complete deployment pipeline for this Go API: Dockerfile, Railway project, environment variables, health check, and a runbook in DEPLOYMENT.md”
“Audit our existing Dockerfile and railway.toml — identify what's wrong, rewrite them to best practices, and redeploy”