Node and npm available to build steps, for compiling a theme or bundling front-end assets
Node.js and npm for build steps — compiling a theme, bundling front-end assets, running a bundler over your CSS. A tool the build runs in, not a container that runs beside your site: nothing of it is started, it belongs to no machine, and it is gone by the time the release is serving.
That is the whole difference between this and
Node.js as an application. If your site is a Node
application — Next.js, Nuxt, Express — you want that one, which runs
continuously and answers requests. If your site is PHP and merely needs npm run build during a deploy, you want this one.
Both can be true at once. A Drupal site with a themed front end uses PHP-FPM to serve and this to build.
| Version | Status |
|---|---|
26.10 |
Supported, and the default |
24.21 |
Supported |
22.23 |
Supported |
26.8 |
Deprecated — still runs, but move to something newer |
24.20 |
Deprecated — still runs, but move to something newer |
A deprecated version still runs and is still what some sites are on. It is listed so you can move before it goes, rather than finding out on the morning a build stops resolving it.
Pin the version, not the build: name 26.10 and the platform matches it to the
current build, so a security rebuild reaches you without anybody editing a
repository.
Nothing on this one. Everything it takes decides where it connects, what it is, or whether it starts — and an application able to set those could break its own environment in ways nothing here would catch.
Name it in vallic.yaml, and run the steps that need it in
its image with image: node. A step without image runs in your application's
own container, and the PHP image has no node or npm in it:
services:
- node: '26'
build:
steps:
- name: PHP dependencies
run: composer install --no-dev --optimize-autoloader
- name: Theme
run: npm ci && npm run build
image: node
The step runs against the same checkout as the others, so what it writes — a
compiled theme, a bundle — is in the release. npm's download cache is kept
between builds for you. Anything it installs that production does not need,
node_modules above all, is worth removing in the same step, because the
release is copied to every machine that runs it.