6 hours ago
This is a general Railway platform workflow question, not a request to inspect or change a particular service.
On Hobby, is it supported to save a custom Dockerfile path, start command, restart policy and CPU/RAM limits on an empty service before attaching any repository or image, without executing a workload?
The staged-changes docs mention holding Alt while clicking Deploy to commit settings without triggering a redeploy. Does that also work for a source-free service that has never had a deployment? Are any of these settings dependent on having a source attached first?
Also, when a configuration-apply operation is marked Failed in Activity but its history detail says “changes applied,” which view proves that the settings actually persisted, and where is the underlying apply error available if no build or deployment exists?
I would appreciate documentation or experience with this specific workflow. Please provide guidance only; no account-specific investigation or infrastructure changes are requested. No project identifiers, code, credentials or screenshots are included. AI-assisted question.
3 Replies
6 hours ago
Yes, that workflow is supported. You can create an Empty Service with no repository or image, set the custom Dockerfile path, start command, restart policy and CPU/RAM limits, and apply them with Deploy. None of those settings requires a source to be attached first, and applying settings on a service that has no source and has never deployed does not start a build or deployment for it. The application only builds and runs once you connect a repository or image and apply that change.
Holding Alt while clicking Deploy (or Alt+Shift+Enter) commits staged changes without triggering deploys, and it works the same way here, though for a source-free, never-deployed service a plain Deploy already applies the settings without running anything. Keep in mind that Deploy applies the whole environment's staged changeset, so review it to make sure it does not also include source changes for other services that would deploy.
For an apply marked Failed, the settings can still have been written before the failure was recorded, so the service's own Settings page is the view that shows what actually persisted. The error message for the failed apply is shown in that change's details in the project activity feed, so it is available even when no build or deployment exists.
Status changed to Awaiting User Response Railway • about 6 hours ago
5 hours ago
Settings still show defaults after the failed apply. Opening the Failed Activity entry shows only “6 changes applied” and an old/new settings diff, without an error message or code. No restaging or retry was performed. What exact read-only view exposes the configuration-apply error when no deployment exists? Could a Railway engineer clarify? Guidance only; no resource changes requested. Private identifiers, code, credentials and screenshots omitted.
Status changed to Awaiting Railway Response Railway • about 5 hours ago
5 hours ago
Our earlier reply was wrong about the Activity feed. A failed apply's entry there shows the Failed badge and the change diff, but not the error text.
The error for a failed apply appears in the red "Deploy failed" banner on the environment's project canvas. The banner shows the error message under the headline, along with "Restore changes" and "Dismiss" buttons. This works even when no build or deployment exists. Dismissing the banner clears it, so read it before you click either button. If no specific error was recorded, the banner shows a generic "Failed to apply changes."
Your service's Settings page still shows the defaults, which means those six changes did not persist on the service.
Status changed to Awaiting User Response Railway • about 5 hours ago