deployment_skill

Overview

This skill manages Railway deployments, letting you list, inspect, redeploy, restart, and remove deployments while viewing and filtering logs for troubleshooting. It covers deployment lifecycle commands and log inspection methods without deleting services (use the environment skill to delete a service). Use this skill to quickly diagnose failures, fetch build or runtime logs, and operate deployments from the CLI.

How this skill works

The skill maps common user intents to Railway CLI operations: deployment list, logs, redeploy, restart, and down. It fetches deployment metadata and IDs, pulls deploy or build logs with flexible filters and time ranges, and runs lifecycle actions (redeploy, restart, remove) with optional confirmation skipping. When presenting logs, it includes timestamps, highlights errors/warnings, and summarizes recurring patterns to aid debugging.

When to use it

• You need to list deployments, check status, or inspect deployment history.
• You want to view logs to debug build failures, runtime errors, or crashes.
• You need to redeploy or restart a service after config or resource changes.
• You want to take down a current deployment without deleting the service.
• You need filtered or time-scoped logs (errors only, recent hour, or specific deployment).

Best practices

• List deployments to get the deployment ID before requesting logs for a specific run.
• Use --latest to capture logs for an in-progress or failed deployment rather than the last successful one.
• For build failures, fetch build logs with --build and include the full error block for context.
• Use time filters (--since/--until) and log filters (@level:error, text search) to reduce noise.
• Skip confirmation (-y) only in scripted or automated workflows to avoid accidental changes.

Example use cases

• List the last 10 deployments for the backend to find a failing deployment ID.
• Fetch the last 200 deploy logs filtered for errors in the past hour to diagnose timeouts.
• Redeploy a service after updating environment variables changed via the environment skill.
• Restart containers (without rebuild) when external resources changed but code did not.
• Take down the current deployment for maintenance while keeping the service record intact.