Docs / Shadcn CLI

Shadcn CLI

Learn how to use the new Shadcn CLI 3.0 with namespaced registries and private registry authentication for accessing pro blocks and components.

All of our blocks are compatible and downloadable using the shadcn CLI via our Shadcn Registry.

We support namespaced registries and authentication. This feature provides improved API key authentication for our private shadcn registry, allowing you to access all our pro blocks and components directly from the CLI with environment variables. This enables seamless integration with the Shadcn MCP and other modern developer workflows.

The shadcn CLI is maintained by the shadcn/ui open source project. For command reference, init options, and registry configuration, see the shadcn CLI documentation.

Getting Started

1. Ensure your project has a components.json

{
  "$schema": "https://ui.shadcn.com/schema.json",
  "style": "radix-vega",
  "rsc": true,
  "tsx": true,
  "tailwind": {
    "config": "",
    "css": "app/globals.css",
    "baseColor": "neutral",
    "cssVariables": true,
    "prefix": ""
  },
  "iconLibrary": "lucide",
  "rtl": false,
  "aliases": {
    "components": "@/components",
    "utils": "@/lib/utils",
    "ui": "@/components/ui",
    "lib": "@/lib",
    "hooks": "@/hooks"
  },
  "menuColor": "default",
  "menuAccent": "subtle",
  "registries": {
    "@shadcnblocks": {
      "url": "https://www.shadcnblocks.com/r/{name}",
      "headers": {
        "Authorization": "Bearer ${SHADCNBLOCKS_API_KEY}"
      }
    }
  }
}

2. Generate Your API Key

Note: API key access requires a Pro plan or higher.

Visit your dashboard and navigate to the API Keys section:

  1. Click “New API Key”
  2. Give your key a descriptive name (e.g., “Development”, “CI/CD Pipeline”)
  3. Optionally set an expiration date
  4. Copy the generated key

4. Install Blocks & Components

Use shadcn to install any block from our registry:

npx shadcn add @shadcnblocks/hero125
npx shadcn add @shadcnblocks/pricing3
npx shadcn add @shadcnblocks/features8

Troubleshooting

API key is set in .env but still getting 401

Your components.json references the key via ${SHADCNBLOCKS_API_KEY}, which the CLI expands from your environment. Sometimes the variable is present in your .env file but isn’t actually being loaded (wrong file name, wrong location, the tool not loading .env in that context, a stale shell session, etc.). The reasons vary, so the fastest way to isolate it is to test with the key hardcoded:

  1. Temporarily replace the env reference in components.json with the raw key:
{
  "registries": {
    "@shadcnblocks": {
      "url": "https://www.shadcnblocks.com/r/{name}",
      "headers": {
        "Authorization": "Bearer sk_live_your_actual_key_here"
      }
    }
  }
}
  1. Run your install command again.

If the install now succeeds, the key itself is valid and the problem is that your .env isn’t being read — check the file name/location, confirm the variable name matches SHADCNBLOCKS_API_KEY exactly, and restart your terminal/dev process so it picks up the value. If it still fails, the key may be invalid, expired, or revoked — generate a new one from your dashboard.

⚠️ Security warning: The hardcoded key is only for local testing. Revert to ${SHADCNBLOCKS_API_KEY} before committing — never commit an API key to your repository, as it’s a security risk.

Non www url redirection stripping auth headers

The most common cause is the registry URL host. Always use the www host in your components.json:

{
  "registries": {
    "@shadcnblocks": {
      "url": "https://www.shadcnblocks.com/r/{name}",
      "headers": {
        "Authorization": "Bearer ${SHADCNBLOCKS_API_KEY}"
      }
    }
  }
}

If you use the non-www URL (https://shadcnblocks.com/r/{name}), the request is redirected to www. On that redirect most HTTP clients drop the Authorization header for security reasons, so your API key never reaches the server and you get a 401.

Recent versions of the shadcn CLI (4.11.1+, including the current release) use the native fetch implementation, which strips the header on this redirect — so the non-www URL fails even with the standard npx shadcn. Older versions (≤ 4.11.0) used node-fetch, which preserved the header across the apex → www redirect, which is why the same config may have worked for you previously. Other clients and runtimes — bunx, Deno, CI scripts, and AI site builders — strip it as well. Using the www URL avoids the redirect entirely and works everywhere.