a month ago
preDeployCommand DB writes don't persist to the runtime container (Dockerfile builds). With preDeployCommand running bin/rails db:prepare && bin/rails db:seed, the preDeploy logs show successful row upserts, but the runtime container boots to an empty table. We suspect preDeploy runs against a different DATABASE_URL/database than the runtime container on Dockerfile builds (vs. Nixpacks/Railpack). Questions: (a) Does preDeployCommand run against the same database as runtime for Dockerfile-based services? (b) Is the preDeploy container guaranteed to commit/finish before runtime starts? Separately: the preDeployCommand validator rejects a 2-element array (e.g. ["bin/rails db:prepare", "bin/rails db:seed"]) despite the schema suggesting arrays are allowed — had to combine into one && string. Bug or doc gap?
2 Replies
a month ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • about 1 month ago
a month ago
I'd try using a Railway configuration file (https://docs.railway.com/config-as-code/reference) to set your predeploy command. From what I understand, the entire Dockerfile is considered the build process (extremely simplified), and private networking isn't available in the build process.
0x5b62656e5d
I'd try using a Railway configuration file (https://docs.railway.com/config-as-code/reference) to set your predeploy command. From what I understand, the entire Dockerfile is considered the build process (extremely simplified), and private networking isn't available in the build process.
a month ago
Thanks! I think we're already doing what you're describing, which is what makes this puzzling — let me add detail.
We're setting this via config-as-code, in the deploy block of railway.json (not a Dockerfile RUN step):
"deploy": {
"preDeployCommand": ["bin/rails db:prepare && bin/rails db:seed"]
}
(abbreviated — the real command also echoes progress markers.)
Per the pre-deploy command docs, this runs "between building and deploying," "within your private network," with "access to your application's environment variables," and the documented use case is "database migrations or data seeding before your application runs" — exactly our case. So it shouldn't hit the build-phase private-networking limitation.
And the symptom is consistent with that: during pre-deploy the seed succeeds — it logs each row upserted and exits 0 — so it's clearly reaching a database over the private network. The problem is the runtime container then boots to an empty table (Application.count == 0), as if the rows committed in pre-deploy went to a different database than the app connects to at runtime.
So my actual question: for a Dockerfile-built service, is the pre-deploy container guaranteed the same DATABASE_URL / the same Postgres instance as the runtime container? Committed pre-deploy writes being invisible at runtime looks like a DATABASE_URL mismatch between the two containers rather than a networking gap. (DATABASE_URL is a reference to the Postgres service — happy to share the exact variable setup and full deploy logs.)