Subject: Service consistently failing at "Create container" step, even after recreating from scratch — no application logs produced

Project: airy-vision (174414e1-f052-46b7-a581-25925b08f1ac)

Environment: production (3c335ce0-b42e-4201-91ae-22358cfdebb4)

Affected service: evolution-api (7e94afab-9993-437c-ae7d-0b3de86e5efd)

Image: atendai/evolution-api:v1.8.7

This service has been failing to deploy since our Railway trial expired and we upgraded to a paid plan today (2026-07-15). All other services in the same project (Redis, MongoDB, Postgres, and a second app service "whatsapp-agent") recovered and are running normally after the plan upgrade. Only this one service continues to fail.

The deployment timeline consistently shows:

Initialization → OK

Deploy › Create container → FAILED ("Failed to create deployment.")

Diagnosis › Infrastructure Error → "This deployment failed at the container creation stage before the container ever started. The same image (atendai/evolution-api:v1.8.7) deployed successfully before, and nothing in the service config could cause a failure this early."

No application/container logs are produced at all (confirmed via railway logs CLI and the dashboard "View logs" — completely empty), suggesting the failure happens before the container process starts.

What we've already tried (all failing with the identical error):

Redeployed the existing service ~5 times over ~10 minutes (deployment IDs: 10a578f5, 1c5a4705, 44ce94b7, 48eed72f, 284126f3, 4c118cbd).

Noticed the region was misconfigured to "europe-west4-drams3a" while every other service runs in "sfo"/"us-west". Rescaled to match — still failed identically.

Deleted the service entirely and recreated it from scratch with the same image and env vars (new service ID 7e94afab-9993-437c-ae7d-0b3de86e5efd, deployment 5ab6cf09-f045-41b9-8c0d-7fdb79a2aa52) — same error, zero logs, correct region.

Since this reproduces on a brand-new service ID, it doesn't look like leftover trial-expiration state — it looks like something on Railway's infrastructure side is preventing this image from being scheduled for our account/project.

Could you please investigate whether this is a Docker Hub pull issue, an account/quota restriction, or a platform-side incident?

Thanks!