Install private packages
Cloudflare Pages supports custom package registries, allowing you to include private dependencies in your application. While this walkthrough focuses specifically on npm, the Node package manager and registry, the same approach can be applied to other registry tools.
You will be be adjusting the environment variables in your Pages project’s Settings. An existing website can be modified at any time, but new projects can be initialized with these settings, too. Either way, altering the project settings will not be reflected until its next deployment.
Registry Access Token
Every package registry should have a means of issuing new access tokens. Ideally, you should create a new token specifically for Pages, as you would with any other CI/CD platform.
With npm, you can create and view tokens through its website or you can use the npm
CLI. If you have the CLI set up locally and are authenticated, run the following commands in your terminal:
# Verify the current npm user is correct
$ npm whoami
# Create a readonly token
$ npm token create --read-only
#-> Enter password, if prompted
#-> Enter 2FA code, if configured
This will produce a read-only token that looks like a UUID string. Save this value for a later step.
Private modules on the npm registry
The following section applies to users with applications that are only using private modules from the npm registry.
In your Pages project’s Settings > Environment variables, add a new environment variable named NPM_TOKEN
to the Production and Preview environments and paste the read-only token you created as its value.
By default, npm
looks for an environment variable named NPM_TOKEN
and because you did not define a custom registry endpoint, the npm registry is assumed. Local development should continue to work as expected, provided that you and your teammates are authenticated with npm accounts (see npm whoami
and npm login
) that have been granted access to the private package(s).
Custom registry endpoints
When multiple registries are in use, a project will need to define its own root-level .npmrc
configuration file. An example .npmrc
file may look like this:
@foobar:registry=https://npm.pkg.github.com
//registry.npmjs.org/:_authToken=${TOKEN_FOR_NPM}
//npm.pkg.github.com/:_authToken=${TOKEN_FOR_GITHUB}
Here, all packages under the @foobar
scope are directed towards the GitHub Packages registry. Then the registries are assigned their own access tokens via their respective environment variable names.
Your Pages project must then have the matching environment variables defined for all environments. In our example, that means TOKEN_FOR_NPM
must contain the read-only npm token value and TOKEN_FOR_GITHUB
must contain its own personal access token.
Managing multiple environments
In the event that your local development no longer works with your new .npmrc
file, you will need to add some additional changes:
Rename the Pages-compliant
.npmrc
file to.npmrc.pages
. This should be referencing environment variables.Restore your previous
.npmrc
file – the version that was previously working for you and your teammates.Go to your Pages project > Settings > Environment variables, add a new environment variable named
NPM_CONFIG_USERCONFIG
and set its value to/opt/buildhome/repo/.npmrc.pages
. If your.npmrc.pages
file is not in your project’s root directory, adjust this path accordingly.