docker-python-nodejs is a Python and Node.js image with a wide tag matrix

One container holding two toolchains

The repository does something narrow and useful: it assembles a container image that contains a working Python installation and a working Node.js installation at the same time. The typical consumer is a build that mixes the two, such as a Python service that shells out to a Node tool during the build, or a data pipeline that has a JavaScript front end bundle and a Python backend in the same stage. The alternative for most people is writing your own Dockerfile, installing the two runtimes, and then rediscovering the same problems around apt packages, corepack, poetry and pipenv every time you start a new project. The image also carries the Python package tooling that modern projects expect, since the current latest tag lists npm 10.x, yarn stable, pip, pipenv, poetry and uv alongside Node.js 22.x and the latest Python. The description calls it a Python with Node.js docker image, and the README notes it was last updated by bot on 2026-10-15, which tells you immediately that the tags move on their own schedule rather than with a human release.

The tag matrix and the four base distributions

Tag naming follows a fixed pattern, so you can pick a combination rather than accepting whatever the latest tag holds. A tag reads as the Python version, the Node.js version and an optional distribution suffix, for example `python3.13-nodejs24-bookworm`. Across the matrix the Python versions run from 3.11 through 3.15, and the Node.js versions are 22, 24 and 26. Four distributions are offered for each combination: the default trixie base, bookworm, slim, and alpine. That gives a large number of tags, and they are pinned to exact patch versions in the table rather than floating, so `python3.13-nodejs22` maps to Python 3.13.16 and Node.js 22.23.3 on trixie. The README states that these tags are kept updated automatically when new minor or patch versions are released, and that the Python script in `src/docker_python_nodejs` handling this runs twice a day on GitHub actions. The practical effect is that a tag you pin today keeps receiving patch updates without you doing anything, which is convenient until it is not, since a rebuild months later can pick up a new base image underneath your application.

Which upstream versions are still supported

The repository publishes a support window table for both runtimes, and it is more informative than the tag list. Python 3.15 runs from 2026-10-09 to 2031-10, 3.14 from 2025-10-07 to 2030-10, 3.13 from 2024-10-07 to 2029-10, 3.12 from 2023-10-02 to 2028-10, and 3.11 from 2022-10-24 to 2027-10. Node.js v26 runs from 2026-05-05 to 2029-04-30, v24 from 2025-05-06 to 2028-04-30, and v22 from 2024-04-24 to 2027-04-30. Those end dates tell you when a tag will stop being rebuilt, which matters for a long-lived service that pins an old runtime: the tag you chose today will eventually fall out of the supported set. The README also says where the numbers come from. For Python the maintainer scrapes the supported versions table at devguide.python.org/versions, and for Node.js the release schedule JSON is fetched from the nodejs/Release repository, and the versions are kept up to date using those official sources.

Pulling, building and running the image

The typical tasks section gives the three commands you need.

# Pull from Docker Hub
docker pull nikolaik/python-nodejs:latest
# Build from GitHub
docker build -t nikolaik/python-nodejs github.com/nikolaik/docker-python-nodejs
# Run image
docker run -it nikolaik/python-nodejs bash

The first pulls the published image, the second builds it from the repository source, and the third opens a shell inside it. The README also notes that image tags are built for the linux/amd64 and linux/arm64 platforms, with the exception of alpine, which is only built for linux/amd64, and it points at issue 70 for details of that limitation. That is the first thing to check if you build on Apple silicon, because an alpine-based build of a Python service is a common pairing and it will not have an arm64 variant here.

Using it as a base image with a non-root user

The documented base image pattern switches to a dedicated user and a working directory.

FROM nikolaik/python-nodejs:latest

USER pn
WORKDIR /home/pn/app

All images have a default user `pn` with uid 1000 and gid 1000, so the container does not run as root by default and the uid is the conventional one, which avoids the permission problems that appear when a volume mounted from the host is owned by a different uid. The Dockerfile at the repository root shows where that user comes from. It starts from the python:trixie base, creates the group and the user with the explicit uid and gid, sets POETRY_HOME to /usr/local, and then installs the Node.js tarball, npm with corepack and yarn enabled through corepack, and the Python tooling.

RUN npm install -g corepack && corepack enable yarn

The Node.js install is worth reading rather than trusting. The build fetches the latest release checksum list from nodejs.org, works out the architecture from dpkg, receives the Node.js signing keys from the docker-node repository, downloads the tarball and its signed checksum file, verifies the signature with gpg, checks the sha256 sum against the published list, and only then unpacks it into /usr/local with a symlink from nodejs to node. The install step for the Python side then upgrades pip, pipenv and uv with pip, and runs the official poetry installer script.

The generator behind the tags

The repository is not only an image, it is also the tooling that produces the images and keeps the tag table in the README honest. The top-level entries show a Python package with a pyproject.toml, a src directory, templates for the Dockerfiles, a bin directory, tests and a uv.lock file, plus versions.json as the version data and renovate.json for dependency updates. The pyproject.toml names the project docker-python-nodejs, requires Python 3.14, and lists four runtime dependencies, requests, semver, beautifulsoup4 and jinja2, which is exactly what you would expect for a tool that fetches upstream schedules, parses version ranges, scrapes the Python documentation page and renders the tag table and Dockerfile templates with Jinja2. There is a console entry point named `dpn`. The development group pulls in pytest, ruff, mypy and pytest-socket, and the pytest configuration disables socket access by default, so tests cannot quietly reach the network. Ruff is configured with a line length of 120, a target of py314 and the select set set to ALL with a list of documented exceptions, and mypy runs in strict mode.

Where these images are the wrong choice

The disclaimer is short and unambiguous. The README states that this is experimental and might break from time to time, and asks you to use it at your own risk. That matters for anything long-lived, because the images are not versioned with release notes and the repository publishes no GitHub releases, so there is no changelog to consult when a rebuild behaves differently. The tag churn compounds it. A tag that tracks the latest Python and Node.js release will move underneath you at whatever cadence upstream publishes, so `latest` in particular is a poor choice for a reproducible build, and even a specific tag will pick up new patch versions of the base distribution on each regeneration. The second limitation is the architecture gap on alpine. The third is size and ownership: because the images bundle pip, pipenv, poetry, uv, npm, yarn and corepack on top of two runtimes, they are larger than a purpose-built image, and they carry the maintainer's choices about which versions of those tools you get. If your service needs one runtime, or needs a hard guarantee about what is inside, building your own Dockerfile from python and node official images gives you that.

Editorial conclusion

Adopt these images if your build needs Python and Node.js in one container and you would rather not assemble the two toolchains yourself, and pin an explicit tag rather than latest so a rebuild does not move under you. Skip them if you need a production base image, since the README calls them experimental and may break from time to time. Before you commit, check the tag matrix for your exact Python and Node.js combination, confirm the architecture you need since alpine is built for linux/amd64 only, and verify the non-root user `pn` with uid 1000 works with your build.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nikolaik/docker-python-nodejs on GitHub
4. README