> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/setup-apps-os/artifact-server/jfrog-artifactory.md).

# JFrog Artifactory as your remote

Customers who already operate JFrog Artifactory typically integrate Seal as an additional remote in their existing Artifactory configuration, rather than pointing their package managers at Seal directly. Each Artifactory remote serves one ecosystem (npm, Maven, pip, and so on); Seal's per-ecosystem hosts fit that pattern.

The full setup walkthrough lives in [JFrog Artifactory: Seal as an additional remote](/integrations/artifactory.md). The integration is detailed enough that it has its own chapter in the [Integrations](/integrations/internal-scanners.md) section.

In brief, the steps are:

1. In Artifactory, create a new **Remote Repository** for each ecosystem you want Seal to serve.
2. Point the remote at the relevant Seal host ([Configuring package managers](/setup-apps-os/artifact-server/configuring-package-managers.md) lists them).
3. Set the username and password on the remote to the Seal Project ID and the production token, respectively.
4. Add the new remote to the **Virtual Repository** your developers' package managers already use, ordered as needed (see [Artifact server mode](/discovering/package-discovery-mode/artifact-server.md#what-it-sees) for the ordering's effect on Seal's discovery).

From the developer's perspective, nothing changes about their package manager configuration: it keeps pulling from the Artifactory virtual repository as before. The Seal remote sits inside Artifactory, transparent to the build.

## Project ID attribution

When a customer's package manager pulls directly from a Seal host, the Project ID rides in HTTP Basic auth (username) on each request, so different projects pulling through the same host are distinguished by username. JFrog does not pass the customer's HTTP Basic credentials through to its upstream; it authenticates to Seal using the credentials configured on the Artifactory remote itself. That alone would mean every pull through a given Artifactory remote arrives at Seal as the same Project ID, the one configured on that remote.

For **Maven**, Seal supports a URL-path-based mechanism that lets one Artifactory remote attribute pulls to different Seal Projects. The pattern: the URL the Artifactory remote is configured to forward to is `https://maven.sealsecurity.io/<project-tag>/-/`, with the literal Project ID embedded in the path before the `/-/` separator. Seal's Maven artifact server strips the prefix, uses the value as the Project ID for that request, and serves the rest of the path as a normal Maven URL. You can have many such Artifactory remotes (one per Seal Project) or, if your Artifactory setup supports templated remote URLs based on the request path, use a single remote that interpolates the Project ID per request.

For **other ecosystems** (npm, pip, Go, and the rest), the same path-based override is not currently exposed at the artifact server. Pulls through a single Artifactory remote for those ecosystems arrive at Seal as the single Project ID configured on the remote. To distinguish multiple Seal Projects in those ecosystems, configure a separate Artifactory remote (with its own Project ID and token) for each Seal Project, and route the relevant Artifactory virtual repository at the right remote.

## Related

* [JFrog Artifactory: Seal as an additional remote](/integrations/artifactory.md): the canonical setup home.
* [Configuring package managers](/setup-apps-os/artifact-server/configuring-package-managers.md): the per-ecosystem hosts that the JFrog remote points at.
* [Artifact server mode](/discovering/package-discovery-mode/artifact-server.md): the discovery-side picture and the effect of remote ordering inside Artifactory.