Thank you. This does appear consistent with a Railway build-queue or source-ingestion issue.

We already tried both:

1. A GitHub-source deployment, which was removed before build assignment.
2. A local Railway CLI deployment using railway up.

The latest attempt completed local packaging/upload, but Railway removed the deployment before assigning a build. No image was created, so there is no candidate image to restart.

A previous local-source attempt did reach the build stage successfully, which confirms that the Dockerfile and build context can work.

Could a Railway staff member inspect the deployment event and confirm whether the source upload was received and why no build was assigned?

I can provide the deployment ID and exact UTC timestamp privately to Railway staff.

1. Why a deployment gets removed after a successful local upload but before build assignment

When the source upload succeeds but no build is ever assigned, the deployment is stuck at the "waiting for build" queue stage, not at ingestion. Railway auto-reaps deployments that sit in a pre-build state without being picked up by a builder (the ~5-minute removal you saw is the reaper, not a crash). This is almost always one of two things:

• A transient build-queue/scheduler hiccup on Railway's side for that region/service.
• A stale or conflicting deployment state on the service that blocks a new build from being scheduled.

The fact that a prior local railway up did reach the build stage successfully tells you your Dockerfile and build context are fine — this is a scheduling/state issue, not a config issue.

2. Could this be a service-specific ingestion or queue issue?

Yes, and the evidence points that way. Both your GitHub-source and your post-correction local attempt died at the same stage (record created, no build assigned) while your database and other services were untouched. That's the signature of a per-service queue/state problem rather than a project-wide or account-wide outage.

3. Confirming Railway fully received the uploaded source

• railway up prints an upload/packaging confirmation and returns a deployment URL . if you got that, the source reached Railway.
• Check the deployment's build logs / events in the dashboard (Deployments → the deployment → View Logs). If you see the source snapshot logged but no builder assigned, upload succeeded and the failure is downstream.
• railway logs and the deployment's event timeline will show the "Removed" event with a reason if one was recorded.

4. Redeploying a previous successful image after fixing env vars — without rebuilding

Yes. This is the fastest path for you right now. Env-var changes do NOT require a rebuild:

• In the dashboard, open the last deployment that built successfully and created an image, and use Redeploy (three-dot menu → Redeploy). This reuses the existing image.
• Or roll back: the deployment with the good image → Rollback, then update the env vars.
• Updating env vars alone triggers a redeploy of the existing image, not a source rebuild — so correct the variables, then redeploy the known-good image rather than pushing new source.

5. Service source config / deployment state to reset

A few things worth trying, in order:

• Cancel/remove any stuck deployments still in a pending state so they stop competing in the queue.
• Trigger a fresh railway up --detach and watch the event timeline immediately.
• If GitHub-source keeps stalling at "waiting for source snapshot," disconnect and reconnect the repo on the service (Settings → Source) to clear stale source config.
• If both paths still stall, the service-level state likely needs a Railway-side reset — worth escalating.

Fastest unblock: redeploy the last known-good image with corrected env vars (question 4). That gets you back to a healthy candidate without depending on the build queue at all.

If a Railway staffer picks this up, share the project/service/deployment IDs and the exact UTC timestamp of the removed deployment so they can check the reason on the removal event.