Connect Bolt.new to JFrog Artifactory by configuring your exported project's .npmrc file to use Artifactory as a private npm registry. After exporting the Bolt project locally, set the npm registry URL and authentication token, then run npm install to pull packages from Artifactory. You can also publish your Bolt project as a versioned npm package to Artifactory for use across other projects, or store Docker images in Artifactory's container registry after containerizing your Bolt app.
Enterprise Artifact Management for Bolt.new Projects with JFrog Artifactory
JFrog Artifactory is primarily an enterprise tool — most individual developers and small teams using Bolt.new will not need it. It becomes relevant when you are building Bolt prototypes within an organization that already uses Artifactory as its central artifact repository, or when you need to share private npm packages (custom component libraries, utility functions, design systems) across multiple Bolt projects and teams.
The integration pattern is purely post-export. Bolt.new's WebContainer uses npm to install packages, but it pulls from the public npmjs.com registry — you cannot configure Bolt to use a private registry during development inside the browser. After exporting your project to your local machine (via Bolt's GitHub integration or ZIP download), you can configure npm to route package installations through Artifactory using a .npmrc configuration file. This gives you access to your organization's private packages while keeping the Bolt development workflow intact.
There are three distinct use cases for Artifactory with Bolt projects. First, installing private internal packages in a Bolt-exported project — your organization's design system or utility library lives in Artifactory, and you need to install it after exporting. Second, publishing Bolt-generated components as reusable packages — you built a great component in Bolt, want to share it across projects, and Artifactory is your organization's package registry. Third, storing Docker images — after containerizing your Bolt app, push the image to Artifactory's Docker registry as part of an enterprise CI/CD pipeline. All three patterns use standard npm and Docker tooling; Artifactory is simply the destination.
Integration method
JFrog Artifactory integrates with Bolt.new projects after export, not within the Bolt browser environment itself. The integration has two primary patterns: configuring the exported project to use Artifactory as a private npm registry for installing internal packages, and publishing Bolt-generated components as versioned npm packages to Artifactory for sharing across teams. Both patterns use the standard .npmrc configuration file and work with Bolt-generated Vite and Next.js projects without modification.
Prerequisites
- A Bolt.new project exported to your local machine (via GitHub clone or ZIP download)
- Access to a JFrog Artifactory instance — either a JFrog Cloud account (free at jfrog.com) or an organization-provisioned Artifactory server
- An Artifactory API token or identity token (generated in Artifactory: Edit Profile > Generate Identity Token)
- The npm repository name in Artifactory that you will use (ask your DevOps team, or create one under Administration > Repositories if you have admin access)
- Node.js and npm installed locally to run the configuration commands
Step-by-step guide
Export Your Bolt Project and Prepare for Artifactory Integration
Export Your Bolt Project and Prepare for Artifactory Integration
Before configuring Artifactory, your Bolt project needs to be on your local machine. Bolt.new's WebContainer runs inside a browser tab and has no access to local filesystem or custom registry configurations — all Artifactory setup happens in the exported project environment. Export your Bolt project using one of two methods: the ZIP download (click the download icon in Bolt's toolbar) or GitHub integration (use Bolt's Git panel to push to GitHub, then clone locally). The GitHub route is recommended if you plan to have ongoing development — it gives you a proper Git history and enables bidirectional sync between Bolt and your local environment. After extracting or cloning the project, run npm install to install dependencies from the public npmjs.com registry. This establishes a working baseline before you reconfigure npm to use Artifactory. Verify the project builds by running npm run build. A clean build here confirms the export was successful and the project is in a valid state before you start modifying registry configuration. Note that you are not changing how Bolt.new itself works — Bolt will continue to use the public npm registry for any future prompt-driven package installations in the browser. The Artifactory configuration you add here applies only to your local development and CI/CD environments. If Bolt adds new packages in future sessions, you export the updated project and those packages will come from npmjs.com — which is fine for public packages. Only your organization's private packages need the Artifactory registry configuration.
1# After cloning or extracting the Bolt project:2cd your-bolt-project34# Install standard dependencies first:5npm install67# Verify the build works before adding Artifactory config:8npm run build910# Confirm which Node.js version is being used:11node --version12npm --versionPro tip: Ask your DevOps or platform engineering team for the exact Artifactory server URL, repository name, and authentication method before starting configuration. Artifactory instances vary significantly in URL structure and auth requirements between organizations.
Expected result: The Bolt project is exported, dependencies are installed, and npm run build succeeds. You have the Artifactory server URL and your API token ready.
Configure .npmrc to Use Artifactory as the npm Registry
Configure .npmrc to Use Artifactory as the npm Registry
The .npmrc file controls npm's behavior for a specific project when placed in the project root, or globally when placed in the home directory (~/.npmrc). For Bolt projects, a project-level .npmrc is the right approach — it applies only when working in this specific directory and gets committed to Git alongside the code, making it available to all developers and CI/CD pipelines working with the project. Artifactory supports two common npm authentication methods: basic authentication (username and hashed password) and token-based authentication (API token or identity token). Token-based is simpler and more secure for CI/CD use. Artifactory's npm repository URL follows a standard pattern: https://your-instance.jfrog.io/artifactory/api/npm/your-repo-name/ For scoped packages (recommended pattern for private packages — e.g., @yourorg/design-system), you configure Artifactory only for that scope and keep npmjs.com for all public packages. This is cleaner than routing all npm traffic through Artifactory and avoids slowing down installation of public packages. IMPORTANT: The API token value in .npmrc must never be committed to a public Git repository. The .npmrc file with authentication tokens should either be in .gitignore (if it contains the actual token), or use environment variable references instead of literal token values. The approach using environment variables (${NPM_TOKEN}) keeps the .npmrc safe to commit while requiring the token to be set as an environment variable in each developer's shell or CI/CD system.
1# .npmrc configuration for Artifactory npm registry:2# Option 1: Scope-specific registry (recommended - only @yourorg packages use Artifactory):3@yourorg:registry=https://your-instance.jfrog.io/artifactory/api/npm/your-npm-repo/4//your-instance.jfrog.io/artifactory/api/npm/your-npm-repo/:_authToken=${NPM_TOKEN}56# Option 2: Set Artifactory as default registry for ALL packages (route all npm traffic through Artifactory):7registry=https://your-instance.jfrog.io/artifactory/api/npm/your-npm-repo/8//your-instance.jfrog.io/artifactory/api/npm/your-npm-repo/:_authToken=${NPM_TOKEN}910# Set the environment variable before running npm install:11export NPM_TOKEN=your-artifactory-api-token1213# Then install private packages:14npm install @yourorg/design-system15npm install @yourorg/auth-utilitiesPro tip: Get your Artifactory-specific .npmrc configuration by clicking 'Set Me Up' in the Artifactory web UI next to your npm repository. This auto-generates the exact URL format and authentication commands for your specific instance, avoiding manual URL construction errors.
Expected result: The .npmrc file is configured with the Artifactory registry URL and authentication token reference. Running npm install @yourorg/package-name successfully pulls the package from Artifactory.
Install Private Packages and Update the Bolt Project
Install Private Packages and Update the Bolt Project
With .npmrc configured, installing private packages from Artifactory works the same as installing any public npm package — you just specify the scoped package name and npm routes the request to Artifactory based on the scope configuration. Before installing, set the NPM_TOKEN environment variable in your terminal session so npm can authenticate with Artifactory. This token should come from your user profile in Artifactory (Edit Profile > Generate Identity Token). Never hardcode this value directly in .npmrc — use the environment variable pattern shown in the previous step. After installing private packages from Artifactory, you may want to update your Bolt project to use these packages instead of (or alongside) whatever Bolt generated. For example, if your organization has a design system package (@yourorg/ui), you could replace Bolt-generated shadcn/ui components with your organization's components. This is done by editing the component files locally — you are now working in a standard local Node.js environment where you can make any changes. If you want these private packages available the next time you work in Bolt, you have a few options. You can push your local changes (including the updated package.json with the private package dependencies) back to GitHub, and Bolt will show the updated package.json — though Bolt will not be able to install private packages in its WebContainer environment, meaning prompts that try to use these packages may produce code that works locally but fails in Bolt's preview. The practical approach is to use Bolt for generating new components and UI logic, then integrate them locally with the private packages.
1# Set authentication token (do this in your shell before npm install):2export NPM_TOKEN=your-artifactory-identity-token34# Install private packages from Artifactory:5npm install @yourorg/design-system @yourorg/api-client67# Verify the package was installed from Artifactory (check the version source):8npm info @yourorg/design-system910# If the install fails with authentication error, verify the token:11curl -H "Authorization: Bearer $NPM_TOKEN" \12 https://your-instance.jfrog.io/artifactory/api/npm/your-repo/13# Should return JSON with repository info, not a 401 errorPro tip: Add NPM_TOKEN to your shell's profile file (.bashrc, .zshrc, or config.fish) so you do not need to export it manually in every terminal session. For CI/CD systems, add it as a secret environment variable in CircleCI, GitHub Actions, or your pipeline platform.
Expected result: Private Artifactory packages are installed in node_modules/ and listed in package.json. You can import these packages in your Bolt-exported project files.
Publish a Bolt Component as an npm Package to Artifactory
Publish a Bolt Component as an npm Package to Artifactory
If you want to share components built in Bolt across multiple projects within your organization, you can package them as private npm packages and publish to Artifactory. This is the reverse of the previous steps — instead of consuming packages from Artifactory, you are producing them. First, identify what you want to package. Common candidates from Bolt projects are custom hook sets, utility functions, a collection of themed components, or an API client module. Create a separate directory for the package (or use the entire Bolt project if it is itself a library). Update the package.json with the required publishing fields: the package name with your organization's npm scope (@yourorg/package-name), a version number following semantic versioning, the main entry point (usually dist/index.js after building), and an exports map if you want to support both CommonJS and ESM imports. Add a prepare script that builds the package before publishing. Publish to Artifactory using npm publish. npm reads the .npmrc registry configuration and routes the publish request to Artifactory instead of npmjs.com. After publishing, the package appears in the Artifactory web UI under your npm repository and is installable by anyone in your organization who has Artifactory access.
1// package.json additions for publishing to Artifactory:2{3 "name": "@yourorg/bolt-components",4 "version": "1.0.0",5 "description": "Reusable components extracted from Bolt.new projects",6 "main": "dist/index.js",7 "module": "dist/index.esm.js",8 "types": "dist/index.d.ts",9 "files": [10 "dist/",11 "README.md"12 ],13 "exports": {14 ".": {15 "import": "./dist/index.esm.js",16 "require": "./dist/index.js",17 "types": "./dist/index.d.ts"18 }19 },20 "scripts": {21 "build": "tsc && vite build --mode library",22 "prepare": "npm run build"23 },24 "publishConfig": {25 "registry": "https://your-instance.jfrog.io/artifactory/api/npm/your-npm-repo/"26 }27}2829// Publish command:30// npm publish --registry https://your-instance.jfrog.io/artifactory/api/npm/your-npm-repo/Pro tip: Use semantic versioning strictly for Artifactory packages: patch versions (1.0.1) for bug fixes, minor versions (1.1.0) for backwards-compatible features, major versions (2.0.0) for breaking changes. This helps teams that depend on your package understand the impact of updates.
Expected result: The package is published to Artifactory and visible in the Artifactory web UI. Team members can install it with 'npm install @yourorg/bolt-components' after configuring their .npmrc.
Common use cases
Installing Private Organization Packages in a Bolt Export
Your organization has a private npm package (e.g., @yourorg/design-system or @yourorg/auth-utilities) stored in Artifactory. After exporting a Bolt project, configure .npmrc to use Artifactory as the scoped registry for @yourorg packages, then run npm install to pull these internal dependencies alongside public packages from npmjs.com.
Copy this prompt to try it in Bolt.new
Publishing a Bolt Component Library to Artifactory
Build a reusable UI component library in Bolt, export it, add proper package.json configuration (name, version, main, exports), and publish it to Artifactory for other developers in the organization to use. Team members configure their .npmrc to pull from Artifactory and can install the component library in their own projects.
Copy this prompt to try it in Bolt.new
Storing Bolt App Docker Images in Artifactory
After containerizing a Bolt project with Docker, push the image to Artifactory's Docker registry instead of Docker Hub. Enterprise CI/CD pipelines pull images from Artifactory during deployment, giving security teams visibility into all deployed artifacts and enabling vulnerability scanning through Xray integration.
Copy this prompt to try it in Bolt.new
Troubleshooting
npm install fails with '401 Unauthorized' when trying to pull from Artifactory
Cause: The NPM_TOKEN environment variable is not set, has expired, or the token does not have read permissions for the Artifactory npm repository.
Solution: Verify the token is set: 'echo $NPM_TOKEN' should print a non-empty value. If empty, run 'export NPM_TOKEN=your-token'. If the token is set but still 401, regenerate it in Artifactory under Edit Profile > Access Tokens. Ensure the token has 'Read' permissions for the specific repository. Also verify the .npmrc registry URL matches exactly — a typo in the hostname or repository name returns 401 even with a valid token.
1# Debug authentication issue:2curl -H "Authorization: Bearer $NPM_TOKEN" \3 "https://your-instance.jfrog.io/artifactory/api/npm/your-repo/" \4 -v5# HTTP 200 = auth works6# HTTP 401 = token invalid or expired7# HTTP 404 = repository name wrongnpm publish fails with '403 Forbidden' when trying to publish a package to Artifactory
Cause: The API token does not have 'Deploy' permissions for the target repository, or the repository is configured as read-only (virtual repositories in Artifactory are read-only aggregation views).
Solution: Ensure you are publishing to a local repository (not a virtual or remote repository). Virtual repositories in Artifactory aggregate multiple repos and are read-only — you can pull from them but must publish to a local repository. Check with your Artifactory administrator to confirm you have Deploy permission on the target repository.
1# Verify repository type in Artifactory:2# Administration > Repositories > Local Repositories3# Look for your repo name - it should be 'Local' type, not 'Virtual' or 'Remote'Private Artifactory packages installed locally are not available when the Bolt project runs in the browser preview
Cause: This is expected behavior — Bolt's WebContainer cannot use a private npm registry. Packages installed locally via Artifactory are only available in your local development environment, not in Bolt's browser-based environment.
Solution: This is a fundamental WebContainer limitation, not a configuration error. Your options are: (1) Use the package locally after export and accept that Bolt's preview will not have it; (2) Check if the package is available on the public npm registry (if it is a broadly useful open-source package hosted on npmjs.com as well as Artifactory); (3) Use Bolt's AI to generate the equivalent functionality inline for development, then replace with the private package after export. There is no way to configure Bolt's preview to use Artifactory.
Best practices
- Use scoped npm packages (@yourorg/package-name) for all Artifactory-hosted private packages — this makes it clear which packages are internal and allows npm to route only those packages through Artifactory while public packages still use npmjs.com directly.
- Store the NPM_TOKEN as an environment variable (${NPM_TOKEN} in .npmrc) rather than hardcoding the actual token — commit the .npmrc with the variable reference but never commit the actual token value.
- Configure Artifactory as a virtual repository that proxies npmjs.com plus your local repositories — this allows a single registry URL for all packages (both public and private) without requiring developers to configure multiple registries.
- Add .npmrc to your .gitignore if it contains literal token values, or use the environment variable pattern to make .npmrc safe to commit for team-wide registry configuration.
- Use Artifactory's Xray integration for vulnerability scanning of all packages pulled from or published to Artifactory — this adds an important security layer for enterprise Bolt deployments.
- Version private packages with semantic versioning and maintain a CHANGELOG.md — teams depending on your Bolt-generated components need to understand what changed between versions.
- For most Bolt users, this is an enterprise feature — if your team does not already use JFrog Artifactory, GitHub Packages or AWS CodeArtifact are simpler private package hosting alternatives.
Alternatives
GitHub Packages (packages.github.com) is a simpler private npm registry integrated directly with GitHub — if your team uses GitHub for source control, GitHub Packages may eliminate the need for a separate Artifactory instance.
Artifactory manages Docker images alongside npm packages as part of a universal artifact repository, while standalone Docker Hub is the simpler alternative for teams only needing container image storage.
Jenkins integrates with Artifactory through the JFrog plugin to automate artifact publishing as part of a CI/CD pipeline, combining build orchestration (Jenkins) with artifact management (Artifactory) for enterprise workflows.
GitLab includes a built-in package registry (npm, Docker, Maven) that provides similar private artifact hosting without requiring a separate JFrog Artifactory subscription — a simpler choice for GitLab-based teams.
Frequently asked questions
Can I configure Bolt.new's WebContainer to use Artifactory as the npm registry during development?
No — Bolt.new's WebContainer handles npm installations internally and there is no mechanism to override the npm registry URL from within the browser environment. All Artifactory configuration applies only to your local development environment after exporting the project. For development in Bolt, all packages must be publicly available on npmjs.com.
Do I need JFrog Artifactory, or are there simpler private package registry options?
For most Bolt users, simpler alternatives work fine. GitHub Packages (packages.github.com) is included with GitHub and integrates directly with your repositories. AWS CodeArtifact works well if your team is already on AWS. Verdaccio is a lightweight self-hosted npm registry. JFrog Artifactory makes sense if your organization already uses it as a universal artifact manager (npm, Docker, Maven, Gradle) and you need its advanced features like Xray vulnerability scanning, replication, and access control.
Can I publish a Bolt-generated project to Artifactory and import it into another Bolt project?
You can publish it to Artifactory, but the other Bolt project cannot install it from Artifactory directly (WebContainer only accesses public npm packages). You would need to export the second Bolt project locally and configure .npmrc to pull the private package from Artifactory there. Bolt's preview will not show the private package's components, but the final deployed version will have them after local integration.
How do I handle Artifactory tokens in a CircleCI or CI/CD pipeline for my Bolt project?
Add NPM_TOKEN as a secret environment variable in your CI/CD platform's settings (CircleCI Project Settings > Environment Variables, GitHub Actions > Secrets, etc.). The .npmrc file with ${NPM_TOKEN} as the auth token reference is already in your repository — the CI/CD platform injects the actual token value at build time. This pattern keeps the token out of the repository while allowing automated builds to authenticate with Artifactory.
What types of artifacts can Artifactory manage from a Bolt project workflow?
Artifactory supports multiple artifact types relevant to Bolt projects: npm packages (component libraries and utilities built in Bolt), Docker images (containerized Bolt apps), and potentially Maven/Gradle artifacts if your backend services use JVM languages. All of these are managed in one Artifactory instance with unified access control, making it valuable for organizations with polyglot technology stacks building on Bolt-generated frontend projects.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation