Meteor 3.4

Apply the Node.js 22 prompt first. Review the Meteor 3.4 server methods, publications, collections, Accounts flows, WebApp routes, and optional Rspack build as separate trust boundaries.

Deployment and build

• Check the Node binary in the deployed Meteor bundle, not only the tool's meteor node -v or the image label. If its bundled runtime lacks an upstream security fix, use a compatible patched runtime for deployment and test native dependencies and the resulting bundle.
• The MongoDB startup compatibility probe on this line can ignore TLS certificate validity and print a malformed MONGO_URL with credentials. Validate MONGO_URL before startup, restrict MongoDB destinations, protect startup stderr, and rotate credentials found in logs. The application's main MongoDB connection settings do not fix the probe.
• Set a trusted HTTPS ROOT_URL, private MONGO_URL and METEOR_SETTINGS, and a restricted BIND_IP. At the proxy, remove untrusted forwarding headers and set HTTP_FORWARDED_COUNT to the actual trusted hop count so DDP address limits and request security detection use the correct client.
• Keep server code and secrets out of shared imports, public/, Meteor.settings.public, client source maps, and rendered bootstrap data. Audit the production build, including code-split chunks, rather than trusting Meteor.isServer branches inside client-reachable modules.
• If using the rspack Atmosphere package, review rspack.config.js and its imported plugins as executable build code. Keep client and server entry points distinct; inspect generated