5 hours ago
We are preparing an XJRMX staging service with SQLite on an attached Railway volume. Initialization must occur only once under an explicit owner authorization. We have not opened or initialized the live database.
Our offline tests exposed a race if the application and initializer run as the same Unix user: checking a pathname before SQLite opens it does not stop another process replacing that pathname. We need to establish a supported runtime boundary before implementing a live initializer.
Can Railway support the following model, and what official mechanisms and limitations apply?
- A nonroot application and a fixed initializer running as distinct nonroot principals, with the application unable to acquire initializer identity or privileges or modify initializer code and storage ancestors.
- A durable initialization record whose directory and ancestors remain protected from application rename/deletion, including after redeployment and after ordinary SQLite write access is enabled.
- A defined transition from isolated initialization to read-only diagnostics and, only later, operational database write access.
The currently registered database target is /data/xjrmx.sqlite3. SQLite sidecars use /data as their parent. Giving the application write access to /data could also let it rename a private ledger directory located beneath /data, even if that child has restrictive permissions. We therefore cannot assume such a ledger would remain protected.
If this model is not supported, is there an official exclusive initialization-job/volume-handover mechanism that could meet these requirements? We understand that pre-deploy commands do not mount the volume and are not asking to use that hook.
Please distinguish configurable settings from effective runtime enforcement, and indicate how an owner can obtain limited evidence of effective identities, privileges and ownership without reading database contents or secrets.
This is a platform capability question, not a request to debug our application or change our service. No restart, deployment, permission change, volume move or data access is requested. If account identifiers are needed, please indicate an appropriate private channel.
1 Replies
4 hours ago
At the platform level, the volume-related settings are the mount path and the RAILWAY_RUN_UID variable. Volumes are mounted as root, and the volumes guide says to set RAILWAY_RUN_UID=0 when an image runs as a non-root user. The volume is attached when the container starts, not at build time or during the pre-deploy step, and it is mounted directly, not as an overlay. See Using Volumes.
Inside the running container, Unix users, ownership and permission bits on the volume are whatever your image and start command set up. Your own process supervision is what enforces separation between principals, and so whether an application principal can rename entries under /data depends on how you set ownership and permissions there. The settings above are the only volume controls we expose. None of them gives you a separate principal or a protected directory.
From outside the container, the railway volume CLI can list, browse, upload, rename and delete files on the volume, so a workspace member with that access can change the volume regardless of permissions inside the container. Your service's own logs are the place to see effective identities and ownership at runtime, for example output from id or stat that your start command writes before it opens the database.
Status changed to Awaiting User Response Railway • about 5 hours ago