> 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.md).

# Seal Apps via the Seal Artifact Server

Running your package manager against the Seal Artifact Server is how Seal Apps works when the Seal CLI cannot run inside your CI/CD pipeline. Your package manager pulls from the Seal Artifact Server (directly or as an additional remote), Seal serves sealed versions of the packages you have pinned to them, and your build proceeds with those sealed packages in place.

This chapter is the canonical setup home for the Artifact Server deployment method.

* [When to use this method](/setup-apps-os/artifact-server/when-to-use.md): the situations it fits, and the trade-offs versus the CLI-in-CI methods.
* [Configuring package managers](/setup-apps-os/artifact-server/configuring-package-managers.md): the per-package-manager configuration patterns.
* [Editing dependency files](/setup-apps-os/artifact-server/editing-dependencies.md): how manifest edits drive package replacement under this deployment method, with a pointer to the per-ecosystem syntax under [Working with Seal Apps](/using-platform/working-with-seal-apps.md).
* [Maven-specific server features](/setup-apps-os/artifact-server/maven-server-features.md): `+safest`, `+safest-until-<cutoff>`, and the redirect policy for non-sealed artifacts.
* [JFrog Artifactory as your remote](/setup-apps-os/artifact-server/jfrog-artifactory.md): when your existing JFrog Artifactory should fetch from Seal as an additional remote.

## Before you start

* A **production** [token](/getting-started/tokens.md) saved in your CI's secret manager (or your developer's secret store, for local builds against the Seal Artifact Server).
* The [Project ID](/getting-started/creating-a-seal-project.md#project-id-and-project-name) of the Seal Project you want this build's pulls attributed to.
* A package manager that can be pointed at a configurable remote (npm, Yarn, pnpm, pip, Poetry, Maven, Gradle, Go modules, Composer, Bundler, NuGet).

## How the deployment works

Seal serves packages from one host per ecosystem: `npm.sealsecurity.io` for npm-style ecosystems, `maven.sealsecurity.io` for JVM packages, `pypi.sealsecurity.io` for Python, and so on. These hosts are public and shared across all Seal customers; the credentials in your package manager's configuration are what identify your tenant and your Seal Project.

The build pulls from those hosts as a remote, with HTTP Basic authentication carrying the Project ID in the username and the token as the password. For sealed packages the customer has pinned in the manifest, the server returns the sealed artifact. For non-sealed packages, the server proxies to the public registry (npm registry, Maven Central, PyPi, and so on).

There is no Seal CLI step in this deployment. Sealing Rules in the platform are not applied here; the equivalent of a "rule" is the version pin in your manifest. Each customer-pinned sealed version travels with the manifest like any other dependency.

The full discovery-side picture (what Seal sees, the primary-vs-fallback configurations, caching caveats) is in [Configuring the Seal Artifact Server for discovery](/discovering/artifact-server-discovery.md) and [Artifact server mode](/discovering/package-discovery-mode/artifact-server.md).

## Related

* [Choosing your deployment method](/setup-apps-os/choosing-deployment-method.md): the decision page for the five deployment methods.
* [Configuring the Seal Artifact Server for discovery](/discovering/artifact-server-discovery.md): the discovery-side how-to that mirrors this chapter.
* [Generating and revoking tokens](/getting-started/tokens/generating-tokens.md): generating the production token used in the configuration below.