Hey! What’s happening here is actually normal it’s just not very obvious the first time you run into it. ### Auto-deploy on merge When you connect a GitHub repo to a service but don’t explicitly choose a branch in the environment settings, Railway just follows the repo’s default branch (usually `main`). So your dev service was technically watching `main` the whole time. You just didn’t notice because you never manually set a branch. The moment you merged `dev` into `main`, that created a new commit on `main` — and Railway detected it and triggered a deploy on your dev service. Docs here if you want to check: <https://docs.railway.com/deployments/github-autodeploys> ### “Still reading from GitHub after disconnect” This part is related to your `railway.toml`. From your screenshots, the build command (`prisma generate && node scripts/prisma-postgenerate.js...`) is coming from config-as-code. When Railway deployed the service, it cached that config. The “Open file” link pointing to your repo is just showing where that config originally came from — it’s metadata from the last build, not necessarily proof that it’s still actively connected. Another detail: in Railway, changing variables always triggers a redeploy. There’s no simple “Save” button — that’s just how it works. So when you change a variable and hit deploy, it rebuilds using the last known source. If the repo reference wasn’t fully cleared, it’ll try pulling from GitHub again and fail. More on config-as-code: <https://docs.railway.com/config-as-code> ### What I’d do * Go to **Settings → Source** on the dev service and double-check that it’s really disconnected. You should only see “Connect Repo” or “Connect Image” with nothing linked. * If it still behaves strangely after that, honestly, it might be faster to delete the service and create a fresh one when you need it. For your dev workflow, instead of connecting a branch and risking unwanted auto-deploys, you can use `railway up` from the CLI and push manually whenever you want. That gives you full control over when a deploy happens. Also keep in mind: any service connected to that repo will read the `railway.toml`. So if prod and dev need different build configs, you can set a custom config file path per service in the settings.

I truly appreciate the detailed and easy to understand reply! 🙌 So, basically, this seems to be a cache "issue", especially because of the `railway.toml` file, so it always tries to use what was once connected, even if now I have no repo or branch connected. I wanted to avoid having to create or duplicate a service and having to add the custom variables I have, but maybe I will do that. 1 - Delete the current service to clear that cache. 2 - Create a new service, without connecting it to any repo or branch 3 - Add the variables 4 - Do some research on the CLI so I can use that instead just for the `development` service. Since I've been developing solely on GitHub's Codespaces for the last few weeks, using the `development` service will not be used as much, so it's not a big deal to do some extra work. One question: since no GitHub repo/branch will be connected, then in `Custom Build Command` section, it won't show the `railway.toml` file, which means I have to actually type in the command I now have in `railway.toml`, right? And any changes I make to `railway.toml`, I have to go and update the build command, correct? Again, I really appreciate your reply. It was extremely helpful! 💪

Glad it helped! Just one small correction on the build command part: you're right that without a connected repo, Railway won't read the `railway.toml` automatically. But I wouldn't say you _have_ to type everything manually — you have two options: * Type the build command directly in the dashboard (like you said), which means keeping it in sync manually if things change. * Or, when you use `railway up` from the CLI, it will still read your `railway.toml` and apply the build/start commands from there — so you get the best of both worlds. The file acts as your source of truth locally, and Railway follows it during deploys without needing a connected repo. So if you're deploying via CLI (`railway up`), you can keep everything in `railway.toml` and not worry about manually syncing the dashboard. The dashboard settings only take precedence when Railway is building from a connected Git repo without a config file present. In short: * **CLI deploy (**`railway up`**)** → reads `railway.toml` * **Connected repo deploy (no config file)** → uses dashboard settings * **Connected repo deploy (with** `railway.toml`**)** → `railway.toml` Hope that clears it up! Let me know if you run into anything else.