Hi Railway team, Since June 5th, every new deployment of this service fails at the CREATE_CONTAINER stage with "Failed to create deployment." and no build or deploy logs. The service is currently surviving only on a container deployed May 7th. I've ruled out everything I can on my side — details below. == Service info == - Project: gracious-elegance (5b9a5dbb-1390-42b3-acca-7b6867497240) - Environment: production (403b93af-65d3-4dfd-8f63-a1edfc7208d7) - Service: we-mp-rss (3e21c967-5d44-4a6a-86ef-fb6ff1a2fb3b) - Region: us-west2, 1 replica - Deployed via public Docker image, volume mounted at /app/data == Failed deployments == - fb70a042 — Jun 5, failed at Create container after ~6 min - 999188b0-e6e3-4492-a1ab-6314b6419a4d — same failure - 2bb2f380 — Jun 12, same failure - 4bcea464 — Jun 12, stuck at "Creating containers..." for 29:47, then failed (this attempt used Docker Hub instead of ghcr, see below) == What I've already ruled out == 1. Image problems: ghcr.io/rachelos/we-mp-rss:latest is public with a valid OCI index including linux/amd64 (verified via the registry API). 2. Registry-specific issues: deployment 4bcea464 used the Docker Hub mirror (rachelos/we-mp-rss:latest) — identical failure. Both ghcr.io and docker.io fail at the same stage. 3. Plan limits: Hobby plan, image ~1.5 GB compressed — well within limits. 4. Config drift: no changes to variables, networking, or the volume since the last successful deployment on May 7. == Impact == The May 7 container is still Active and serving, but it crashed once during these deploy attempts and briefly took the service down. I currently cannot ship any update — each deploy risks an outage if the old container is stopped and the new one never comes up. == Ask == Since CREATE_CONTAINER hangs for minutes and fails with no logs, could you check host-level logs for what it's blocked on — the image pull, or attaching the volume that's currently held by the active old deployment? Any guidance on a safe path forward (given the volume) would be much appreciated. Thanks!

All deployments fail at CREATE_CONTAINER in us-west2 (no logs) — service surviving on a May 7 container

kakazhi996

HOBBYOP

25 days ago

Hi Railway team,

Since June 5th, every new deployment of this service fails at the

CREATE_CONTAINER stage with "Failed to create deployment." and no build

or deploy logs. The service is currently surviving only on a container

deployed May 7th. I've ruled out everything I can on my side — details

below.

== Service info ==

Project: gracious-elegance (5b9a5dbb-1390-42b3-acca-7b6867497240)
Environment: production (403b93af-65d3-4dfd-8f63-a1edfc7208d7)
Service: we-mp-rss (3e21c967-5d44-4a6a-86ef-fb6ff1a2fb3b)
Region: us-west2, 1 replica
Deployed via public Docker image, volume mounted at /app/data

== Failed deployments ==

fb70a042 — Jun 5, failed at Create container after ~6 min
999188b0-e6e3-4492-a1ab-6314b6419a4d — same failure
2bb2f380 — Jun 12, same failure
4bcea464 — Jun 12, stuck at "Creating containers..." for 29:47,

then failed (this attempt used Docker Hub instead of ghcr, see below)

== What I've already ruled out ==

Image problems: ghcr.io/rachelos/we-mp-rss:latest is public with a

valid OCI index including linux/amd64 (verified via the registry API).
Registry-specific issues: deployment 4bcea464 used the Docker Hub

mirror (rachelos/we-mp-rss:latest) — identical failure. Both ghcr.io

and docker.io fail at the same stage.
Plan limits: Hobby plan, image ~1.5 GB compressed — well within limits.
Config drift: no changes to variables, networking, or the volume

since the last successful deployment on May 7.

== Impact ==

The May 7 container is still Active and serving, but it crashed once

during these deploy attempts and briefly took the service down. I

currently cannot ship any update — each deploy risks an outage if the

old container is stopped and the new one never comes up.

== Ask ==

Since CREATE_CONTAINER hangs for minutes and fails with no logs, could

you check host-level logs for what it's blocked on — the image pull, or

attaching the volume that's currently held by the active old deployment?

Any guidance on a safe path forward (given the volume) would be much

appreciated. Thanks!

Solved

2 Replies

Status changed to Awaiting Railway Response Railway • 25 days ago

alexeyea

PRO

25 days ago

US West deploy 30 minutes still in progress (not finished), no changes were applied, last time deploy was 8 minutes

angelo-railway

EMPLOYEE

24 days ago

Hey, your case is different from the June 11-12 us-west2 incident other folks hit. Yours started June 5, so "resolved, redeploy" doesn't apply here.

What I think is happening: your service is still running a container from May 7, and that old container is holding your /app/data volume. New deploys can't attach the volume while the old container has it, so they die at CREATE_CONTAINER with no logs.

Try one redeploy now (this week's platform issues are cleared, so it's a clean test). If it fails again, reply here and I'll manually clear the old container so the volume can attach to the new one. Your data is safe either way.

Status changed to Awaiting User Response Railway • 24 days ago

Railway

BOT

17 days ago

This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!

Status changed to Solved Railway • 17 days ago

Welcome!