Introduction

On Amazon Elastic Beanstalk, Node.js and npm are often available through platform-managed paths rather than the exact directories developers expect from a local machine. The real problem is usually not that the tools are “missing,” but that deployment scripts hardcode assumptions about where they live. The safest Elastic Beanstalk strategy is to rely on the environment’s PATH, platform hooks, and runtime discovery instead of baking absolute Node or npm paths into scripts.

Why the Paths Look Different

Elastic Beanstalk manages language runtimes for you. Depending on platform generation and solution stack, Node.js may be installed under Elastic Beanstalk-managed directories rather than under the most familiar local development locations.

That means scripts like this are fragile:

/usr/local/bin/node app.js
/usr/local/bin/npm install

Those paths may work locally and fail on Beanstalk even though node and npm are available.

Prefer Runtime Discovery

The first thing to do on a live environment is ask the shell what it actually sees:

1which node
2which npm
3node --version
4npm --version

If you are writing hook scripts or troubleshooting an instance, these commands tell you more than guesswork based on an old blog post.

In shell scripts, prefer:

#!/usr/bin/env bash
node --version
npm --version

And for executable scripts:

#!/usr/bin/env node
console.log(process.version);

This uses the active environment resolution rather than hardcoding one directory.

Use Elastic Beanstalk Platform Hooks

When you need custom setup on Beanstalk, platform hooks are the right integration point. For example, on Amazon Linux 2 platforms you can place scripts under .platform/hooks/.

Example hook:

1#!/usr/bin/env bash
2set -euo pipefail
3
4echo "Node path: $(which node)"
5echo "npm path: $(which npm)"
6node --version
7npm --version

This is far more maintainable than calling one guessed path from an ad hoc deployment command.

Update PATH Only When Necessary

Sometimes a custom script runs in a stripped-down environment and cannot see the expected runtime. In that case, update PATH in one place rather than rewriting every command to use absolute paths.

export PATH="$PATH:/opt/elasticbeanstalk/node-install/nodejs/bin"
node --version
npm --version

But treat this as an environment fix, not as a general recommendation to hardcode that exact directory forever. Platform versions can change runtime layout.

Application Scripts Should Avoid Absolute Runtime Paths

In package.json, deployment scripts should normally assume node and npm are discoverable from the environment:

1{
2  "scripts": {
3    "start": "node server.js",
4    "build": "npm run lint && node build.js"
5  }
6}

This keeps the project portable across:

• local development,
• CI,
• containers,
• Elastic Beanstalk.

Absolute runtime paths make the app less portable for little gain.

Debugging a Real Deployment

If a deployment fails because a hook script cannot find npm, check:

1. the script interpreter line,
2. executable permissions,
3. the effective PATH,
4. platform generation and runtime version,
5. whether the command is running as the user you expect.

A script may succeed in an interactive SSH session and fail in a deployment hook because the shell environment is different. That usually explains the discrepancy better than “Elastic Beanstalk installed Node incorrectly.”

Good Operational Rule

Use platform-managed runtimes as discovered services, not as memorized file paths. If a specific path must be referenced for one environment, isolate that into one configuration point and document why it exists.

The more often a repo says “Node is always exactly here,” the more likely it is to break during a platform upgrade.

Common Pitfalls

• Hardcoding local-machine Node or npm paths into Elastic Beanstalk deployment scripts.
• Assuming one blog post’s Elastic Beanstalk runtime path is stable across platform generations.
• Debugging application code before checking whether the deployment hook environment has the expected PATH.
• Writing scripts that call /usr/local/bin/node when #!/usr/bin/env node would be more portable.
• Fixing each failing script individually instead of centralizing environment-path handling where needed.

Summary

• On Elastic Beanstalk, Node.js and npm may live in platform-managed locations that differ from local expectations.
• Prefer which node, which npm, and the shell PATH over hardcoded absolute paths.
• Use platform hooks for environment-aware deployment logic.
• Update PATH centrally only when necessary, and avoid encoding one platform-specific runtime path throughout the repo.
• Portable scripts should rely on runtime discovery, not on fixed installation directories.