---
updatedAt: 2026-09-29T11:30:14.000Z
agentTools:
  siteIndex: https://docs.jfrog.com/llms.txt
  projectIndex: https://docs.jfrog.com/security/llms.txt
---

# Configuration by Package Type

Set SASE intercept hostnames, redirect methods, and client trust for npm, PyPI, Maven, Docker, Hugging Face, and Go when routing public registry traffic through JFrog Artifactory.

## Public Registry Hostnames

This is the common hostname reference shared by every SASE provider's intercept rule, regardless of vendor. Add every HTTPS hostname your clients use for the package types you have enabled in Artifactory (Package Reroute remote repositories). Confirm the defaults below with TLS/SNI captures, package-manager docs, or your SASE provider's logs. Corporate mirrors and private edge caches use different hosts. Scope must stay aligned with [Supported Package Types (GA)](/security/docs/package-traffic-controller#supported-package-types-ga) and your entitlements.

| Package ecosystem        | Common HTTPS hostnames                                             | Notes                                                                                                                                                                                                                                                                                                                                                    |
| ------------------------ | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| npm                      | `registry.npmjs.org`, `registry.npmjs.com`, `registry.yarnpkg.com` | `registry.npmjs.org` is the default; `registry.npmjs.com` is also a valid registry host. Yarn (classic) and some installs still resolve the default registry via `registry.yarnpkg.com`—include it when Yarn is in scope alongside npm.                                                                                                                  |
| Python (PyPI)            | `pypi.org`, `files.pythonhosted.org`                               | pip, Poetry, and uv often use both; include each you see in traffic.                                                                                                                                                                                                                                                                                     |
| Java (Maven)             | `repo1.maven.org`, `repo.maven.apache.org`                         | Maven Central hosts supported for PTC. After the redirect, Artifactory strips the `/maven2` path prefix before serving from your Maven remote.                                                                                                                                                                                                           |
| Docker (e.g. Docker Hub) | `registry-1.docker.io`, `index.docker.io`                          | `auth.docker.io` is often redundant for routine image pulls (many environments never need it in the category); adding it does not hurt if you prefer a broader list or see auth-related misses in your SASE provider's logs. GHCR, Quay, ECR, Artifactory-on-prem registries, and so on each need their hostnames added when those clients are in scope. |
| Hugging Face             | `huggingface.co`                                                   | Some clients use additional CDN-style hosts; extend the list if logs show misses.                                                                                                                                                                                                                                                                        |
| RubyGems                 | `rubygems.org`, `api.rubygems.org`, `index.rubygems.org`           | `rubygems.org` handles package downloads; `api.rubygems.org` is used for gem metadata lookups; `index.rubygems.org` is used by Bundler and dependency resolution (`/versions`, `/info/<gem>`, `/api/v1/dependencies`). Include all three.                                                                                                                |
| Cargo (Rust)             | `index.crates.io`                                                  | Cargo 1.68+ uses the sparse registry index at `index.crates.io`. After the redirect, Artifactory serves `config.json` pointing crate downloads directly at Artifactory — `crates.io` and `static.crates.io` must NOT be on the intercept list.                                                                                                           |
| Go                       | `proxy.golang.org`, `sum.golang.org`, `index.golang.org`           | `proxy.golang.org` is the module proxy, `sum.golang.org` is the checksum database, and `index.golang.org` is the module index. One Go remote covers all three.                                                                                                                                                                                           |

This list is not exhaustive. Public registry and CDN hostnames can change, so re-verify when upgrading clients or changing regions.

## Ecosystem Overview

SASE intercept rules, SSL inspection, Artifactory remote repository layout, and client trust differ per ecosystem. This page summarizes npm, Python (PyPI), RubyGems, Cargo, Maven, and Go in detail and points to other topics for Docker and Hugging Face. It does not replace `scripts/README.md` for OS-specific variables, client versions, and tests—use that README as the source of truth for workstation configuration.

Configure each ecosystem you enable:

* [npm (Node.js)](#npm-configuration)
* [Python (PyPI)](#python-pypi-configuration)
* [Maven](#maven-configuration)
* [RubyGems](#rubygems-configuration)
* [Cargo (Rust)](#cargo-rust-configuration)
* [Go](#go-configuration)
* [Docker, Hugging Face, and other types](#docker-hugging-face-and-other-types)

### SASE: Patterns for Every Ecosystem

* Add the correct HTTPS hostnames for each client you intercept (see [Public Registry Hostnames](#public-registry-hostnames)).

> **Important — Request method selection:** The HTTP methods to include and exclude in the redirect rule differ per package ecosystem. Using the wrong methods (for example, redirecting POST) will break specific CLI commands. Configure methods exactly as specified in the [npm](#npm-configuration), [Python (PyPI)](#python-pypi-configuration), [Maven](#maven-configuration), and [Go](#go-configuration) tables.

* Trust: Configure the SASE CA per client and OS before enabling inspection (see your SASE provider's guide, for example [Before Step 2: Verify trust stores for your package clients](/security/docs/configure-zscaler-zia#before-step-2-verify-trust-stores-for-your-package-clients)).

***

## npm Configuration

### Intercept Settings for npm

| Setting          | Value                                                                                                                                    |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| URL to add       | `registry.npmjs.org` (also `registry.npmjs.com` and `registry.yarnpkg.com`; see [Public Registry Hostnames](#public-registry-hostnames)) |
| Request Methods  | GET and HEAD only                                                                                                                        |
| Excluded Methods | POST (must NOT be selected)                                                                                                              |

### Why POST Must Be Excluded for npm

The `npm audit` command sends POST requests to `registry.npmjs.org`. If POST requests are included in the redirect rule, `npm audit` is redirected to Artifactory, which will fail because:

* npm expects an HTTP 307 redirect to properly forward a POST request (preserving the method and body)
* Some SASE solutions (for example, Zscaler) return an HTTP 302 for POST requests, which causes the npm client to drop the POST body and fail

By excluding POST from the redirect rule, `npm audit` traffic passes through your SASE directly to `registry.npmjs.org` without interception, allowing it to function normally.

### Commands Affected by Method Exclusion for npm

| Command                 | HTTP Method | Redirected? | Notes                             |
| ----------------------- | ----------- | ----------- | --------------------------------- |
| `npm install <package>` | GET         | Yes         | Primary use case                  |
| `npm view <package>`    | GET         | Yes         | Package metadata                  |
| `npm audit`             | POST        | No          | Passes through to public registry |
| `npm publish`           | PUT         | No          | Not redirected                    |
| `npm login`             | GET         | No          | Not redirected                    |

### Testing (npm)

**To verify npm traffic through PTC:**

1. Redirect: Run `npm install express --loglevel verbose` (or another public package) with SASE redirect rules active. In the output, confirm GET requests go to your Artifactory hostname / npm remote repository API path after the redirect, not only to the public registry.
2. Artifactory: In the UI, confirm `express` (and deps) appear in the npm remote cache (e.g. `npm-remote-registry`).
3. Curation (optional): **Curation** > **Audit** shows an Approved entry for the package when Curation is enabled.
4. Blocked package (optional): `npm install <blocked-package>` should fail with a policy violation when blocking policies apply.
5. POST passthrough: `npm audit` should still reach the public registry (POST not redirected).

npm installs through PTC are verified when GET traffic reaches Artifactory and `npm audit` still works.

***

## Python PyPI Configuration

### Intercept Settings for Python

| Setting          | Value                                                                                                                                                    |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| URLs to add      | `pypi.org`, `files.pythonhosted.org` (both are common; confirm in your traffic — see [Public Registry Hostnames](#public-registry-hostnames))            |
| Request Methods  | Start with GET and HEAD only on the redirect rule, same discipline as npm                                                                                |
| Excluded Methods | POST off the redirect unless you have explicitly validated a tool that must be redirected via POST (unusual for simple `pip install` / `uv pip install`) |

pip, Poetry, and uv mostly use GET for Simple API metadata and artifact downloads, but ecosystem tools evolve—if a command fails after enabling the redirect, inspect method and host in your SASE and adjust the rule or category.

### Trust Stores and Clients for Python

Use `scripts/README.md` for `REQUESTS_CA_BUNDLE`, `UV_NATIVE_TLS`, `SSL_CERT_FILE`, and version-specific notes for pip, Poetry, and uv. The SASE trust-store guidance linked from [Prerequisites](/security/docs/prerequisites-and-installation-script) also applies.

### Strict SSL Certificate Validation in Python Tools

Python-based package tools use Python's built-in `ssl` module for HTTPS connections, which requires certificates to be RFC 5280 compliant. If your SASE provider uses an older certificate that doesn't meet these requirements, some Python-based tools may encounter TLS errors.

This is not tied to a specific Python version — it depends on the combination of the certificate in use and the OpenSSL version Python was compiled against.

**Impact by tool:**

| Tool   | Non-compliant certificate                 |
| ------ | ----------------------------------------- |
| Poetry | May be affected (uses httpx → Python ssl) |

**Resolution:** Ask your SASE provider administrator to update the CA certificate to an RFC 5280 compliant version. Most providers have issued updated certificates since mid-2024 — once updated, all tools listed above should work without any further configuration.

### Configuring Artifactory to Support Poetry for PTC

**Poetry version 1.7.0 or later** is supported as a PyPI client for PTC. Earlier versions of Poetry are not supported. Because Poetry uses the PyPI Simple API with JSON responses, the Artifactory PyPI remote repository used as the PTC `repo_key` must have **JSON indexing enabled**.

**To enable JSON indexing on your PyPI repository:**

1. In the Administration module, navigate to **Artifactory Settings** > **Packages Settings**.
2. Under **PyPI**, select the **Enable simple json format** checkbox.
3. Click **Save**.

JSON indexing is enabled for Poetry and other JSON-aware PyPI clients using the PTC redirect path.

For full details on creating and configuring PyPI repositories and connecting Poetry to Artifactory, see [PyPI Repositories](/artifactory/docs/pypi-repositories#enable-json-indexing-in-pypi-repositories) in the JFrog documentation.

### Locks and Reproducibility for Python

As with npm, CI that does not traverse PTC may resolve artifacts differently than developer laptops. Align `requirements.txt`, Poetry, `uv.lock`, and pip-tools workflows across teams; watch for strict `pip install --require-hashes` or offline installs that assume direct PyPI URLs.

### Testing for Python

**To verify PyPI traffic through PTC:**

1. With your SASE and Artifactory configured for PyPI, run a public install, for example `pip install requests` or `uv pip install requests` (use the same tool your teams standardize on).
2. In Artifactory, confirm the package appears under the PyPI remote repository configured as the PTC `repo_key`.
3. If Curation is enabled on that remote, check **Curation** > **Audit** for an expected decision.

PyPI installs through PTC are verified when packages appear in Artifactory and optional Curation audit entries look correct.

***

***

## RubyGems Configuration

### Intercept Settings for RubyGems

| Setting          | Value                                                                                                                  |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------- |
| URLs to add      | `rubygems.org`, `api.rubygems.org`, `index.rubygems.org` (see [Public Registry Hostnames](#public-registry-hostnames)) |
| Request Methods  | GET and HEAD only                                                                                                      |
| Excluded Methods | POST (not used by gem or Bundler for package downloads)                                                                |

### Register RubyGems with Package Reroute

Create a RubyGems remote repository in Artifactory (package type: **Gems**, upstream URL: `https://rubygems.org`), then register it with the Package Reroute API:

```shell
curl -X PUT "https://<YOUR_ARTIFACTORY_URL>/artifactory/api/package-reroute/config/gems" \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"repo_key": "<YOUR_GEMS_REMOTE_REPO_KEY>"}'
```

Where:

* `<YOUR_ARTIFACTORY_URL>`: Your JFrog Platform hostname (for example `acme.jfrog.io`)
* `<TOKEN>`: Admin JWT or Basic auth credentials
* `<YOUR_GEMS_REMOTE_REPO_KEY>`: The key of your RubyGems remote repository

### Trust Stores and Clients for RubyGems

Ruby clients (gem, Bundler) use OpenSSL for HTTPS and read the SASE CA from the `SSL_CERT_FILE` environment variable.

| Platform                  | How to configure                                                                                                                                                                                                                                                                            |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Windows**               | Run `install_certs_windows.ps1 -Package ruby` (or `-Package all`). Sets `SSL_CERT_FILE` to the generated bundle.                                                                                                                                                                            |
| **Linux (Debian/Ubuntu)** | Run `install_certs_debian_ubuntu.sh` with `--package all`. Sets `SSL_CERT_FILE` to the system CA bundle — Ruby uses the same variable. (There is no separate `ruby` package flag on Linux; `--package all` is the correct option.)                                                          |
| **macOS**                 | The macOS install script does not include a Ruby package flag. Set `SSL_CERT_FILE` manually to the path of your SASE CA bundle (for example `export SSL_CERT_FILE=~/package-route.pem`). See [Configure Workstation for PTC](/security/docs/configure-workstation) for CA extraction steps. |

### Testing (RubyGems)

**To verify RubyGems traffic through PTC:**

1. With SASE redirect rules active, run `gem install <package> --verbose`. Confirm GET requests go to your Artifactory hostname after the redirect.
2. In Artifactory, confirm the gem appears in your RubyGems remote repository cache.
3. If Curation is enabled, confirm an Approved entry appears under **Curation > Audit**.

***

## Cargo (Rust) Configuration

### Intercept Settings for Cargo

| Setting          | Value                                                                                |
| ---------------- | ------------------------------------------------------------------------------------ |
| URLs to add      | `index.crates.io` only (see [Public Registry Hostnames](#public-registry-hostnames)) |
| Request Methods  | GET and HEAD only                                                                    |
| Excluded Methods | POST (not used by cargo for package fetching)                                        |

`index.crates.io` serves the sparse registry index (Cargo 1.68 and later). After the redirect, Artifactory's `config.json` response points crate downloads directly at the Artifactory Cargo API — `crates.io` and `static.crates.io` must **not** be on the SASE intercept list. Redirecting those hosts to `/artifactory/api/package-reroute` returns HTTP 400 (unknown registry).

### Register Cargo with Package Reroute

Create a Cargo remote repository in Artifactory (package type: **Cargo**, upstream URL: `https://crates.io`), then register it with the Package Reroute API:

```shell
curl -X PUT "https://<YOUR_ARTIFACTORY_URL>/artifactory/api/package-reroute/config/cargo" \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"repo_key": "<YOUR_CARGO_REMOTE_REPO_KEY>"}'
```

Where:

* `<YOUR_ARTIFACTORY_URL>`: Your JFrog Platform hostname (for example `acme.jfrog.io`)
* `<TOKEN>`: Admin JWT or Basic auth credentials
* `<YOUR_CARGO_REMOTE_REPO_KEY>`: The key of your Cargo remote repository

### Trust Stores and Clients for Cargo

Cargo uses Rust's native TLS implementation, which reads CA certificates from the OS trust store on all platforms. No additional environment variable or cert bundle configuration is required — standard OS-level trust (macOS Keychain, Windows Certificate Store, Linux system CA bundle) is sufficient when the SASE CA is installed at the OS level by your install scripts.

| Platform                  | How to configure                                                                                                                                                                    |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Windows**               | Ensure the SASE CA is in the Windows Certificate Store (Machine or User). The standard `install_certs_windows.ps1` installs the cert into the OS store as part of npm/Python setup. |
| **Linux (Debian/Ubuntu)** | Ensure the SASE CA is in the system trust store (the install script handles this).                                                                                                  |
| **macOS**                 | Ensure the SASE CA is trusted in the macOS Keychain. The install script exports from Keychain; Cargo reads from it natively.                                                        |

### Testing (Cargo)

**To verify Cargo traffic through PTC:**

1. With SASE redirect rules active, run `cargo fetch` or `cargo build` on a project with crates.io dependencies. Confirm requests go to your Artifactory hostname.
2. In Artifactory, confirm the crate appears in your Cargo remote repository cache.
3. If Curation is enabled, confirm an Approved entry appears under **Curation > Audit**.

***

## Go Configuration

### Intercept Settings for Go

| Setting          | Value                                                                                                                  |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------- |
| URLs to add      | `proxy.golang.org`, `sum.golang.org`, `index.golang.org` (see [Public Registry Hostnames](#public-registry-hostnames)) |
| Request Methods  | GET and HEAD only                                                                                                      |
| Excluded Methods | POST (not used by the Go client for module download)                                                                   |

`proxy.golang.org` serves module downloads, `sum.golang.org` serves checksum lookups, and `index.golang.org` serves the module index. One Go remote covers all three hosts. Developers keep the default `GOPROXY` (`https://proxy.golang.org,direct`) and `GOSUMDB` (`sum.golang.org`). The security edge redirects those requests to Artifactory.

### Register Go with Package Reroute

Create a Go remote repository in Artifactory (package type: **Go**, upstream URL: `https://proxy.golang.org`). In **Go Settings**, set **Git Provider** to **Artifactory**. Then register that remote with the Package Reroute API:

```shell
curl -X PUT "https://<YOUR_ARTIFACTORY_URL>/artifactory/api/package-reroute/config/go" \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"repo_key": "<YOUR_GO_REMOTE_REPO_KEY>"}'
```

Where:

* `<YOUR_ARTIFACTORY_URL>`: Your JFrog Platform hostname (for example `acme.jfrog.io`)
* `<TOKEN>`: Admin JWT or Basic auth credentials
* `<YOUR_GO_REMOTE_REPO_KEY>`: The key of your Go remote repository

The `repo_key` must be that remote repository. Package Reroute sends module requests to the remote directly, and Artifactory serves those requests when **Git Provider** is **Artifactory**.

### Trust Stores and Clients for Go

The `go` command uses the operating system trust store. When the SASE CA is installed at the OS level, no extra environment variable is required.

| Platform                  | How to configure                                                                                                                                        |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Windows**               | Ensure the SASE CA is in the Windows Certificate Store (Machine or User). The standard `install_certs_windows.ps1` installs the cert into the OS store. |
| **Linux (Debian/Ubuntu)** | Ensure the SASE CA is in the system trust store (the install script handles this).                                                                      |
| **macOS**                 | Ensure the SASE CA is trusted in the macOS Keychain. The `go` command reads that trust store.                                                           |

### Testing (Go)

**To verify Go traffic through PTC:**

1. With SASE redirect rules active, run `go mod download` in a module that depends on a public module. Confirm requests go to your Artifactory hostname.
2. In Artifactory, confirm the module appears in your Go remote repository cache.
3. If Curation is enabled, confirm an Approved entry appears under **Curation > Audit**.

***

## Maven Configuration

### Intercept Settings for Maven

| Setting          | Value                                                                                                    |
| ---------------- | -------------------------------------------------------------------------------------------------------- |
| URLs to add      | `repo1.maven.org`, `repo.maven.apache.org` (see [Public Registry Hostnames](#public-registry-hostnames)) |
| Request Methods  | GET and HEAD only                                                                                        |
| Excluded Methods | POST (Maven Central deploy is not a PTC use case)                                                        |

Add `repo1.maven.org` and `repo.maven.apache.org` to the SASE intercept list **after** you register Maven with Package Reroute (see [Register Maven with Package Reroute](#register-maven-with-package-reroute)). When a matching Central URL includes the `/maven2` prefix, Artifactory strips that prefix and serves the artifact from your Maven remote repository path.

The GA client for this path is `mvn` (and Maven Wrapper) against those two Maven Central hosts. Gradle, sbt, and Apache Ivy are not separate PTC package types. A Gradle (or sbt/Ivy) download is redirected only when the request host is already `repo1.maven.org` or `repo.maven.apache.org`.

Complete the Package Reroute `PUT` for `maven` before you enable the firewall intercept. If intercept is on and Maven is not registered, Artifactory returns HTTP 400 for Central the same way it does for an unknown host. See [HTTP 400 on Maven reroute](/security/docs/limitations-and-troubleshooting#http-400-on-maven-reroute).

### Register Maven with Package Reroute

Create a Maven remote repository in Artifactory (package type: **Maven**, upstream URL: `https://repo.maven.apache.org/maven2`), then register it with the Package Reroute API:

```shell
curl -X PUT "https://<YOUR_ARTIFACTORY_URL>/artifactory/api/package-reroute/config/maven" \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"repo_key": "<YOUR_MAVEN_REMOTE_REPO_KEY>"}'
```

Where:

* `<YOUR_ARTIFACTORY_URL>`: Your JFrog Platform hostname (for example `acme.jfrog.io`)
* `<TOKEN>`: Admin JWT or Basic auth credentials
* `<YOUR_MAVEN_REMOTE_REPO_KEY>`: The key of your Maven remote repository

This registration is mandatory. Do not enable SASE intercept for `repo1.maven.org` or `repo.maven.apache.org` until this call succeeds. Otherwise Central traffic that is redirected to PTC returns HTTP 400, which looks the same as an unsupported registry host.

### Trust Stores and Clients for Maven

Maven, Gradle, sbt, and Ivy use the JVM trust store. They do **not** pick up the npm or Python PEM environment variables from the standard install scripts. Use the **separate JVM installer family** in the [package-reroute README](https://github.com/jfrog/package-reroute/blob/main/README.md). Pair those scripts with `install_certs_macos.sh`, `install_certs_debian_ubuntu.sh`, or `install_certs_windows.ps1` when the same workstation also runs npm or Python.

| Platform                | How to configure                                                                                                                                                                                                                                                                                                                                                    |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **macOS**               | Run `install_certs_jvm_macos.sh --use-truststore <path-to-jks>`. Copies a JKS truststore and installs a per-user LaunchAgent (`com.jfrog.package-reroute.jto-env.plist`) that sets `JAVA_TOOL_OPTIONS` in the launchd `gui/<uid>` domain so Dock-launched IDEs inherit trust. This LaunchAgent is the macOS-specific step. Do not rely on `~/.zshrc` for JVM trust. |
| **Linux (generic)**     | Run `install_certs_jvm_linux.sh --use-truststore <path-to-jks>`. Installs the JKS at `/etc/ssl/package-route-jvm/truststore.jks` and sets `JAVA_TOOL_OPTIONS` in `/etc/environment`.                                                                                                                                                                                |
| **Linux (RHEL family)** | Run `install_certs_jvm_rhel.sh --use-cert <path-to-pem>`. Installs the SASE CA with `update-ca-trust extract` so Red Hat OpenJDK reads system trust. This path does not write `JAVA_TOOL_OPTIONS`.                                                                                                                                                                  |
| **Windows**             | Run `install_certs_jvm_windows.ps1 -UseTruststore <path-to-jks>`. Copies a per-user JKS under `%LOCALAPPDATA%` and sets User-scope `JAVA_TOOL_OPTIONS`. Administrator is not required.                                                                                                                                                                              |

Each customer builds and distributes the JKS. JFrog does not ship a prebuilt truststore. Use `build_jvm_truststore_macos.sh`, `build_jvm_truststore_linux.sh`, or `build_jvm_truststore_windows.ps1` as a working example: they import public roots plus your SASE CA. A JKS that contains only the corporate CA replaces the JVM default trust source and breaks TLS to Maven Central.

After install, quit and relaunch IDEs. Run `gradle --stop` if you use the Gradle Daemon. Open a new terminal (or log off and on) so existing processes reread `JAVA_TOOL_OPTIONS`. See [Configure Workstation for PTC](/security/docs/configure-workstation#jvm-clients-maven-gradle-sbt-ivy).

### Testing (Maven)

**To verify Maven traffic through PTC:**

1. With SASE redirect rules active, resolve a public Central artifact, for example `mvn -U dependency:get -Dartifact=junit:junit:4.13.2`. Confirm GET requests go to your Artifactory hostname after the redirect.
2. In Artifactory, confirm the artifact appears in your Maven remote repository cache.
3. If Curation is enabled, confirm an Approved entry appears under **Curation > Audit**.

***

## Docker, Hugging Face, and other types

**Docker**: Registry hostnames (Docker Hub, GHCR, and others) belong in your SASE intercept list when those clients are in scope. Container trust is not the host OS profile — see [Containers and Virtual Environments](/security/docs/configure-workstation#containers-and-virtual-environments) on the workstation configuration page, and Docker’s [Using Docker with Zscaler](https://docs.docker.com/guides/zscaler/) (written for Zscaler, but the same CA-trust pattern applies to any TLS-inspecting SASE proxy).

### Docker — clients verified by JFrog

The table below lists Docker clients currently covered in this documentation.

| Layer                                    | Clients                           | Status                                                                                  |
| ---------------------------------------- | --------------------------------- | --------------------------------------------------------------------------------------- |
| Container engines                        | OrbStack, Rancher Desktop, Colima | Verified                                                                                |
| Container engines                        | Docker Desktop                    | Commonly used with the same workflow; validate end-to-end in your environment           |
| CLI clients (on top of any engine above) | `docker`, `nerdctl`               | Verified                                                                                |
| Registry CLI / Libraries                 | `crane` (v0.21.8+)                | Verified (*Applies to `crane` and any client built on `go-containerregistry` ≥ 0.21.8*) |
| Not supported                            | Podman                            | Not supported for PTC as documented here                                                |

`crane` is a registry CLI built on Google’s `go-containerregistry` library (it shares that library’s versioning). It is not a container engine. Any Go application or CLI that uses `go-containerregistry` v0.21.8 or later is supported the same way.

If your standard client is not listed, validate in your environment and confirm support with your JFrog team.

* **Hugging Face**: Use [Hugging Face Repositories](/artifactory/docs/hugging-face-repositories) for remote repository layout and credentials. The PTC `repo_key` for `huggingfaceml` must be a Hugging Face remote repository. Add `huggingface.co` (and any CDN hosts your traces show) to your SASE intercept list when that traffic should be redirected. **Important:** the SASE redirect rule for Hugging Face must use **GET only** — do not include HEAD. This applies to all SASE providers (Zscaler, Netskope, Cloudflare, and others). Create a separate redirect rule or policy for `huggingface.co` distinct from npm/PyPI rules. Xet must be disabled on workstations using PTC for Hugging Face (`HF_HUB_DISABLE_XET=1`). For limitations (gated models, Xet, large-asset behavior), see [Hugging Face models and registry limitations](/security/docs/limitations-and-troubleshooting#hugging-face-models-and-registry-limitations).

***

***

## Frequently Asked Questions

This section provides answers to frequently asked questions about per-package-type configuration for Package Traffic Controller (PTC).

<Accordion title="FAQs" icon="plus">

##### Q: Why must npm redirect rules exclude POST requests?

**A:** `npm audit` sends POST to `registry.npmjs.org`. Redirecting POST breaks audit. Allow only GET and HEAD on the redirect rule. See [Why POST must be excluded (npm)](#why-post-must-be-excluded-for-npm).

##### Q: Which Docker container engines are verified for PTC?

**A:** This documentation covers OrbStack, Rancher Desktop, Colima, `docker`, and `nerdctl`. `crane` (v0.21.8+) and other clients built on `go-containerregistry` ≥ 0.21.8 are also verified as registry CLI / library clients—not as container engines. Podman is not supported. See [Docker — clients verified by JFrog](#docker-clients-verified-by-jfrog).

##### Q: How do I make npm work inside Docker containers behind SASE?

**A:** Bake or mount the SASE CA and set `NODE_EXTRA_CA_CERTS`. Containers do not inherit the host trust store automatically. See [Docker Configuration for npm (Node.js)](/security/docs/configure-workstation#docker-configuration-for-npm-nodejs).

##### Q: Why is `HF_HUB_DISABLE_XET=1` required for Hugging Face?

**A:** Hugging Face Xet is not supported through the PTC redirect flow. Set the variable on workstations using PTC for Hugging Face. See [Limitations and Troubleshooting](/security/docs/limitations-and-troubleshooting#hugging-face-models-and-registry-limitations).

##### Q: Why does macOS Maven need a LaunchAgent instead of shell profile exports?

**A:** Dock-launched IDEs do not read `~/.zshrc`. The JVM installer writes `JAVA_TOOL_OPTIONS` through a per-user LaunchAgent so IntelliJ and other GUI apps inherit the JKS path. See [Trust Stores and Clients for Maven](#trust-stores-and-clients-for-maven).

##### Q: Who builds the JVM truststore for Maven PTC?

**A:** Each customer builds and distributes the JKS. The `build_jvm_truststore_*` scripts in the [package-reroute README](https://github.com/jfrog/package-reroute/blob/main/README.md) are a working example. The truststore must include public roots and your SASE CA. See [Trust Stores and Clients for Maven](#trust-stores-and-clients-for-maven).

##### Q: Why does Maven Central through PTC return HTTP 400?

**A:** HTTP 400 on the reroute endpoint means Artifactory did not resolve a registered Maven registry for that host. Two common causes look the same: the intercept includes a host that is not `repo1.maven.org` or `repo.maven.apache.org`, or Maven was never registered with `PUT /artifactory/api/package-reroute/config/maven`. Register Maven first, then enable intercept. See [HTTP 400 on Maven reroute](/security/docs/limitations-and-troubleshooting#http-400-on-maven-reroute).

</Accordion>

## Related Topics

* [Package Traffic Controller (PTC) overview](/security/docs/package-traffic-controller)
* [Configure Artifactory for PTC](/security/docs/configure-artifactory)
* [Configure Zscaler ZIA](/security/docs/configure-zscaler-zia)
* [Configure Netskope](/security/docs/configure-netskope)
* [Limitations and Troubleshooting](/security/docs/limitations-and-troubleshooting)