nodejs/docker-node

Official Docker Image for Node.js :whale: :turtle: :rocket:

Node.js

The official Node.js docker image, made with love by the node community.

Table of Contents

• What is Node.js?
• How to use this image
  • Create a Dockerfile in your Node.js app project
  • Best Practices
  • Run a single Node.js script
  • Verbosity
    • Dockerfile
    • Docker Run
    • NPM run
• Image Variants
  • node:<version>
  • node:alpine
  • node:buster
  • node:bullseye
  • node:bookworm
  • node:slim
• License
• Supported Docker versions
• Supported Node.js versions
• Governance and Current Members
  • Docker Working Group Members
  • Docker Working Group Collaborators
  • Emeritus
    • Docker Working Group Members

What is Node.js?

Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

See: http://nodejs.org

How to use this image

Create a Dockerfile in your Node.js app project

# specify the node base image with your desired version node:<version>
FROM node:16
# replace this with your application's default port
EXPOSE 8888

You can then build and run the Docker image:

$ docker build -t my-nodejs-app .
$ docker run -it --rm --name my-running-app my-nodejs-app

If you prefer Docker Compose:

version: "2"
services:
  node:
    image: "node:8"
    user: "node"
    working_dir: /home/node/app
    environment:
      - NODE_ENV=production
    volumes:
      - ./:/home/node/app
    expose:
      - "8081"
    ports: # use if it is necessary to expose the container to the host machine
      - "8001:8001"
    command: "npm start"

You can then run using Docker Compose:

$ docker-compose up -d

Docker Compose example mounts your current directory (including node_modules) to the container. It assumes that your application has a file named package.json defining start script.

Best Practices

We have assembled a Best Practices Guide for those using these images on a daily basis.

Run a single Node.js script

For many simple, single file projects, you may find it inconvenient to write a complete Dockerfile. In such cases, you can run a Node.js script by using the Node.js Docker image directly:

$ docker run -it --rm --name my-running-script -v "$PWD":/usr/src/app -w /usr/src/app node:8 node your-daemon-or-script.js

Verbosity

Prior to 8.7.0 and 6.11.4, the docker images overrode the default npm log level from warn to info. However, due to improvements to npm and new Docker patterns (e.g. multi-stage builds) the working group reached a consensus to revert the log level to npm defaults. If you need more verbose output, please use one of the following methods to change the verbosity level.

Dockerfile

If you create your own Dockerfile which inherits from the node image, you can simply use ENV to override NPM_CONFIG_LOGLEVEL.

FROM node
ENV NPM_CONFIG_LOGLEVEL info
...

Docker Run

If you run the node image using docker run, you can use the -e flag to override NPM_CONFIG_LOGLEVEL.

$ docker run -e NPM_CONFIG_LOGLEVEL=info node ...

NPM run

If you are running npm commands, you can use --loglevel to control the verbosity of the output.

$ docker run node npm --loglevel=warn ...

Image Variants

The node images come in many flavors, each designed for a specific use case. All of the images contain pre-installed versions of node, npm, and yarn. For each supported architecture, the supported variants are different. In the file: versions.json, it lists all supported variants for all of the architectures that we support now.

node:<version>

This is the defacto image. If you are unsure about what your needs are, you probably want to use this one. It is designed to be used both as a throw away container (mount your source code and start the container to start your app), as well as the base to build other images off of. This tag is based off of buildpack-deps. buildpack-deps is designed for the average user of docker who has many images on their system. It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system.

node:alpine

This image is based on the popular Alpine Linux project, available in the alpine official image. Alpine Linux is much smaller than most distribution base images (~5MB), and thus leads to much slimmer images in general.

This variant is highly recommended when final image size being as small as possible is desired. The main caveat to note is that it does use musl libc instead of glibc and friends, so certain software might run into issues depending on the depth of their libc requirements. However, most software doesn't have an issue with this, so this variant is usually a very safe choice. See this Hacker News comment thread for more discussion of the issues that might arise and some pro/con comparisons of using Alpine-based images.

One common issue that may arise is a missing shared library required for use of process.dlopen. To add the missing shared libraries to your image:

• For Alpine v3.18 and earlier, adding the libc6-compat package in your Dockerfile is recommended: apk add --no-cache libc6-compat

• Starting from Alpine v3.19, you can use the gcompat package to add the missing shared libraries: apk add --no-cache gcompat

To minimize image size, it's uncommon for additional related tools (such as git or bash) to be included in Alpine-based images. Using this image as a base, add the things you need in your own Dockerfile (see the alpine image description for examples of how to install packages if you are unfamiliar).

To make the image size even smaller, you can bundle without npm/yarn.

node:buster

This image is based on version 10 of Debian, available in the debian official image.

node:bullseye

This image is based on version 11 of Debian, available in the debian official image.

node:bookworm

This image is based on version 12 of Debian, available in the debian official image.

node:slim

This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run node. Unless you are working in an environment where only the Node.js image will be deployed and you have space constraints, we highly recommend using the default image of this repository.

License

License information for the software contained in this image. License information for the Node.js Docker project.

Supported Docker versions

This image is officially supported on Docker version 1.9.1.

Support for older versions (down to 1.6) is provided on a best-effort basis.

Please see the Docker installation documentation for details on how to upgrade your Docker daemon.

Supported Node.js versions

This project will support Node.js versions as still under active support as per the Node.js release schedule.

Governance and Current Members

The Node.js Docker Image is governed by the Docker Working Group. See GOVERNANCE.md to learn more about the group's structure and CONTRIBUTING.md for guidance about the expectations for all contributors to this project.

Docker Working Group Members

• Hans Kristian Flaatten (starefossen)
• Hugues Malphettes (hmalphettes)
• John Mitchell (jlmitch5)

Docker Working Group Collaborators

• Mikeal Rogers (mikeal)
• Laurent Goderre (LaurentGoderre)
• Simen Bekkhus (SimenB)
• Peter Dave Hello (PeterDaveHello)

Emeritus

Docker Working Group Members

• Christopher Horrell (chorrell)
• Peter Petrov (pesho)

docker-node's Issues

Fix test-build.sh to work with on-build

The current test-build.sh script is a bit limited and fails when testing Onbuild images when node is updated. This happens because the Onbuild Dockerfile is trying to build from a node tag version that doesn't exist in the registry yet. So for instance, if we update the Docker files for node 0.12.3, the respective Onbuild Docekrfile will have FROM node:0.12.3.

Support December 2015 Security Releases

Node.js releases December 2015 security releases, https://nodejs.org/en/blog/vulnerability/december-2015-security-releases.

We'd like to see the builds for those releases.

onbuild fails on Windows due to node_modules and long filenames

I have an existing project that has been working on nodejs for Windows. I tried to build with the onbuild Docker image but I get a message eventually that it cannot 'stat' a file with a very long path - it is buried deep inside node_modules.

I suspect Windows (I am using version 7) cannot deal with the path due to file name length limitations, the very same reason the PHP composer dependency system cannot install Zend Framework 1 on Windows.

The solution is to document this as a known limitation, and the offer the idea that after building, the script should run 'npm install' within the container.

Potential security issue in sha256sum usage?

The use of sha256sum here seems problematic to me.

I assume the intent is to verify that the source tarball hasn't been tampered with, so checking against SHASUMS256.txt.asc makes sense.

But, both the tarball and SHASUMS256.txt.asc are downloaded on the fly from the web. That seems like an issue: If the source tarball had been compromised on the server, I'd assume that SHASUMS256.txt.asc would have been too.

Seems like it would be better to embed the known last-good contents of SHASUMS256.txt.asc directly in the Dockerfile and check against that. Am I missing something? (Honestly asking with no sarcasm, because I'm not a security guru and I'm a Docker newbie.)

Mongoose, Mongodb, Mockgoose, etc use kerberos 0.0.X and that requires libkrb5-dev

Hi my builds are failing because I cannot build kerberos on the docker image as libkrb5-dev is missing. I've collected this info while researching the issue, I'm not an expert on kerberos or anything like it.

Seems to be a pretty common library.

Add 4.0.0

Will need to test Node.js 4.0.0 RC-1 first (https://nodejs.org/download/rc/).

See nodejs/node#2522

“Error: The `libsass` binding was not found…” in 4.2.4-wheezy.

Hey,

I posted a question on stackoverflow regarding a problem I have with node-sass using the 4.2.4-wheezy image. I am wondering right now if this has something to do with the image itself as I am perfectly capable of building it on my machine running node 4.2.4 and on the 5.4.1-wheezy image on docker.

Question: Error running yeoman generator-meanjs

Hello I have the docker image.
I am running boot2docker on windows 8
I start it like this:
docker run -it -p 9000:3000 node ./bin/bash
It logs me in as root.

I install yeoman and generatormean into npm global
then I run 'yo meanjs'
I tried using the --unsafe-perm flag as mentioned in
#88

I get the following error:

Error: ECCES: permission denied, open 'root/.config/configstore/insight-yo.json'
You don't have access to this file.
at Error (native)
at Object.fs.openSync (fs.js:584:10)
/usr/local/lib/node_modules/yo/node_modules/configstore/index.js

I realise that this is not an error with this image, and my knowledge of docker,
linux, and npm is limited. I have picked up that I should not be logging in as
root, but I don't know how to startup this image with another user account.

switch to buildpack-deps-scm+gcc for the default variant

Now that we have more granular buildpack-deps, I'd like to discuss switching to buildpack-scm+gcc (and maybe later buildpack-gcc see docker-library/buildpack-deps#17) for the default variant.

The rational I'd like to defend here, is that user of the default image should never have to modify their Dockerfile in order to npm install self contained native dependencies that doesn't require a 3rd party library/headers, but that paying the tax of 400MB of C libraries (currently in buildpack-deps) you might not care about could be a hard price to pay (both for the first pull/push) for that "feature"

The :slim version is not really a good fit either, as figuring out the set of dependencies for build C extensions to add on top (after #2 was merged) is not necessarily well know of casual users.

It sounds like it could be useful to provide a more granular base image offering:

• FROM node node + what's necessary to build C deps + debian
• FROM node:buildpack node + popular C libraries + debian
• FROM node:slim node + busybox-opkg? or even SCRATCH? :)

What do you think?

/cc @tianon @automaticali

node:0 -> v4, node:4 -> doesn't exist

Looks like there's a bit of weirdness going on with the image tagging?

0.12: why upgrade to npm 3?

this breaks a bunch of things in my builds that use to work before, and there's no way to revert because you haven't versioned this change.

I'm seeing npm ERR! code EXDEV and npm WARN EBUNDLEOVERRIDE Replacing... messages that break my installation. when googling the first error, it seems the fix is to upgrade to node 4? why is this in a 0.12 Dockerfile then?

please either revert this change, or version it so we can choose npm v2 or npm v3. those of us on node 0.12 don't want breaking changes, please leave this to node 5.

Explain expose port with "run a single Node.js script"

I like the practice of running a single node script as described in the docs.

Run a single Node.js script
docker run -it --rm --name my-running-script -v "$PWD":/usr/src/myapp -w /usr/src/myapp node:0.10 node your-daemon-or-script.js

What I am missing in this example command line is the info how to expose the port. For beginners it would be great to mention external exposure via something like -p 80:3000 and internal exposure via something like --expose 3000 to be able to link it to other containers like nginx-proxy.

v5 on hub.docker.com

Hi,

Should v5 be on https://hub.docker.com/_/node/ by now?

I was expecting it to just appear as it's been officially released?

I'm not sure if every version will be on https://hub.docker.com/_/node/ so just asking here.

Thanks.

`npm install` uses wrong package

I have the following weird combination that leads to unexpected results.

I am running docker on Windows, and in my package.json there is a dependency to phantomjs which install a different executable depending on the environment is in: if it's on windows it downloads a windows executable, if it's on linux it downloads a linux executable. Apparently, the npm install command is run in my windows environment, or it caches the windows packages, Since if I enter the docker image bash and I ls into the node_modules phantomjs folder, I see the windows executable. If I do

rm node_modules -r
npm install

inside the docker container bash it installs the correct phantomjs executable. Is it true that the npm install run during docker build depends on the host environment and not the container environment? This could explain why, otherwise could be a caching problem... Can someone shed some light?

Global installs fail

When I run the container node:0.10 using

$ docker run -it node:0.10 bash

and then inside if the container run

# npm install -g pm2-web

I get an error message by node-gyp telling me that the user is undefined:

gyp WARN EACCES user "undefined" does not have permission to access the dev dir "/root/.node-gyp/0.10.36"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/usr/local/lib/node_modules/pm2-web/node_modules/mdns2/.node-gyp"

How do I fix that?

npm start failed

when I launch the container, it fails with message:

npm ERR! Linux 3.18.11-tinycore64
npm ERR! argv "node" "/usr/local/bin/npm" "start"
npm ERR! node v0.12.2
npm ERR! npm  v2.8.4
npm ERR! path /usr/src/app/package.json
npm ERR! code ENOENT
npm ERR! errno -2

npm ERR! enoent ENOENT, open '/usr/src/app/package.json'
npm ERR! enoent This is most likely not a problem with npm itself
npm ERR! enoent and is related to npm not being able to find a file.
npm ERR! enoent 

npm ERR! Please include the following file with any support request:
npm ERR!     /usr/src/app/npm-debug.log

It seems npm can not open package.json file.

Using npm 2.x

Hi,

I have an application that needs npm 2.x. Whenever I pull any of the node Docker images (even the older ones) I see that npm 3.x is used.

How can I pull an image and use npm 2.x?

Thanks!

Excessive npm log output in 4.x

When running NPM in the 4.x version of the docker image, the image runs with
ENV NPM_CONFIG_LOGLEVEL info
Is there any reason why this is not "warn" as is usually the default?

The log output is enough for Travis-CI to complain that the log output is too long.

Node 0.11.16 ignores SIGTERM when run inside Docker

Dockerfile:

FROM node:0.11.16
WORKDIR /app
COPY index.js /app/
CMD ["node", "index.js"]

index.js:

console.log('started');
process.stdin.resume();

This app will ignore TERM and INT signals, so it cannot be terminated using Ctrl+C or docker stop.

Other configurations that I have tested:

• Node.js v0.11.16 in Docker, built from source (Alpine Linux, musl-libc): doesn't exit;
• Node.js v0.11.16 in Mac OS X, outside of Docker: correctly exits;
• Node.js v0.10.36, both in Docker and on Mac OS X: correctly exits.

It appears that Node actually recieves and handles these signals, but for some reason doesn't perform the default action. This can be verified by adding signal listeners in index.js:

console.log('started');

exitOnSignal('SIGINT');
exitOnSignal('SIGTERM');
process.stdin.resume();

function exitOnSignal(signal) {
  process.on(signal, function() {
    console.log('\ncaught ' + signal + ', exiting');
    process.exit(1);
  });
}

It correctly prints Caught SIG{INT,TERM} and exits.

Switch to using xz compressed packages?

I noticed that there are xz packages available. For instances of v4.2.3 (via https://nodejs.org/dist/v4.2.3/)

node-v4.2.3-linux-x64.tar.gz                       03-Dec-2015 22:05            11683079
node-v4.2.3-linux-x64.tar.xz                       03-Dec-2015 22:05             8000024

We've been using the .gz package in all out Dockerfiles. Should we switch to xz? The download would be faster, but I'm not sure what affect it would have on the image build. My understanding of xz is that compression takes a while, but decompression is fast. I'll do a bit of testing this week and see how things play out.

Missing python in the slim versions

My npm install fails on 0.10-slim when i include the use of the idle-gc dependency.

> [email protected] install /app/node_modules/idle-gc
> node-gyp rebuild

gyp ERR! configure error 
gyp ERR! stack Error: Can't find Python executable "python", you can set the PYTHON env variable.
gyp ERR! stack     at failNoPython (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:103:14)
gyp ERR! stack     at /usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/configure.js:42:11
gyp ERR! stack     at F (/usr/local/lib/node_modules/npm/node_modules/which/which.js:40:25)
gyp ERR! stack     at E (/usr/local/lib/node_modules/npm/node_modules/which/which.js:43:29)
gyp ERR! stack     at /usr/local/lib/node_modules/npm/node_modules/which/which.js:54:16
gyp ERR! stack     at Object.oncomplete (fs.js:108:15)
gyp ERR! System Linux 3.16.0-31-generic
gyp ERR! command "node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /app/node_modules/idle-gc
gyp ERR! node -v v0.10.37
gyp ERR! node-gyp -v v1.0.2
gyp ERR! not ok 

Any change python could be added in the *-slim tagged images too?

5.1.0 is unpublished on Docker Hub

0.10 and 0.12 LTS and npm

With the upcoming LTS releases we need to rethink what we've been doing with npm.

For the Node.js 0.10 and 0.12 images we were updating the bundled version of npm to something more current (v3.x). For the LTS releases, I'm not sure if we should still be doing that and instead just stick with the bundled version of npm.

For the v0.10.41 LTS release there will be npm v1.4.29 which will show a deprecation banner every time npm is invoked encouraging people to update to v2.x. The v0.10.42 LTS release will come with npm v2.x. I think we should change the update logic for v0.10.41 LTS so npm is updated to the latest npm v2.x release, then remove it for v0.10.42

For 0.12, we can remove logic that updates npm from the respective docker files entirely for the upcoming LTS release (I'm assuming 0.12.8?). However, I don't know whether the LTS release of 0.12 will come with npm v2.x or v.3.x.

Actually, the more that I think about it maybe we should just leave things as is? From a docker experience, it's probably better to have the latest version of npm with the latest fixes and security patches etc.

Anyway, I wanted to put this out there for broader discussion.

For reference: nodejs/Release#37

npm install --production

Hi,

I have submitted this in multiple repo's now but got redirected to this one.
dockerfile/nodejs-runtime#1
GoogleCloudPlatform/nodejs-docker#27
My thoughts on the npm install command used:

---

I think you actually want to run npm install --production instead of npm install. This decreases the size of projects that use separate dependencies and devDependencies in the package.json. This is pretty common. I think the majority of the people want to actually run it with the --production flag but they do not know about it. I think this is a better default and people that for some reason want to build the docker image with devDependencies can use a workaround.

What is the best way to work around this? Can you overwrite certain commands or should you use your own docker file by copy pasting this one?

Thanks for the help!

slim-onbuild tag

Would be great to have a tag with a combination of slim and onbuild tags to save space.

I did it manually on maildev/maildev#102 and it works perfectly.

Include .npmrc for onbuild version

I ran into an issue where I needed to set unsafe-perm=true when using node:0.12-onbuild but I couldn't get the setting to take using "config": { "unsafe-perm": true } in package.json. It would be nice if .npmrc is also copied over when package.json is copied so we could configure npm before npm install. I know we can always break glass and not use the -onbuild version but it's convenient to use (can write my Dockerfile from memory without having to lookup the base to copy/paste).

So in short, could we change:

ONBUILD COPY package.json /usr/src/app/

to:

ONBUILD COPY package.json .npmrc /usr/src/app/

Shouldn't be running node as root?

Apologies if this is a FAQ, my Google-fu didn't turn up any answers.

Isn't it a bad idea that we're running node as the root user by default? I'm currently crafting Dockerfiles for my company's products and am curious about what the best practice is for this issue.

When will official node image repo bump to 0.12.6?

Can I ask what the timeline is for bumping the official Docker node image to v0.12.6? This repo bumped two nights ago, but the image is still stuck at 0.12.5...

(Sorry if this is an annoying question — I just couldn't find any info anywhere on what the official process is for incorporating changes in the underlying git repos into the official Docker builds. And given that the 'net is frothing with you-must-upgrade-to-0.12.6 warnings, there are a lot of people waiting for the official repo to bump...)

Thanks in advance.

NPM is 2.14 not 3.5.2 (using node:4.2-wheezy image)

NPM install fails for me, and it is reporting that the version is: 2.14.12, I believe this fixed in later versions of NPM but I am confused as to why I'm even using npm 2.

Step 0 : FROM node:4.2-wheezy
 ---> 005063d24086
Step 1 : RUN npm install --global gulp
 ---> Running in 68159de6a2fc
npm info it worked if it ends with ok
npm info using [email protected]
npm info using [email protected]
npm info addNameTag [ 'gulp', 'latest' ]
npm info attempt registry request try #1 at 12:18:56 PM
npm http request GET https://registry.npmjs.org/gulp
npm info retry will retry, error on last attempt: Error: self signed certificate

LTS tag

Would it be helpful to add an LTS tag in addition to the latest?

5.x

5.x images are not seem to be in docker hub, even though there are Dockerfiles here. Any ETA?

Thanks.

EOL node 0.8 ?

I'm going on the assumption that 0.8.* will no longer be supported at some point (unless that's the case already). We should eventually remove the 0.8 tag. I'd like to get some Clarification from the LTS working group.

Security issue: node is run as root

In case of security flaw in the application run and in docker.
cf:
http://blog.zeltser.com/post/104976675349/security-risks-and-benefits-of-docker-application
http://thenewstack.io/docker-addresses-more-security-issues-and-outlines-plugin-approach/
http://www.slideshare.net/jpetazzo/docker-linux-containers-lxc-and-security
https://blog.xenproject.org/2014/06/23/the-docker-exploit-and-the-security-of-containers/

Deployment best practices

Hi there! I hope this issue can help me and other coming here with a similar problem:

I'm planning to deploy a container based on this image in production behind an https load balancer.

Would a simple npm start --production for an express app.listen(... be enough for production use? Or should something more be done to enhance security/throughput of the service.

Thanks! 🍬

Update official-images per org change.

I'm assuming we will need to do a pull request to https://github.com/docker-library/official-images to reflect the GitHub org change to nodejs from joyent.

Merge commit history from previous repo

As noted in the comments of #3, figure out how to merge the commit history from the previous repo: https://github.com/docker-library/node

onbuild does not work with npm-shrinkwrap.json

npm installs packages from a npm-shrinkwrap.json if one exists. They way in which the Dockerfile for onbuild is structured, npm will never install from npm-shrinkwrap.json.

https://github.com/nodejs/docker-node/blob/master/0.12/onbuild/Dockerfile#L6

SHASUMs via HTTPS?

Hi!
Shouldn't we be pulling the SHASUMs via HTTPS? Everything else feels like a substantial security issue to me which would make the checksum tests basically pointless.
Hope someone can proof me wrong :-)
Cheers

4.1 tags missing

According to https://hub.docker.com/_/node/, there should be some 4.1 tags, but https://hub.docker.com/r/library/node/tags/ doesn't list any and trying to pull node:4.1.0 fails with Tag 4.1.0 not found in repository docker.io/library/node.

Move to the nodejs GitHub organization and combine efforts with nodejs/docker team?

Hey @chorrell, since we are in the process of combining Node.js and io.js efforts under the foundation in the new http://github.com/nodejs/ organization and have been gradually moving relevant repositories there and combining the efforts of the various working groups. Could we also plan for a move of this repository under the same organization and combine the great work you've been putting in here with the existing @nodejs/docker working group that also takes care of the official io.js Docker images @ https://github.com/nodejs/docker-iojs?

I hear great feedback about the way this project is run from people who are using it and it'd be great to be able to combine the effort and energy that are put in here and in docker-iojs under the same umbrella to set us up for when the converged work begins releasing (likely within a couple of months).

Perhaps as a start we could add yourself and anyone else who is responsible for maintaining this repository to the @nodejs/docker group and get some communication started around how you can converge your efforts as we've been doing across other groups.

Add basic tests

Test image builds, and ideally, basic commands. Ideally this help us catch issues before making a pull request to the official image repo.

A recent example of where we got burned by this: docker-library/official-images/pull/630

Not executing script for CRLF

Not sure if this is the right forum to post this or the official Docker forum but here it is.

My script doesn't seem to be running (using Windows) when my script line endings are CRLF.

_docker-compose.yml_

web:
  image: node:4
  volumes:
    - ..:/usr/src/app
  working_dir: /usr/src/app
  command: sh ./init.sh

_init.sh_ (line-ending as CRLF)

#!/bin/bash

# npm install some-packages

npm start

I had to convert the line endings to LF for the container to successfully execute the script

Question: Why is node-slim not recommended?

The readme at the Docker hub notes about the slim package:

node:slim
This image does not contain the common packages contained in the default tag and only contains the minimal packages needed to run node. Unless you are working in an environment where only the node image will be deployed and you have space constraints, we highly recommend using the default image of this repository.

But when looking at the Dockerfile 0.10 slim it seems that it is perfectly suitable for runtime.

• Why is it does the readme recommend the default image?
• What runtime usecases would the slim package not be suitable for?

Note: Although Docker does a great deal of caching layers we like to promote smaller images since we see a lot of layer pushing around dev and production workflows.

Where's Christopher?

Hi @nodejs/docker ,

I'm going to be unavailable for a week or so to deal with some personal matters. I wanted to let everyone know in light of https://nodejs.org/en/blog/vulnerability/openssl-and-low-severity-fixes-jan-2016/ as I most likely won't be able to handle the updates for 0.10.x and 0.12.x :(

Also, apologies for the extraneous issue here. I wasn't sure what the best way was to keep everyone informed...

Discourage use of the onbuild image for production use

While the onbuild variant is really useful for "getting off the ground running" (zero to Dockerized in a short period of time), it's not recommended for long-term usage within a project due to the lack of control over when the ONBUILD triggers fire (see also moby/moby#5714, moby/moby#8240, moby/moby#11917).

We should backport the enhanced description of the onbuild image variant which used in the documentation of the Node.js Docker Image in the Docker Registry to this repository: https://github.com/docker-library/docs/tree/master/node#nodeonbuild

'lstat package.json: no such file or directory' using node:onbuild

I'm using Docker v1.9.1, here is my Dockerfile:

FROM node:onbuild

EXPOSE  8080

Calling docker build -t my_app .

gives me this output:

Step 1 : FROM node:onbuild
# Executing 3 build triggers...
Step 1 : COPY package.json /usr/src/app/
lstat package.json: no such file or directory

Add an Alpine variant?

Having an Alpine variant would be useful.

This primarily depends on nodejs/build#75 though

/usr/src/app not writable when host is fedora 22

I've created a simple example to illustrate the issue.

https://github.com/airtonix/fedora-22-docker-write-access-problem

tl;dr :

Creating dockerfedora22writetest_test_1...
Attaching to dockerfedora22writetest_test_1
test_1 | Error: EACCES, scandir '/usr/src/app'
test_1 |     at Error (native)
test_1 | 
test_1 | Error: EACCES, open 'npm-debug.log.7da2e9feb6af80ea1c45d89105a542fd'
test_1 |     at Error (native)
test_1 | 
dockerfedora22writetest_test_1 exited with code 0
Gracefully stopping... (press Ctrl+C again to force)

Create a minimal variant?

A few months ago I was at DockerCon and @proppy asked if it was possible to statically compile Node.js and use the resulting binary to create a very small Docker image with just Node.js. I'm in SF this week and during a hack-a-thon at Joyent I put that out there and it turns out it's pretty easy:

https://hub.docker.com/r/joshwilsdon/nodejs/

I took the above and put together a rough build process/proof-of-concept:

https://hub.docker.com/r/chorrell/node-minimal/

I think this would be an interesting variant we could provide. It would require a some doc on how to use it and how to use it as a base for other images.

Working Directory error in install/postinstall scripts

I get this error when trying to run the postinstall or install parts of my package with npm install in the GitLab CI runner using Docker and node:4:

npm WARN cannot run in wd [email protected] node ./node_modules/bower/bin/bower i (wd=/builds/author/my-package)

Is this a permissions issue?