A runtime the repo never declared
The repo never declared a Node version, so the platform picked one. The runtime is now declared, and CI, the devcontainer and PostgreSQL move to match production.
Nothing in the repository asked for a Node version, so the platform chose its default. This change declares the version in the repo, moves CI, the devcontainer and the PostgreSQL version to match production, and adds two dependency overrides for transitive packages in the production tree.
The version the platform chose#
Railpack, the builder the hosting platform runs, reads engines.node from package.json and installs the newest release in the range it is given. Without the field it had been falling back to its default. The range pins the 24 line, so a build cannot land on another major version. CI and the devcontainer moved to the same line, so a test run and a production build share a major version.
"engines": {
"node": ">=24.x <25"
}Two overrides in the workspace file#
A couple of transitive packages in the production tree needed overrides, so the workspace file now pins them to a floor. Neither is a direct dependency, and the change touches only that file and the lockfile, like the grouped update before it. This change is scoped to the runtime and two dependency pins. The pins look like this:
overrides:
some-transitive-package: '>=x.y.z'PostgreSQL 18 everywhere#
Production runs the managed PostgreSQL that came with the hosting move, and it had moved to 18 while CI and the devcontainer stayed on 16. The docs still named 15. All three now say 18. The cost lands on the devcontainer: a rebuild creates a fresh 18 cluster, and the data in the old 16 volume is no longer read. It stays on disk, but anyone rebuilding should expect an empty database. The match is by major version.
A test whose starting state changed between runs#
The branch also had to clear a failing CI job, and that failure predated it. A turn-by-turn equivalence test built two starting duel states with two separate calls. Each call could start from a different state, so the test failed on some runs and not others. The fix builds the starting state once and hands it to both paths, so the test compares the same game twice. The duel logic did not change. The setup stopped depending on when it ran.
Where this leaves things#
The remaining checks are on the platform side. After the deploy, the production build log should show a 24.x Node install. If the production build log still shows the old runtime after the deploy, that is an open follow-up, and this post will be updated when it is closed.