The best infrastructure keeps the important work moving without constantly asking for your attention.
This week, the Railway plugin lands in Grok Bot, giving bots an authenticated way to deploy, configure, monitor, and troubleshoot Railway infrastructure. MySQL High Availability brings automatic failover to eligible MySQL services, and starred projects move to the top of your dashboard. We also put a clock on pre-deploy commands and added earlier warnings for agent usage limits.
Let's get into it! 🚄
Railway plugin for Grok Bot
Railway Grok bot pluginYour Grok Bot deserves a Railway engineer. With the Railway plugin, a bot can deploy an application, inspect its logs and performance, troubleshoot a failed release, or coordinate a rollout with other bots.
Ask, “How did the last deployment perform?” and the bot can return request counts, status codes, latency, and resource usage. Turn the same request into a daily routine, and the check keeps running without another prompt.
Install Railway from Grok Bot's plugin directory, click Authenticate, and complete the Railway OAuth flow. The plugin bundles the use-railway skill with Railway's hosted MCP server. Instead of connecting Railway workflows and authenticated tools separately, one plugin gives the bot both. You can connect multiple Railway accounts when your bots work across separate workspaces.
Watch the full demo on YouTube, read the Grok Bot plugin documentation, then build a routine and tell us what your bots take off your plate on Central Station.
MySQL High Availability
MySQL High AvailabilityWhen the primary goes down, MySQL can now choose its own replacement.
Railway grows your existing service into a single-primary Group Replication cluster. The database nodes manage membership, replication, and primary election themselves, so the stack doesn't need a separate Sentinel or coordinator tier. HAProxy gives applications one stable endpoint and routes each connection to whichever node is primary.
Convert a service from Database → Config → High Availability. Railway backs up its data, stages the replicas and HAProxy instances, and updates variable references within your project. The conversion drops active connections, and hardcoded connection strings still need to be updated manually.
Previously, MySQL High Availability was available only through Priority Boarding. It is now generally available for eligible services using a versioned official MySQL 8 or 9 image.
Read the MySQL High Availability documentation, put the cluster through a failover, and tell us how it behaves for your workload on Central Station.
Favorite projects
Favorite ProjectsSome projects are in rotation. Others are home base.
Star a project from its dashboard card in grid or list view, and Railway moves it into a Favorites section above the main project grid. Favorites are personal to each user. In a shared workspace, everyone can keep a different set of projects close at hand without rearranging the dashboard for their teammates.
The section follows your selected dashboard sort, so names and activity stay in the same order as the rest of your projects. Unstar a project and it returns to the main grid.
Previously, every active project lived in the same grid, so the services you use most could drift off the first page.
Star the projects you return to most, and tell us what else the dashboard should keep within reach on Central Station.
Fixes and improvements
-
We shipped a configurable Pre-deploy Timeout from 1 to 3600 seconds. Previously, pre-deploy commands had no user-settable time limit, so a migration waiting on a lock or input could hold a deployment in progress. When the timeout expires, Railway removes the command container and fails the deployment with a clear timeout message. Leaving the field empty preserves the existing unlimited behavior. Read the documentation.
-
We improved agent usage limit notifications with email and in-app warnings before a workspace reaches its effective limit, plus a paused notice when included agent usage runs out. Included plan allowances warn at 50%, 80%, and 90%, while custom hard limits warn at 75% and 90%. Previously, workspaces without an explicitly configured limit could exhaust their included agent usage and be blocked without an email.