> 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/using-platform/working-with-seal-apps/artifact-server.md).

# Under Artifact Server

In the Artifact Server deployment method, nothing Seal-specific runs in your CI: your package manager is configured to pull from the Seal Artifact Server, and the manifest tells the build which sealed versions to use. To remediate a vulnerable package, you edit the manifest to pin the sealed version (for example, `2.7.4-sp1` instead of `2.7.4`); the next build pulls the sealed artifact in place of the public origin.

## The recurring rhythm

The four steps from [Working with the platform](/using-platform/working-with-the-platform.md), specialized for Artifact Server:

1. **Review** what is vulnerable. Discovery for an Artifact-Server-only Seal Project is limited to what the artifact server itself sees — only packages the build has pulled at least once. The Vulnerable packages tab reflects that. For a more complete picture, either connect source control as a secondary discovery signal, or run an [imported-manifest upload](/discovering/importing-manifests.md) periodically.
2. **Decide what to seal.** For each package you want to seal, edit the manifest to pin the sealed version. See the per-ecosystem pages below.
3. **Let the next build run.** The build resolves the new pin and the package manager fetches the sealed artifact from the Seal Artifact Server.
4. **Verify** by reading your build's resolved-dependency report (the lockfile or the build log). On the Seal side, the Vulnerable packages tab will eventually reflect the change after the artifact server observes the new pull; this can lag by hours depending on cache behavior.

## Direct dependencies vs transitive dependencies

For dependencies you list directly in your manifest, pinning is straightforward — change the version range to the sealed `-sp[N]`. The per-ecosystem pages below cover the syntax.

Transitive dependencies are harder. When the vulnerable package is brought in by another package, editing your own dependencies section does nothing: the upstream dependency still asks for the vulnerable version. Each ecosystem has a different mechanism for forcing a transitive resolution, and not every ecosystem has a clean one. The per-ecosystem pages cover the mechanism for each, including the ecosystems where the only option is to add the package as a direct dependency yourself.

The sealed version of a package is fully compatible with its specific origin version only. Overrides therefore have to be version-specific: pair the origin version with the matching sealed version, and leave other versions of the same package untouched.

## When Seal publishes a newer iteration

Artifact Server has no automatic rollover for pinned versions. When Seal publishes `sp2` for a package whose manifest entry points at `sp1`, the build keeps pulling `sp1` until you edit the manifest.

The Maven ecosystem has an exception: the `+safest` version suffix on `maven.sealsecurity.io` always resolves to the safest published iteration for that origin version, so a Maven build pinning `2.7.4+safest` automatically picks up `sp2` when it ships. See [Maven-specific server features](/setup-apps-os/artifact-server/maven-server-features.md). No other ecosystem has a comparable mechanism today; everywhere else, pinned means literally pinned.

## Per-ecosystem editing details

The exact syntax for pinning sealed versions and forcing transitive overrides depends on the package manager.

| Ecosystem  | Page                                                                                                | Transitive override covered?        |
| ---------- | --------------------------------------------------------------------------------------------------- | ----------------------------------- |
| npm        | [Editing npm dependencies](/using-platform/working-with-seal-apps/artifact-server/npm.md)           | Yes (`overrides`)                   |
| Yarn       | [Editing Yarn dependencies](/using-platform/working-with-seal-apps/artifact-server/yarn.md)         | Yes (`resolutions`)                 |
| pnpm       | [Editing pnpm dependencies](/using-platform/working-with-seal-apps/artifact-server/pnpm.md)         | Yes (`pnpm.overrides`)              |
| Maven      | [Editing Maven dependencies](/using-platform/working-with-seal-apps/artifact-server/maven.md)       | Yes (`<dependencyManagement>`)      |
| Gradle     | [Editing Gradle dependencies](/using-platform/working-with-seal-apps/artifact-server/gradle.md)     | Direct only                         |
| Go modules | [Editing Go dependencies](/using-platform/working-with-seal-apps/artifact-server/go.md)             | Direct only                         |
| pip        | [Editing pip dependencies](/using-platform/working-with-seal-apps/artifact-server/pip.md)           | Yes (pin as direct)                 |
| Poetry     | [Editing Poetry dependencies](/using-platform/working-with-seal-apps/artifact-server/poetry.md)     | Direct only                         |
| Bundler    | [Editing Bundler dependencies](/using-platform/working-with-seal-apps/artifact-server/bundler.md)   | Yes (add `gem` entry)               |
| NuGet      | [Editing NuGet dependencies](/using-platform/working-with-seal-apps/artifact-server/nuget.md)       | Yes (explicit `<PackageReference>`) |
| Composer   | [Editing Composer dependencies](/using-platform/working-with-seal-apps/artifact-server/composer.md) | Direct only                         |

## Editing the lockfile by hand

For ecosystems with a lockfile (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, `Pipfile.lock`, `Gemfile.lock`, `go.sum`), the package manager normally regenerates the lockfile when you change the manifest. Most of the time this is fine.

When it is not, you may have to edit the lockfile by hand. Two common causes:

* The build environment uses a frozen-lockfile flag (`npm ci`, `yarn install --frozen-lockfile`, `pnpm install --frozen-lockfile`) and refuses to regenerate. In that case, regenerate locally with the relaxed install command, commit the new lockfile, and let CI run with the frozen flag against the new file.
* The lockfile contains an integrity hash that does not match the sealed artifact. The sealed package is published with the public registry's checksum format, so this is rare today, but if it occurs, recompute the hash with the package manager's normal tooling and commit the updated lockfile.

## Common situations

### A new vulnerability is disclosed in a package you already use

You see the row on the Vulnerable packages tab. Find the sealed iteration that addresses it on the [Repository page](/discovering/repository-page/sealed-packages.md) or in the package's drawer on the Protection page, then pin the new version in your manifest. The next build pulls the new artifact.

### A developer adds a new vulnerable dependency

The next build pulls the public version (no override exists yet). The package shows up on the Vulnerable packages tab once the artifact server sees the pull. Edit the manifest to pin the sealed version.

### A build pulls the wrong version after a manifest edit

* Check the manifest in the branch that built. The most common cause is the change landing on a different branch than CI expected.
* Check the lockfile. A stale lockfile can override the manifest pin if the build uses a frozen-lockfile flag. Regenerate the lockfile locally and commit it.
* Check your package-manager registry config. If the build is still pointed at the public registry rather than the Seal Artifact Server, the pinned `-sp[N]` version does not resolve and the build either falls back to the origin or fails outright depending on the manager. See [Configuring package managers](/setup-apps-os/artifact-server/configuring-package-managers.md).

## Related

* [Seal Apps via the Seal Artifact Server](/setup-apps-os/artifact-server.md): the setup chapter that points your package managers at Seal.
* [Configuring package managers](/setup-apps-os/artifact-server/configuring-package-managers.md): per-package-manager registry setup.
* [Maven-specific server features](/setup-apps-os/artifact-server/maven-server-features.md): Maven's `+safest` and `+safest-until-<cutoff>` suffixes.
* [The Repository page](/discovering/repository-page.md): the catalog of available sealed versions.