A coding agent can turn infrastructure problems into pull requests by combining Railway metrics, logs, traces, and repository context.
2
Scheduled monitoring gives the system a time-based view of service health, which can avoid reacting to noisy, short-lived threshold spikes.
3
Durable workflows let the monitor retry failed API calls and resume from cached completed steps before an agent creates a fix.
Summary
Mahmoud Abdelwahab presents Railway Autofix, a template that monitors a Railway project and opens GitHub pull requests when infrastructure problems are detected. The system runs on a schedule, collects the project architecture, resource metrics, HTTP metrics, and logs, then identifies affected services. It gathers more context before asking an AI model to produce a debugging plan. OpenCode runs as a headless coding-agent server with access to the repository, Git, and the GitHub CLI. Inngest durable workflows coordinate the process, retry failed steps, and cache completed work. The agent receives the project context and plan, works in a repository-specific session, and opens a pull request with a summary of the root cause and changes. The demo shows this flow from a service with high memory use and request failures to an open pull request for human review.
Abdelwahab starts with Railway services that have realistic production problems. One service shows memory usage climbing quickly, a 94% request error rate, many 500 responses, and response times of several seconds. Another looks healthy in CPU and memory metrics but has very slow database queries, causing pages to take about 30 seconds to load. Normal monitoring would alert an engineer, who would then inspect logs, metrics, and traces. Railway Autofix instead sends the detected problem and its context to a coding agent, which investigates, changes the repository, and opens a pull request for review.
Scheduled analysis gives noisy metrics more context
The proposed monitor runs every 10, 15, or 30 minutes. It first fetches the application's architecture, including deployed frontends, backends, cron jobs, queues, and databases. It then collects CPU and memory data together with HTTP error rates, failed request counts, and latency. The workflow returns the services that exceeded configured thresholds. Abdelwahab prefers analyzing a time slice over triggering directly from an alert webhook. A spiky workload might briefly reach 80% CPU without having a real problem, so the system needs the surrounding data before it decides to investigate.
The monitor gathers outside context before asking for a fix
Once a service looks suspicious, the system pulls project health information, logs, metrics, and other service context. High resource use may simply reflect successful usage, especially if the logs contain no errors. The system could also scan the repository to infer upstream providers and check their status pages. If a payment processor is down, the agent can explain that the application should wait rather than change its own code. The workflow then creates a detailed plan containing the architecture, affected services, high error counts, resource use, failing endpoints, and proposed investigation steps.
Durable execution makes multi-step infrastructure automation resumable
Abdelwahab uses durable workflows to coordinate calls to Railway, language models, databases, and the coding agent. He illustrates the pattern with a video-upload workflow that generates a transcript, creates a summary, and stores both in a database. Each step can retry automatically, with options for schedules such as exponential backoff and custom failure behavior. Completed steps cache their results. If transcription and summarization succeed but database storage fails, a retry continues from the failed step instead of repeating earlier API calls. This matters because the monitoring workflow depends on many external requests that can fail independently.
OpenCode can run as a headless coding-agent service
The coding agent is OpenCode, an open-source terminal agent that allows users to choose an LLM provider or model. Its architecture includes a server implementation with an API, so a separate client can communicate with an agent running on Railway. The deployed environment installs the tools the agent needs, including curl, jq, bash, Git, and the GitHub CLI. OpenCode can inspect the file system, configure Git, and open pull requests. In the demo project, a Bun server calls create open code server and listens on port 4096.
Inngest workflows connect monitoring, context collection, and repair
The demo API exposes Inngest functions and a debugging UI. In production, monitor project health runs on a schedule. It retrieves the project architecture, then runs resource and HTTP metric collection steps in parallel. The workflow formats CPU, memory, error-rate, latency, and status-count data into summaries. When it finds an affected service, pull service context fetches HTTP logs, build logs, and deployment logs, then passes an architecture summary and service data to the next workflow. The parallel collection keeps the workflow from handling every service one after another.
The language model produces a plan before the agent edits code
The generate fix workflow gives a language model the project architecture and performance data. Its output includes debugging steps such as reproducing the problem locally with the same load, along with recommendations and a proposed fix. That plan is passed to the coding agent rather than asking the agent to begin with only a raw alert. Each repository receives its own agent session, similar to a separate chat. The agent follows the plan, works through errors it encounters, and is expected to create a pull request when the changes are ready.
The completed demo ends with an open pull request containing the generated changes. Its conversation includes a summary of the changes, an analysis summary, the suspected root causes, and what was fixed. The intended operator experience is to review that pull request and merge it if the changes look correct. The automation handles detection, context gathering, planning, repository edits, and pull-request creation, while the engineer still decides whether the proposed repair should enter production.
