Skip to content

docs: document slim Docker images and package manager setup - #2954

Open
vladfrangu wants to merge 2 commits into
masterfrom
docs/docker-slim-images
Open

docs: document slim Docker images and package manager setup#2954
vladfrangu wants to merge 2 commits into
masterfrom
docs/docker-slim-images

Conversation

@vladfrangu

@vladfrangu vladfrangu commented Sep 7, 2026

Copy link
Copy Markdown
Member

Mirrors apify/crawlee#4082 for the Actor Dockerfile page:

  • Document the -slim tag variants (no preinstalled apify/crawlee/typescript) in the Node.js base images section and the tag naming convention, and recommend them by default.
  • New Package managers section: Corepack enabled (no package manager besides npm preinstalled), packageManager support, flat node_modules linker config, /pkg-cache, and how to override the linker via ENV.
  • Supported Node.js versions are now 22, 24 and 26. Example Dockerfiles on the Dockerfile, source code, performance and academy pages bumped from :16/:20 to :24.

[🤖] Claude Code using Fable 5

@github-actions github-actions Bot added this to the 149th sprint - Tooling team milestone Sep 7, 2026
@github-actions github-actions Bot added the t-tooling Issues with this label are in the ownership of the tooling team. label Sep 7, 2026
@apify-service-account

apify-service-account commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

✅ Preview for this PR (commit a001c3e5) is ready at https://pr-2954.preview.docs.apify.com (see action run).

@honzajavorek honzajavorek left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for visiting our docs monastery with the gift of new content! It looks good, but I dropped a few comments so that the resulting document is more coherent, at least according to my humble opinion.

I also feel that even if all my comments are addressed, the document as a whole kind of jumps from general advice to Node.js advice, then to general advice, then to Python advice, then back to Node.js advice, and so on. But I don't know if I'm to poke into that right now. Leaving it up to you, if you feel like the sections could use a better sorting, when you glance over their order.


See the [Docker image guide](/sdk/js/docs/guides/docker-images) for more details.

#### Slim images

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
#### Slim images
### Node.js slim images

Oftentimes, flat is better than nested. I wouldn't nest this section as H4, I think it's okay if we use just ### here and a descriptive heading.


Every Node.js image is also published as a slim variant, with a `-slim` suffix appended to the tag (e.g. `24-slim`, `24-1.60.0-slim`). Slim images do not preinstall `apify`, `crawlee` or `typescript`. They only ship the browser automation library the image is built around (for example `puppeteer` or `playwright`), and `actor-node:24-slim` ships no npm packages at all. This makes them smaller and faster to pull, and your `package.json` is the single source of truth for dependency versions.

Use the slim variant unless you have a reason not to. Reach for the full image when you want to run something quickly without maintaining a `package.json`, or when you rely on the exact preinstalled versions of `apify` and `crawlee`.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use the slim variant unless you have a reason not to.

This makes me think that this section should be listed first? So that anyone looking for Node.js images finds this one first and only when they have a reason not to use them, they scroll down to find out more about the base images. Does it make sense? 🤔 And in such case, Reach for the full image could become Reach for the [full image](#anchor-to-the-base-images-section)

1. Predictability - You know exactly which version you're running
1. Debugging - Version-specific issues are easier to track down

## Package managers

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## Package managers
## Node.js package managers

I don't see this addressing any other managers than those specific to the Node.js ecosystem, so as a reader, I want to know before I start to read this that there isn't anything for me if I use pip or uv.


:::note Overriding the linker

These settings are applied through environment variables (`PNPM_CONFIG_NODE_LINKER`, `YARN_NODE_LINKER`), and both pnpm and yarn give environment variables precedence over `.npmrc` / `.yarnrc.yml`. To use a different linker, override the variable in your `Dockerfile` instead of the config file:

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This reads in kind of confusing way. I'd streamline the sentences so that the message reads more "from A to B" and not jumping by random:

To use a different linker, use environment variables, such as `PNPM_CONFIG_NODE_LINKER`
or `YARN_NODE_LINKER`. Both pnpm and yarn give environment variables precedence over
`.npmrc` or `.yarnrc.yml`, so you can override the variable in your `Dockerfile` instead
of in the config file:

... code block ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

t-tooling Issues with this label are in the ownership of the tooling team.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants