> 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/introduction/seal-approach/sealing-approaches.md).

# How sealed packages are delivered

Seal delivers a sealed package in one of two technical ways, called **sealing approaches**. Both involve Seal building from source. They differ in where the artifact lands in your workflow.

## Build-time dependency sealing

The customer's build picks up the sealed dependency at build time. The build proceeds normally: the dependency manifest resolves to a sealed version, the code compiles against it, and the artifact your team ships incorporates it.

This is the path for application-dependency ecosystems: npm, pip, Maven, Gradle, Go modules, Composer, Bundler, NuGet.

## Post-build artifact sealing

Seal produces a fully built artifact that replaces an existing one in a built environment. There is no rebuild on the customer side. The sealed artifact takes the slot the vulnerable artifact had; nothing else changes in the surrounding image or filesystem.

This is the approach when a rebuild is not available or not practical. The most common cases are pre-built JARs and Python wheels inside containers, where the source for the build is not at hand or the build itself happened far upstream of the deployment.

## Which one applies

Seal Apps uses build-time dependency sealing.

Seal Vendor Apps and Seal My Container use post-build artifact sealing for pre-built artifacts inside container images (typically JARs and Python wheels).

## Related

* [The Seal product family](/introduction/product-family.md): which products use which approach.
* [Working with Seal Apps](/using-platform/working-with-seal-apps.md): the day-2 view of build-time dependency sealing in the application context.