> 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/when-to-use.md).

# When to use this method

The Artifact Server deployment method is the right choice when your build cannot run the Seal CLI but can be pointed at a configured remote. Common situations:

* The build pipeline is owned by a team you do not have permission to modify (a vendor pipeline, a contracted operations team).
* The build runs in a sandboxed CI environment that does not allow executing arbitrary binaries.
* The build is implemented through tools that orchestrate package-manager operations directly without an obvious place to insert an additional CLI step.
* You are integrating Seal into an existing remote-server-based workflow (for example, a [JFrog Artifactory](/setup-apps-os/artifact-server/jfrog-artifactory.md) tenant that already configures upstream remotes for each ecosystem) and want Seal to fit in the same pattern.

## What you trade for what

Choosing the Artifact Server deployment shapes a few things differently from the CLI-in-CI methods:

* **No Sealing Rules**. Rules in the Seal Platform UI and in `.seal-actions.yml` are not consulted; the equivalent is the version pin in your manifest. To use a sealed version, the customer names the sealed version directly in `package.json` / `pom.xml` / `requirements.txt` / and so on.
* **Discovery is per-pull**. Seal sees what the build pulls, not what the manifest declares. The picture builds up over time rather than reflecting the latest commit, and the configurations described in [Artifact server mode](/discovering/package-discovery-mode/artifact-server.md) determine whether Seal sees only sealed-version requests or every pull. Read that chapter for the coverage caveats.
* **No automatic remediation**. Each sealed version landing in the build is the result of a manifest edit by a developer or by a generated PR. There is no Seal CLI pass that replaces vulnerable packages without manual intervention.
* **Developer effort per remediation**. Editing the manifest, opening a pull request, going through review and merge is on the customer's side for each fix. CLI-in-CI methods can fold that in.

The trade-offs above are the ones to plan for if you choose this method.

## Related

* [Choosing your deployment method](/setup-apps-os/choosing-deployment-method.md): the broader decision page.
* [Editing dependency files manually](/setup-apps-os/artifact-server/editing-dependencies.md): the manifest-pinning side of the workflow.
* [Configuring package managers](/setup-apps-os/artifact-server/configuring-package-managers.md): the remote-configuration side of the workflow.