Configure Artifactory for PTC

JFrog Artifactory Configuration

This section covers the JFrog Artifactory side of the PTC setup: creating remote repositories, registering each package type with Package Reroute through the REST API, optionally enabling Curation, configuring anonymous access, and verifying the redirect endpoint. Artifactory must be fully configured before ZIA rules are activated (see Deployment Sequence).

Important — PTC repo_key must be a remote repository: The Package Reroute repo_key must point to a remote repository. Virtual repositories are not supported as the PTC repo_key.

Complete the following procedures in order (after Prerequisites):

• Step 1: Create a Remote Repository
• Step 2: Register Repositories with Package Reroute
• Step 3: Enable JFrog Curation
• Step 4: Configure Anonymous Access
• Step 5: Verify the Redirect Endpoint

Repository Architecture

PTC requires the following repository structure:

• Remote Repository: Proxies and caches packages from the upstream public registry, and is the only supported repo_key target for Package Reroute. JFrog Curation policies apply at this layer when Curation is enabled for that remote. The remote must allow anonymous Read and Deploy/Cache (per package type) so it can serve and cache packages from the upstream registry without end-user credentials. See Step 4: Configure Anonymous Access; scope permissions to that remote only.

The Package Reroute repo_key must point to a remote repository. Virtual repositories are not supported as the repo_key target—they prevent JFrog from tracking consumption accurately and from configuring Curation automatically on the upstream-facing repository.

Step 1: Create a Remote Repository

The steps below use npm and registry.npmjs.org as a worked example. For each other package type you support, create a remote repository of the matching package type with that ecosystem’s public registry URL, then map each type in the Package Reroute Config API the same way.

To create a remote repository for PTC:

1. Navigate to Administration > Repositories > Remote.
2. Click New Remote Repository.
3. Package Type: Select npm.
4. Repository Key: Enter a descriptive name, for example npm-remote-registry.
5. URL: https://registry.npmjs.org
6. Click Create.

The remote repository is created and ready to map in the Package Reroute Config API.

Step 2: Register Repositories with Package Reroute

After the remote repository exists, you must map each package type you enable to that remote repository’s repo_key using the Update Registry Configuration API. PTC does not work until this step completes—the Router /package-reroute path needs a configured remote repository for each registry type. The API validates that the repository exists before accepting the configuration.

The repo_key must reference a remote repository. Virtual repositories are not supported.

Supported type values for GA are npm, pypi, docker, and huggingfaceml. Repeat the call for every ecosystem you roll out.

To register npm with Package Reroute:

1. Use the remote repository key from Step 1 (for example npm-remote-registry) as the repo_key.
2. Call PUT /artifactory/api/package-reroute/config/npm with that key in the request body.
3. Confirm the response returns HTTP 200 and the same repo_key.
4. Optionally call Get Registry Configuration or Get Full Configuration to verify the mapping.

curl -X PUT "https://<YOUR_ARTIFACTORY_URL>/artifactory/api/package-reroute/config/npm" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"repo_key": "npm-remote-registry"}'

Where:

• <YOUR_ARTIFACTORY_URL>: Your JFrog Platform hostname (for example acme.jfrog.io)
• <token>: Admin JWT or use Basic authentication per Package Reroute Config API
• repo_key: The remote repository key from Step 1

Package Reroute is configured for npm. Repeat PUT /artifactory/api/package-reroute/config/{type} for each additional package type (for example pypi, docker, huggingfaceml) before you enable ZIA rules for those ecosystems.

Step 3: Enable JFrog Curation

You can skip this step and still use PTC for redirect, proxy, and cache. Enable Curation when you want the JFrog Catalog to evaluate requests (allow/block, CVS, audit) on the configured remotes.

JFrog Curation acts as the perimeter defense for your repositories when turned on. It checks each package request against organizational policies using the JFrog Catalog before allowing the download.

To enable Curation on the remote repository:

1. Navigate to Administration > Curation > Curated Repositories and connect the remote repository to Curation.
2. Enable Curation for npm-remote-registry.
3. Enable the Compliant Version Selection (CVS) flag on the same remote repository. CVS allows Curation to automatically serve the nearest compliant version of a package when the requested version is blocked by policy, maintaining developer flow without manual intervention. See Compliant Version Selection.

Curation is enabled on the remote repository used by PTC.

To configure initial Curation policies:

Recommended initial approach: Start with blocking malicious packages and use dry-run mode for everything else.

1. Navigate to Curation > Policies (see Create Policies).
2. Create a Block Malicious Packages policy:
   • Condition: Malicious package detected
   • Action: Block
   • Scope: All curated repositories
3. Create additional policies in dry-run mode for:
   • License compliance (e.g., block GPL-licensed packages)
   • Package maturity (e.g., minimum age of 14 days to protect against zero-day attacks)
   • CVE severity thresholds
4. Monitor the Curation audit log to understand the impact before switching policies from dry-run to blocking.

Policies are in place. Monitor audit results before enforcing blocks in production.

Step 4: Configure Anonymous Access

PTC currently operates with anonymous access. Redirected requests from Zscaler arrive without end-user Artifactory credentials, so the anonymous principal must be allowed to complete installs through the remote repository you set as repo_key in Package Reroute.

To configure anonymous access for PTC:

1. Navigate to Administration > Security > Settings.
2. Enable Allow Anonymous Access (platform setting).
3. Assign permissions to the anonymous user on the remote repository configured as repo_key in Package Reroute. Grant Read plus Deploy/Cache (and any other actions required for that package type) so Artifactory can proxy and cache from the public registry on behalf of anonymous clients.
4. Use permission targets limited to that remote (for example npm-remote-registry), not broad anonymous access across the whole instance.
5. Verify: From a context with no Artifactory token, exercise the same URL path clients use after redirect (the remote repository’s API URL for your package type) and confirm install or metadata fetch succeeds.

Anonymous users can complete installs through the configured remote repo_key.

Recommendation: Keep anonymous permission targets scoped to the specific remote repository used by PTC, rather than opening anonymous access on unrelated repos.

For more details on configuring anonymous access in JFrog Artifactory, see:

• Allow Anonymous Access
• Anonymous Users — Includes how to restrict anonymous access to API-only use and block anonymous users from accessing the Artifactory UI

Restricting anonymous PTC traffic to Zscaler egress

JFrog Cloud (SaaS) only — MyJFrog IP/CIDR Allowlist

The MyJFrog portal IP/CIDR allowlist is a JFrog Cloud control. It does not apply to typical self-hosted Artifactory deployments. On self-hosted deployments, use your own firewall, reverse proxy, WAF, or network policy to limit which source IPs can reach Artifactory’s HTTPS endpoint. For cloud security options and UI locations, see JFrog documentation: Configure cloud security.

For JFrog Cloud, adding Zscaler’s public egress ranges to the allowlist helps ensure anonymous PTC traffic is only accepted from paths that traverse Zscaler (tighten further with your network design as needed):

• Only requests from allowlisted source addresses can reach the instance (per MyJFrog rules).
• Direct anonymous access from arbitrary networks can be blocked when combined with your IP policy.
• Reduces exposure from enabling anonymous repository access for the redirect flow.

MyJFrog setup (cloud):

1. Log in to my.jfrog.com.
2. Open the Security area of the portal for your JFrog Cloud subscription and locate the IP/CIDR allowlist control.
3. In Security, locate the allowlist control and add Zscaler egress ranges in CIDR notation (e.g., 100.101.128.0/17). Obtain your organization’s ranges from the Zscaler Admin Portal or your Zscaler team.
4. Save or apply the change.

Tab names and menu paths can change between portal releases. Use Configure cloud security as the source of truth.

Step 5: Verify the Redirect Endpoint

The /package-reroute entry point on the JFrog Router is where Zscaler-redirected client traffic lands. It is product-defined and not customer-configurable. You can validate it before ZIA is enabled by calling Artifactory directly with the same query shape Zscaler will append (url= original registry URL, percent-encoded).

To verify the package-reroute redirect endpoint:

Build https://<hostname>/package-reroute?url=<percent-encoded-upstream-url> using your Artifactory hostname. Percent-encode the value of url (for https://registry.npmjs.org/express use https%3A%2F%2Fregistry.npmjs.org%2Fexpress). Example (fictional tenant acme.jfrog.io):

curl -v "https://<YOUR_ARTIFACTORY_URL>/package-reroute?url=https%3A%2F%2Fregistry.npmjs.org%2Fexpress"

Where:

• <YOUR_ARTIFACTORY_URL>: Your JFrog Platform hostname (for example acme.jfrog.io)

Use your own hostname. The Router path is /package-reroute. If an encoded url fails in your shell, try single-quoting the full URL or passing --data-urlencode via curl -G.

Expected (correct behavior): HTTP 302 or 307 with a Location header pointing to an Artifactory URL (typically under /artifactory/api/npm/<your-remote>/... for the express package—not still on registry.npmjs.org). Do not use curl -L here if you only want to inspect this first hop.

If something looks wrong:

• 401 / 403: Anonymous or Router access may not be configured yet—complete Step 4: Configure Anonymous Access and permission targets, then retry.
• 404 / wrong path: Confirm ZIA’s redirect URL uses /package-reroute on your Artifactory host and that you completed Step 2: Register repositories with Package Reroute. Use Get Full Configuration (GET /artifactory/api/package-reroute/config) or Get Registry Configuration to confirm repo_key for npm is set—that API does not return or change the Router redirect path. See the Package Reroute Config API overview.
• Very long url= values: Some clients require URL-encoding the url query parameter; if the bare string fails, encode the registry URL portion.

A successful test returns HTTP 302 or 307 with a Location header pointing at your Artifactory remote repository path.

Package Reroute Logs in Artifactory

When traffic follows PTC, JFrog Artifactory records package reroute events in system logs. These entries help verify that installs were redirected through Artifactory, which registry type was involved, and which source and target URLs were used.

Where to View Them

1. In the JFrog Platform UI, open Administration.
2. Go to Monitoring → Artifactory Logs (path names can vary slightly by release. The goal is the Artifactory log viewer under administration and monitoring).
3. Select artifactory-service.log (or download it for offline search).

You can pause, refresh, or download the log file depending on UI options. Large files are normal on busy instances.

Example Line for npm

2026-04-28T08:48:37.574Z [jfrt ] [INFO ] [5133f38050b3a8fab28558dbac15d947] [7.0.0.1-8081-exec-13] - Reroute: method=GET user=anonymous registry=npm original=https://registry.npmjs.org/mcp-remote target=https://acme.jfrog.io/artifactory/api/npm/npm-remote-registry/mcp-remote userAgent=npm/11.12.1 node/v25.9.0 darwin arm64 workspaces/false

What Each Part Means

Scoped packages and paths with special characters appear URL-encoded in log lines (for example %2f for / in scoped npm names), which is normal.

Why This Matters for Customers

• Audit and forensics: Prove that a given install attempt flowed through your governed Artifactory path, not only direct-to-registry.
• Triage: Compare original vs target when a redirect or repository mapping looks wrong.
• Client hygiene: Use userAgent to identify old npm/pip/Docker clients after policy changes.
• Ownership: Correlate user= and userAgent= with your identity and endpoint telemetry to troubleshoot client behavior.
• Dependency installs: Reroute events cover redirect handling; additional dependency fetches can appear as standard repository traffic.

Frequently Asked Questions

This section provides answers to frequently asked questions about configuring JFrog Artifactory for Package Traffic Controller (PTC).

Related Topics

• Package Traffic Controller (PTC) overview
• Prerequisites and Installation Script
• Configure Zscaler ZIA