Hey there, let's dig into why your GitLab CI build is failing at the Running npm install in the server bundle... step when your local Docker build works perfectly. I’ve tackled similar issues with meteor-launchpad and Meteor apps in CI environments, so here are the most common fixes to try:

1. Fix Node.js/NPM Version Mismatch #

Meteor 1.6.1 is tied to Node.js 8.11.4 and a specific NPM version—if GitLab’s shared runner uses a different version, it can break dependency installation. Local builds use your machine’s compatible version, but CI starts fresh each time.

Solution:
Lock in the correct Node version in your .gitlab-ci.yml using nvm:

before_script:
  - curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
  - source ~/.bashrc
  - nvm install 8.11.4
  - nvm use 8.11.4

Alternatively, use a Docker base image that already includes Node 8.11.4 to avoid version conflicts entirely.

2. Add Dependency Caching #

Local builds cache node_modules and Meteor packages, but GitLab CI runs in a clean environment by default. Reinstalling dependencies every time slows builds and increases the chance of network-related failures.

Solution:
Configure GitLab CI to cache critical directories:

cache:
  paths:
    - .meteor/local/build/programs/server/node_modules/
    - .meteor/packages/
    - node_modules/
  key: "$CI_COMMIT_REF_SLUG"

Make sure you’ve committed your package-lock.json or yarn.lock file to Git—this helps the cache work reliably and avoids unexpected dependency version changes.

3. Resolve Permission Issues #

GitLab’s shared runner runs as a non-root user by default, which can cause permission errors when npm tries to write to system directories or create node_modules.

Solution:
Tell npm to use a user-writable cache directory before installing dependencies:

npm config set cache ~/.npm-cache --global
npm install --cache ~/.npm-cache

If you’re building with Docker, you can also adjust permissions in your Dockerfile (e.g., create a non-root user and set directory ownership) to match the runner’s environment.

4. Check Network Restrictions #

Shared runners might have network limitations that your local machine doesn’t—like blocked access to the npm registry or Meteor’s package servers. This leads to failed dependency downloads.

Solution:

• Switch to a more reliable npm registry (e.g., a regional mirror) in your CI script:

  npm config set registry https://registry.npmmirror.com/
  

• If you’re using a self-hosted GitLab runner, verify it has access to external networks or configure a proxy if needed. For GitLab’s official runners, network issues are rare but can happen—try re-running the build first.

5. Match Local Build Arguments to CI #

If you use --build-arg flags in your local Docker build (e.g., passing Meteor settings), missing these in CI can cause the npm install step to fail silently or with cryptic errors.

Solution:
Mirror your local Docker build command in .gitlab-ci.yml. For example, if you run:

docker build --build-arg METEOR_SETTINGS=$(cat settings.json) .

Add the same build arg to your CI step:

build:
  script:
    - docker build --build-arg METEOR_SETTINGS=$(cat settings.json) -t $IMAGE_NAME .

Debugging Tips #

If none of the above work, add debug steps to your CI script to get more context:

# Print version info
node --version
npm --version

# Show directory structure and permissions
ls -la .meteor/local/build/programs/server/

# Run npm install with verbose logging to see exact failures
npm install --verbose

This will reveal if a specific package is failing to install, if permissions are blocked, or if network requests are timing out.

内容的提问来源于stack exchange，提问作者Jim Theorell