When to use this method

When the Artifact Server deployment method is the right fit, and the trade-offs versus the CLI-in-CI methods.

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 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 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: the broader decision page.

• Editing dependency files manually: the manifest-pinning side of the workflow.

• Configuring package managers: the remote-configuration side of the workflow.