Cache HeroUI Pro installs in GitHub Actions, Vercel, and other CI so pipelines stay under the daily CDN download limit.
HeroUI Pro CI installs download the package from the CDN during postinstall. Each install that cannot reuse a previous download counts against the daily limit for that CI/CD token. The limit resets at 00:00 UTC.
| License | Daily CI downloads |
|---|---|
| Individual (any plan) | 1,000 |
| Team Web | 5,000 |
| Team Super | 10,000 |
| Enterprise with unlimited downloads | No daily cap |
The count is per CI/CD token, not per seat. A pipeline that installs on every commit, matrix job, or preview build can spend the allowance even when the package version has not changed. Caching is allowed and is the way to avoid that.
The dashboard shows today's usage, the allowance, and the reset time on the Tokens page and the overview CI/CD token card.
The CDN request happens when the package is installed and its postinstall script runs. Restoring a warm install skips that script.
Cache both of these, keyed by the lockfile:
node_modules (and pnpm's virtual store, if you use one), so install is a no-op and postinstall does not run againA store-only cache is not enough. An empty node_modules still installs the package and runs postinstall, which calls the CDN again.
Do not delete node_modules before install, and do not pass --force or clean the package manager cache in CI. Those options throw away the cache and count another download.
actions/setup-node with cache: pnpm or cache: npm caches the store. Also cache the install output with actions/cache so postinstall does not run on every job.
Use HEROUI_AUTH_TOKEN from the dashboard. Keep it in repository secrets.
jobs:
build:
runs-on: ubuntu-latest
env:
HEROUI_AUTH_TOKEN: ${{ secrets.HEROUI_AUTH_TOKEN }}
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: pnpm
- name: Cache installed dependencies
uses: actions/cache@v4
with:
path: |
node_modules
~/.local/share/pnpm/store
key: ${{ runner.os }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}
restore-keys: |
${{ runner.os }}-pnpm-
- run: pnpm install --frozen-lockfilejobs:
build:
runs-on: ubuntu-latest
env:
HEROUI_AUTH_TOKEN: ${{ secrets.HEROUI_AUTH_TOKEN }}
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- name: Cache installed dependencies
uses: actions/cache@v4
id: npm-install
with:
path: node_modules
key: ${{ runner.os }}-node-modules-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-modules-
- run: npm ciPoint the cache key at the lockfile only. Hashing source files misses the cache on every commit. restore-keys lets a lockfile change reuse the previous store instead of downloading every package from scratch.
In a monorepo, run one install for the workflow and share that cache across jobs. A matrix that installs the same lockfile in every cell multiplies the CDN downloads.
Vercel restores node_modules and the package manager cache between builds when the lockfile is unchanged. Leave that cache on.
HEROUI_AUTH_TOKEN in the project's environment variables. Do not expose it to the browser.pnpm install, npm install, or the equivalent frozen install).VERCEL_FORCE_NO_BUILD_CACHE.rm -rf node_modules or pnpm install --force.A lockfile change still installs once. Later builds with the same lockfile reuse the cache and do not count another CDN download.
Restore the store and node_modules before install, then save them after a successful install. Key the cache with the lockfile hash.
# pnpm store location
pnpm store path
# npm cache location
npm config get cache# Generic cache inputs. The path list is the same idea as actions/cache.
key: ci-pnpm-{{ checksum "pnpm-lock.yaml" }}
paths:
- node_modules
- ~/.local/share/pnpm/storeThen install with the token present:
export HEROUI_AUTH_TOKEN=your-cicd-token
pnpm install --frozen-lockfileUse the same pattern for npm (npm ci) and for React Native packages (heroui-native-pro). Both products share the CI/CD token and the same daily counter.
When a key reaches 80% of the daily allowance, the dashboard links back to this page. At 100%, installs fail until 00:00 UTC with the limit, remaining count, and reset time in the response headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset).