Description: `I have an existing healthy Railway service currently using the image source ghcr.io/railwayapp/function-bun:1.4.0 with a custom start command. The service has a persistent /data volume, service variables, a Railway public domain, and a currently successful deployment. I want to convert this SAME existing service to a private GitHub repository source while preserving the service ID, /data volume attachment, variables, domain, and current working deployment until I explicitly deploy the repository-backed version. The GitHub repository is already authorized and visible to Railway. Railway documents serviceConnect for connecting a repository and serviceInstanceUpdate for start-command/healthcheck changes, but I cannot find documentation describing exactly what serviceConnect does when the existing service is image-backed. Please confirm: 1. Does serviceConnect immediately trigger a deployment, or does it only stage/change the source association? 2. When serviceConnect is used on an existing image-backed service, does connecting the GitHub repository automatically replace/remove the existing image source? 3. Is there a supported way to connect the repository with autodeploy disabled BEFORE the first repository-backed deployment? 4. Can I connect the repository, configure the new start command and healthcheck, verify the resulting configuration, and only then explicitly trigger the first repository-backed deployment while the existing deployment continues serving? 5. Will this transition preserve the same service ID, persistent volume mount, service variables, Railway domain, and deployment history? 6. If the first repository-backed deployment fails and I roll back to the previous successful image-backed deployment, does rollback also restore the previous service source and start-command configuration, or would I need to restore those service settings separately? I am specifically trying to avoid an intermediate source-less or partially converted service state. I already have a verified restorable backup of the persistent volume and do not want to experiment on the currently working service merely to determine these transition semantics.`

Safe conversion of existing image-backed service to GitHub source

josekearns-rgb

PROOP

5 days ago

Description:

`I have an existing healthy Railway service currently using the image source ghcr.io/railwayapp/function-bun:1.4.0 with a custom start command. The service has a persistent /data volume, service variables, a Railway public domain, and a currently successful deployment.

I want to convert this SAME existing service to a private GitHub repository source while preserving the service ID, /data volume attachment, variables, domain, and current working deployment until I explicitly deploy the repository-backed version.

The GitHub repository is already authorized and visible to Railway.

Railway documents serviceConnect for connecting a repository and serviceInstanceUpdate for start-command/healthcheck changes, but I cannot find documentation describing exactly what serviceConnect does when the existing service is image-backed.

Please confirm:

Does serviceConnect immediately trigger a deployment, or does it only stage/change the source association?
When serviceConnect is used on an existing image-backed service, does connecting the GitHub repository automatically replace/remove the existing image source?
Is there a supported way to connect the repository with autodeploy disabled BEFORE the first repository-backed deployment?
Can I connect the repository, configure the new start command and healthcheck, verify the resulting configuration, and only then explicitly trigger the first repository-backed deployment while the existing deployment continues serving?
Will this transition preserve the same service ID, persistent volume mount, service variables, Railway domain, and deployment history?
If the first repository-backed deployment fails and I roll back to the previous successful image-backed deployment, does rollback also restore the previous service source and start-command configuration, or would I need to restore those service settings separately?

I am specifically trying to avoid an intermediate source-less or partially converted service state. I already have a verified restorable backup of the persistent volume and do not want to experiment on the currently working service merely to determine these transition semantics.`

$20 Bounty

2 Replies

Railway

BOT

5 days ago

We checked our documentation and it does not cover this yet, so the Railway community is the best place to get a real answer: people who have already worked this out on their own projects and can tell you what actually worked.

So we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who answers it, and threads like this usually get picked up quickly.

Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.

Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
Keep it private and close the thread - Nothing becomes public and the thread closes.

Status changed to Awaiting User Response Railway • 5 days ago

Railway

BOT

5 days ago

This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.

Status changed to Open Railway • 5 days ago

mayori

MODERATOR

5 days ago

serviceConnect will trigger a deployment
Yes, because serviceConnect trigger a deployment, it will remove previous deployment
You can try serviceInstanceUpdate to change source, start command, healthcheck, etc. This function only update the service settings without triggering a deployment (you can change the service source repo, but you can't set which branch to deploy)
(same as 3 above)
Yes
Yes, Rolling back a deployment will use the previous deployment configuration

Welcome!