Make Node version configurable + verify Node 25 compatibility (Docker + Swarm)

[hitendras510]

Summary

This PR makes the Node.js version configurable in the Dockerfile and verifies compatibility with Node 25.

Changes

• Introduced ARG NODE_VERSION (default 24.4.0) for flexibility
• Improved PNPM setup with a safe fallback when corepack is unavailable
• Fixed Dockerfile CMD placement to ensure correct container startup
• Clarified environment handling (no .env baked into image)

Testing

Tested using NODE_VERSION=25 with a full production-like setup:

• Docker (multi-stage build)
• PostgreSQL container
• Redis container
• Docker socket integration
• Docker Swarm enabled

Results

• Build completed successfully
• Application starts without errors
• Database and Redis connections verified
• Swarm-based deployment features working
• Restart stability confirmed
• No runtime issues observed in logs

Notes

• Node 25 images may not include corepack by default; fallback ensures PNPM availability
• No breaking changes introduced; default Node version remains unchanged

Suggestion

Consider relaxing engines.node from "^24.4.0" to ">=24.4.0" since Node 25 is compatible.

Greptile Summary

This PR makes the Node.js version configurable via ARG NODE_VERSION (defaulting to 24.4.0) and adds a corepack/pnpm fallback for Node images that lack corepack. It also removes the .env.production copy step and fixes CMD indentation.

• The removal of the .env.production COPY is a silent breaking change: any deployment that previously relied on it being baked in will start without required env vars, causing runtime failures without a clear error pointing at the missing config.
• The corepack enable || true pattern swallows real corepack errors on images that do include corepack, potentially leaving the image in an unexpected state.

Confidence Score: 3/5

Not safe to merge as-is: the silent removal of the .env.production copy step is a breaking change for existing deployments.

The .env.production removal is a P1 issue that can cause silent runtime failures (missing DB URLs, secrets, etc.) in any environment that previously relied on that file being baked into the image. The corepack || true pattern is P2 but masks genuine errors. These issues need to be resolved or explicitly acknowledged with a migration guide before this is merged.

Dockerfile — specifically the commented-out .env.production COPY and the corepack error-suppression pattern.

_{Reviews (1): Last reviewed commit: "feat(docker): make node version configur..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

[greptile-apps]

Silent failure in corepack enable

corepack enable || true always exits 0, so any genuine failure of corepack enable (e.g. a permissions issue on a node image that does include corepack) is silently ignored. The layer then proceeds to run corepack prepare, which will also fail and fall back to npm — leaving the image in a state where pnpm was installed via a different mechanism than expected, without any build-time warning.

A safer pattern is to check whether corepack is available first, rather than suppressing its errors unconditionally:

Suggested change

	RUN corepack enable || true && \
	corepack prepare pnpm@10.22.0 --activate || \
	npm install -g pnpm@10.22.0
	RUN if command -v corepack > /dev/null 2>&1; then \
	corepack enable && corepack prepare pnpm@10.22.0 --activate; \
	else \
	npm install -g pnpm@10.22.0; \
	fi

[greptile-apps]

Breaking change: .env.production no longer copied into image

Commenting out this line silently removes a file that the app may rely on to start. Any existing deployment that depended on .env.production being baked in (database URLs, secret keys, etc.) will now start without those values, causing runtime failures (DB connection errors, missing secrets, etc.) without a clear error message pointing back to the missing copy.

If the intent is to require runtime-supplied env vars going forward, this should be an explicit, documented migration step — not a silent comment-out. Consider keeping the COPY but guarding it conditionally, or at minimum adding a startup check that validates required variables are present.