> 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/maven-server-features.md).

# Maven-specific server features

Beyond serving the standard Maven protocol, the Seal Artifact Server exposes two Maven-only conveniences for pinning to a safest sealed version directly from your POM, plus a per-tenant control over what happens when the server is asked for an artifact it does not host.

This page assumes Maven is already pointed at the Seal Artifact Server. See [Configuring Maven](/setup-apps-os/artifact-server/configuring-package-managers/maven.md) for the basic setup.

## Pinning to the latest safest sealed version with `+safest`

Append `+safest` to the version of any dependency you want resolved against the latest sealed sibling of that origin version:

```xml
<dependency>
  <groupId>org.apache.commons</groupId>
  <artifactId>commons-text</artifactId>
  <version>1.10.0+safest</version>
</dependency>
```

The Seal Artifact Server returns a relocation POM that points your build at the currently-recommended sealed sibling for `commons-text` `1.10.0` (for example, `1.10.0+sp3` if that is the latest iteration). The next time Seal publishes a newer sealed iteration (`+sp4`, `+sp5`), the next build picks it up automatically without a POM change.

If no sealed sibling exists for the requested origin version, the response resolves back to the origin version itself, so your build does not break.

This is a build-time alternative to tracking the safest sealed version through a Sealing Rule: both achieve the same outcome (your build always pulls the latest safest sealed iteration), but `+safest` lives in your POM whereas a safest-tracking Sealing Rule lives in the Seal Platform.

## Pinning to a safest sealed version up to a cutoff date with `+safest-until-<cutoff>`

Some build environments require reproducibility: locking the set of sealed packages to whatever was the safest available at a known good date, and treating any newer sealed iterations as out of scope until the lock is updated. Regulated builds with audit requirements are the typical case.

Append `+safest-until-<cutoff>` to pin against the safest sealed iteration Seal had published by the cutoff:

```xml
<dependency>
  <groupId>org.apache.commons</groupId>
  <artifactId>commons-text</artifactId>
  <version>1.10.0+safest-until-20260415T000000Z</version>
</dependency>
```

The cutoff is a compact ISO 8601 timestamp in UTC: `YYYYMMDDTHHMMSSZ`. The example above means "the safest sealed iteration of `commons-text@1.10.0` whose publish timestamp is on or before `2026-04-15 00:00:00 UTC`."

Seal evaluates eligibility against the published timestamps of the sealed iterations, picks the most recently published one that is on or before the cutoff (preferring public over private versions), and returns a relocation POM pointing at it. If no sealed iteration satisfies the cutoff, the response resolves back to the origin version.

Update the cutoff in your POM when you choose to advance the lock; until you do, every build resolves to the same sealed iteration.

## Redirect policy for non-sealed artifacts

When the Seal Artifact Server is asked for an artifact it does not host (a package or version Seal has not produced a sealed sibling for), the default behavior is to redirect the client to Maven Central with HTTP 307. This keeps standard builds working without configuration changes: Seal serves what it has, Maven Central serves the rest.

For environments that source from an internal Maven mirror rather than Maven Central (for example, organizations standardized on Cloudera or another internal repository), this implicit redirect is wrong: it sends the client past the configured internal mirror straight to Maven Central. The Seal Artifact Server supports a per-tenant **no-redirect** mode that returns HTTP 404 instead of redirecting, letting the Maven client fall through to the next repository in its own configured order.

The no-redirect mode is set at the tenant level and is not a per-build choice. Contact your Seal account team to enable it for your tenant if your build infrastructure depends on an internal Maven mirror.

## Related

* [Configuring Maven](/setup-apps-os/artifact-server/configuring-package-managers/maven.md): the basic setup that points Maven at the Seal Artifact Server.
* [Editing dependency files manually](/using-platform/working-with-seal-apps/artifact-server/maven.md): pinning specific sealed versions in `pom.xml`, including transitive overrides through `<dependencyManagement>`.