43 minutes ago
Hello Railway Support team,
We are preparing a controlled production deployment of a Python/FastAPI application and need clarification about rollback, CI integration, and deployment recovery before making any changes.
ENVIRONMENT
- Service: Python/FastAPI backend on Railway
- Repository: Private GitHub repository, branch
main - Current deployment: Sleeping (Serverless enabled)
- Builder: Railpack 0.40.1
- Python: 3.13.15
- Auto Deploy: Enabled
- Wait for CI: Enabled
- Health Check Path: Not configured
- GitHub Actions:
pull_requestandworkflow_dispatchonly; nopushworkflow
A. ROLLBACK AND RECOVERY
- How can we confirm our plan's rollback retention period and whether the current deployment image is still available?
- After deploying a new version, can we restore the exact previous image without rebuilding? For how long?
- Where is the Rollback option? Our deployment menu shows only View Logs, Redeploy, and Remove.
- Does rollback restore environment variables and service settings as well as the image?
- Can we preserve or pin the current image before deploying? If rollback is unavailable, what recovery procedure do you recommend?
B. AUTO DEPLOY AND WAIT FOR CI
- With Auto Deploy and Wait for CI enabled, what happens when a commit is pushed to
mainbut no GitHub Actions workflow runs onpush? Will Railway deploy, wait, skip, or create no deployment? - Could this configuration silently prevent deployments or allow untested code into production? Where can we review the relevant events?
- Does disabling Auto Deploy before merging guarantee that the merge will not trigger a deployment?
- What GitHub Actions configuration do you recommend to ensure Railway deploys only commits that passed CI?
C. FAILED DEPLOYMENTS AND HEALTH CHECKS
- If a new build or health check fails, does the previous deployment remain active?
- Would setting
/healthas the Health Check Path prevent an unhealthy deployment from replacing the current one? Our endpoint does not query PostgreSQL. - Does Serverless change health check or deployment recovery behavior?
D. REDEPLOY AND DEPENDENCIES
- Does Redeploy rebuild the application and reinstall dependencies, or can it reuse the existing image?
- Our deployment shows "No build logs were found." Can expired logs or installed Python package versions be recovered without restarting the service?
- What is the recommended approach to reproducible Python builds when dependencies currently use version ranges?
ADDITIONAL CONTEXT
A separate support discussion covers our PostgreSQL service remaining asleep after a plan change. Database recovery is being handled independently.
We have omitted project identifiers, deployment IDs, credentials, and environment variable values because this is a public discussion. Please advise if project-specific details should be shared through a private channel.
NO CHANGES AUTHORIZED
Please do not wake, restart, redeploy, remove, roll back, or modify any application or database service. We are requesting technical guidance only.
Thank you for your assistance.
Kind regards,
Pablo Gauzzi
ISP Solution
1 Replies
Status changed to Awaiting Railway Response Railway • 40 minutes ago
39 minutes ago
Rollback is in the three-dot menu of an older deployment in the service's Deployments list, not the current one. It restores that deployment's image and its variables. Hobby keeps removed deployment images for 72 hours, and rollback disappears from the menu once that passes, so its absence on older entries means the image is out of the window. Redeploy is different: it creates a new deployment from the same code and build/deploy configuration, and redeploying an old deployment rebuilds from its original source. See plan image retention.
Wait for CI requires a GitHub Actions workflow that runs on: push for main. With only pull_request and workflow_dispatch triggers, nothing on the pushed commit can gate it, so add a push workflow covering your tests; a failed workflow skips the deploy. Skipped deployments appear in deployment history under Show Skipped. Disabling Autodeploy stops deploys on new commits; you can then use Deploy Latest Commit from the Command Palette.
With a healthcheck path such as /health, the new deployment only goes live after it returns a 2xx, so a failed build or healthcheck leaves the previous deployment serving. It is checked only at deploy time, not continuously. Services with a volume have brief downtime on redeploy.
Logs older than your plan's visibility window can't be shown. For reproducible Python builds, pin exact versions in a committed lock or requirements file.
Status changed to Awaiting User Response Railway • 38 minutes ago