elastic-beanstalk-deployment

AWS Elastic Beanstalk automates Node.js application deployment but has specific behaviors around dependency installation that can cause issues, especially with monorepos. Understanding when EB installs dependencies vs when it skips installation is critical for successful deployments.

Core principle: Choose between letting EB install dependencies (smaller packages, slower) or bundling node_modules (larger packages, more reliable).

Use when:

• Deploying Node.js applications to AWS Elastic Beanstalk
• Encountering "Cannot find package" errors during deployment
• Working with monorepo workspace packages
• Need reliable deployments without npm registry dependencies
• Deploying applications with private packages

Don't use for:

• Non-AWS deployments
• Docker-based deployments (different dependency strategy)
• Simple apps with only public npm packages (standard approach works fine)

Reference: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/nodejs-platform-dependencies.html

| Condition | EB Action | npm Command |

|-----------|-----------|-------------|

| package.json exists, NO node_modules/ | Installs dependencies | npm install --omit=dev (npm 7+) |

| node_modules/ directory present | Skips installation | None - uses bundled modules |

Strategy 1: Let EB Install Dependencies (Standard)

Best for: Simple apps, all packages in npm registry, no monorepo

```yaml

# GitHub Actions workflow

• name: Build application

run: npm run build

• name: Create deployment package

run: |

zip -r app.zip \

dist/ \

package.json \

package-lock.json \

.ebextensions/

```

Pros:

• Smaller deployment packages (5-10MB typical)
• Consistent with npm ecosystem
• Uses platform's npm version

Cons:

• Slower deployments (installs on every deploy)
• Requires all packages in npm registry
• Can fail with network/registry issues

Strategy 2: Bundle node_modules (AWS Recommended for Special Cases)

Best for: Monorepos, private packages, reliability requirements

AWS official quote: "Bundle node_modules to bypass potential npm registry installation issues."

```yaml

# GitHub Actions workflow

• name: Install production dependencies

run: npm install --omit=dev

• name: Create deployment package

run: |

zip -r app.zip \

dist/ \

package.json \

node_modules/ \

.ebextensions/

```

Pros:

• Bypasses npm registry issues
• Faster deployments (no install phase)
• Works with workspace packages
• Reliable and predictable

Cons:

• Larger packages (50-100MB typical)
• Must ensure platform-compatible binaries

The Problem

Running npm ci --production inside a monorepo workspace:

• Creates symlinks to workspace packages (not actual files)
• Results in incomplete node_modules (~3MB instead of ~50MB)
• Causes "Cannot find package" errors during EB deployment

Example error:

```

Error: Cannot find module '@prpm/types'

```

The Solution: Clean Context Installation

Install dependencies outside the workspace context to get real files instead of symlinks:

```yaml

• name: Create standalone package.json

run: |

mkdir -p /tmp/clean-install

cd /tmp/clean-install

# Copy package.json and replace workspace refs with file paths

cp $GITHUB_WORKSPACE/packages/app/package.json .

jq --arg workspace "$GITHUB_WORKSPACE" \

'.dependencies["@workspace/pkg"] = "file:\($workspace)/packages/pkg"' \

package.json > package.json.tmp

mv package.json.tmp package.json

• name: Install dependencies (outside workspace)

run: |

cd /tmp/clean-install

npm install --omit=dev --legacy-peer-deps

# Verify critical packages (real directories, not symlinks)

test -d node_modules/pg || exit 1

test -d node_modules/@workspace/pkg/dist || exit 1

• name: Copy to deployment location

run: |

rm -rf packages/app/node_modules

cp -r /tmp/clean-install/node_modules packages/app/

```

Key steps:

1. Install outside workspace context
2. Convert workspace dependencies to file: references
3. Verify packages are real directories (not symlinks)
4. Bundle complete node_modules in deployment

Override Production Install Mode

Set in Beanstalk console:

```

NPM_USE_PRODUCTION=false

```

Specify Node.js Version

In package.json:

```json

{

"engines": {

"node": "20.x"

}

}

```

Note: Version range feature not available on Amazon Linux 2023

When bundling node_modules, migrations can run immediately:

```yaml

# .ebextensions/migrations.config

container_commands:

01_run_migrations:

command: npm run migrate

leader_only: true

```

Why this works with bundled approach:

1. EB extracts deployment to /var/app/staging/
2. node_modules/ already present (bundled)
3. EB skips npm install step
4. Migrations run with all dependencies available

Issue: "Cannot find package 'X'"

Symptoms:

```

Error: Cannot find module 'pg'

Error: Cannot find module '@prpm/types'

```

Cause: Package not installed or symlinked

Solution:

```bash

# Verify package exists as real directory

ls -la node_modules/pg

file node_modules/@prpm/types # Should show "directory", not "symbolic link"

# If symlink, use clean context installation (see above)

```

Issue: "npm install fails with workspace package not found"

Symptoms:

```

npm ERR! Could not resolve dependency: @workspace/package

```

Cause: Workspace package not in npm registry

Solution: Use bundled node_modules approach with clean context installation

Issue: Binary compatibility errors

Symptoms:

```

Error: The module was compiled against a different Node.js version

```

Cause: Native modules compiled for macOS/Windows, deployed to Linux

Solution:

• Install dependencies in Linux environment (Docker, GitHub Actions with ubuntu-latest)
• Or use --platform=linux flag for specific packages

Issue: Deployment package too large (>500MB)

Cause: Dev dependencies or unnecessary files included

Solution:

```bash

# Use --omit=dev flag

npm install --omit=dev

# Exclude unnecessary files

zip -r app.zip dist/ package.json node_modules/ .ebextensions/ \

-x ".cache/" ".test.js" ".spec.js"

# Use .ebignore file

echo "*.test.js" >> .ebignore

echo "*.spec.js" >> .ebignore

```

Before deploying, always verify:

```bash

# 1. Check node_modules size (should be 50MB+ for typical apps)

du -sh node_modules

# Expected: 50M-100M (if bundled)

# Red flag: 3M-5M (likely symlinks)

# 2. Verify critical packages exist

ls -la node_modules/pg

ls -la node_modules/fastify

ls -la node_modules/@your-workspace/package

# 3. Check for symlinks (should see real directories)

file node_modules/@your-workspace/package

# Expected: "directory"

# Red flag: "symbolic link to ../../packages/your-package"

# 4. Verify dist directories for workspace packages

test -d node_modules/@your-workspace/package/dist || echo "ERROR: dist missing"

# 5. Test the deployment package locally

unzip -q app.zip -d /tmp/test-deploy

cd /tmp/test-deploy

node dist/index.js # Should start without errors

```

1. Always Include package-lock.json

✅ Do: Include package-lock.json for reproducible builds

```yaml

zip -r app.zip dist/ package.json package-lock.json node_modules/

```

❌ Don't: Omit lock file or use only package.json

2. Verify Deployment Package

```bash

# Inspect before uploading

unzip -l app.zip | grep node_modules | head -20

# Check size

ls -lh app.zip

# Should be: 50-100MB (bundled) or 5-10MB (unbundled)

```

3. Test Locally First

```bash

# Extract and test the exact deployment package

unzip app.zip -d /tmp/deployment-test

cd /tmp/deployment-test

npm start # Should work without any npm install

```

4. Monitor First Deployment

When switching from unbundled to bundled (or vice versa):

• Watch EB console logs carefully
• Verify application starts successfully
• Check for dependency-related errors
• Have rollback plan ready

5. Keep Deployment Packages

Save successful deployment packages for rollback:

```bash

aws s3 cp app.zip s3://my-bucket/deployments/app-$(date +%Y%m%d-%H%M%S).zip

```

```

Does your app use monorepo workspace packages?

├─ Yes → Use bundled node_modules (Strategy 2)

│ └─ Install in clean context (outside workspace)

└─ No → Do you need maximum reliability?

├─ Yes → Use bundled node_modules (Strategy 2)

│ └─ Faster deploys, no registry issues

└─ No → Are all packages in public npm registry?

├─ Yes → Let EB install (Strategy 1)

│ └─ Smaller packages, standard approach

└─ No (private packages) → Use bundled node_modules (Strategy 2)

```

This project uses bundled node_modules approach because:

• @prpm/types is a workspace package (not in npm registry)
• Requires reliable deployments without registry dependencies
• Migrations need pg package available immediately
• Speed and predictability are critical

See .github/workflows/deploy-registry.yml for full implementation.

• [AWS EB Node.js Platform](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/nodejs-platform-dependencies.html)
• [npm workspaces documentation](https://docs.npmjs.com/cli/v8/using-npm/workspaces)
• [Elastic Beanstalk container commands](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html#linux-container-commands)