Here's the updated draft with that reference added — ready to paste:

Subject: Persistent volume never mounts into container — /data absent from filesystem across two fresh deployments

Body:

My attest-gateway service has a persistent volume configured and attached per the service config, but it never actually mounts into the running container's filesystem. Confirmed this is not the n8n HOME/RAILWAY_RUN_UID issue from a similar-sounding recent thread — no UID override, no env var indirection. My app checks os.path.isdir() on the mount path directly, and Railway's own container-inspection tools confirm the directory simply does not exist.

This appears to match a separate open thread from a different user: "Subject: Persistent Volume Not Mounting — Service ID: a73c149a-a423-4916-9abc-e0bfcf4c400f" (station.railway.com/questions/subject-persistent-volume-not-mounting-bb159894), posted 3 days ago — same symptom (volume shows mounted in config, /data absent from container, confirmed across multiple redeploys, confirmed not an application bug), different service and project entirely. Flagging in case this is a broader platform issue rather than isolated to either of our accounts.

Project / service details

Project: AiTTEST (project ID e38563db-8bad-4434-acbf-1851678fa9b4)

Environment: production (e7cdb7bd-9726-46ab-b9e3-983be3f7e1c3)

Service: attest-gateway (service ID c55d6420-ea6f-4533-924b-28c07f7d2aa6)

Volume: attest-gateway-data (volume ID fdc1f151-e78b-4a69-9b71-7e110428f30b), 500 MB, mount path /data

Timeline

Created the volume and attached it to attest-gateway at /data.

Service config immediately showed volumeMounts populated correctly: {"fdc1f151-...": {"mountPath": "/data"}}.

Deployed a code change so the app writes its SQLite database to /data if the directory exists, falling back to a non-persistent path otherwise (this fallback is why the app didn't crash — it silently degraded instead).

First deployment after volume creation (deployment 967b6b9c): built and started successfully. /data was not present in the container.

Triggered a second, fresh redeploy (deployment d07992e5) specifically to rule out a stale-container artifact. /data was still not present.

Evidence

Full root filesystem listing on both deployments shows no /data entry at all. Present: /app, /var, /dev, /proc, /sys, /boot, /usr, /home, /lib, /bin, /opt, /tmp, /mnt, /etc, /root, /run, /srv, /media, /mise. Missing: /data.

DISK_USAGE_GB metric is flat at 0 across every sample for the entire runtime window of both deployments — nothing has ever been written to the volume.

The app's own "seed database if empty" startup logic re-ran on both deployments, independently confirming the database table was genuinely empty at boot each time.

Live container file read confirms the deployed code is correct and matches what was committed — this is not an application bug.

What I'm asking

Why does /data not appear in the container filesystem despite the service config showing it correctly attached?

Is this a known, broader platform issue given the matching report linked above?

Is there a fix, or a different configuration step required beyond attaching the volume through the standard flow?