Introduction

Elastic Beanstalk’s Node.js platform historically defaults to npm-oriented behavior, but many teams want Yarn for deterministic installs and lockfile alignment. The practical solution is to make the deployment environment install dependencies with Yarn explicitly, using platform hooks or configuration files that match the current Beanstalk platform generation.

Start with a Clear Yarn-Based Project Layout

If the application is supposed to use Yarn, the repository should reflect that clearly:

• 'package.json'
• 'yarn.lock'
• no conflicting package-manager assumptions in deployment scripts

At minimum, local and CI installs should already succeed with:

yarn install --frozen-lockfile
yarn build

If the app still depends on npm conventions locally, fixing Elastic Beanstalk first is the wrong layer.

Use Platform Hooks on Modern Elastic Beanstalk

On Amazon Linux 2 based Node.js platforms, .platform/hooks is the cleanest way to customize install behavior. For example, you can run Yarn during the prebuild phase.

1#!/bin/bash
2set -euo pipefail
3
4cd /var/app/staging
5
6if ! command -v yarn >/dev/null 2>&1; then
7  npm install -g yarn
8fi
9
10yarn install --frozen-lockfile

Save that as:

.platform/hooks/prebuild/10_use_yarn.sh

Make it executable:

chmod +x .platform/hooks/prebuild/10_use_yarn.sh

This approach works because Beanstalk executes the hook as part of the deployment lifecycle before the app is finalized.

Older Platforms Often Use .ebextensions

If you are on an older Beanstalk platform generation, .ebextensions may still be the customization path. A common pattern is to install Yarn and then run it through container_commands.

1packages:
2  yum:
3    nodejs: []
4
5commands:
6  01_install_yarn:
7    command: "npm install -g yarn"
8
9container_commands:
10  01_yarn_install:
11    command: "yarn install --frozen-lockfile"

Put that in a file such as:

.ebextensions/use-yarn.config

The exact mechanism depends on the platform version, which is why checking the current Beanstalk documentation for your stack version matters.

Keep the Build and Start Commands Consistent

Using Yarn for dependency installation but leaving the rest of the platform confused about startup scripts leads to brittle deployments. Make the application lifecycle explicit in package.json.

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

Then ensure your hook or config runs the right commands:

yarn install --frozen-lockfile
yarn build

That keeps Elastic Beanstalk from silently falling back to an npm-oriented assumption later in the deploy.

Treat yarn.lock as the Source of Truth

The whole reason to use Yarn in deployment is usually reproducibility. That only works if the deployment actually respects the lockfile.

Use:

yarn install --frozen-lockfile

instead of plain yarn install when you want deploys to fail on dependency drift rather than silently rewrite the dependency graph.

If the repo still carries package-lock.json and yarn.lock, choose one package manager and remove the conflicting lockfile. Mixed lockfiles make production dependency behavior harder to predict.

Common Pitfalls

• Installing Yarn but still letting the platform perform the real dependency installation with npm defeats the point of the customization.
• Keeping both package-lock.json and yarn.lock creates ambiguity about which dependency graph is authoritative.
• Using yarn install without --frozen-lockfile allows drift between local, CI, and Beanstalk installs.
• Applying .ebextensions instructions to a modern platform that expects .platform/hooks leads to configuration that looks correct but is never executed.
• Fixing Beanstalk first when the application itself is not consistently Yarn-based locally makes the deployment symptoms misleading.

Summary

• Make the project consistently Yarn-based before customizing Elastic Beanstalk.
• Use .platform/hooks on modern Node.js Beanstalk platforms and .ebextensions only where the platform still expects it.
• Install dependencies with yarn install --frozen-lockfile so the lockfile stays authoritative.
• Keep build and start commands explicit and package-manager consistent.
• Verify the hook mechanism against the actual Elastic Beanstalk platform generation you are deploying.