> 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/manual.md). # Under Manual In the Manual deployment method, nothing about Seal runs in your CI/CD pipeline. You go to the [Repository page](/discovering/repository-page.md), find the sealed version you want, download it, and host it yourself (or apply it directly into a build that pulls from your hosted location). Manual is the deployment method for environments where neither the Seal CLI nor the Seal Artifact Server is reachable — typically standalone on-prem and air-gapped builds. Because nothing reports back to Seal, the Protection page does not show your usage. The day-2 rhythm is correspondingly different from the other four methods. ## The recurring rhythm The four steps from [Working with the platform](/using-platform/working-with-the-platform.md) adapt to a flow that runs through Seal's public Repository page and your internal artifact server: 1. **Review** what is vulnerable. With Manual, Seal does not discover your packages, so the Vulnerable packages tab does not list them. You review through whatever external scanner or SBOM tool you already run, or you use the [Free assessment](/discovering/repository-page/free-assessment.md) to spot-check a manifest. The set of vulnerable packages and the choice of which to seal is owned externally. 2. **Decide what to seal** by picking the sealed version from the [Repository page](/discovering/repository-page/sealed-packages.md). Each package's detail page shows the available `-sp[N]` iterations. 3. **Download the sealed artifact.** The Download dialog on the per-package page gives you the file (the `.tgz`, `.whl`, `.jar`, or equivalent for the ecosystem). 4. **Host or use it.** Put the file on your internal artifact server or hand it directly to the build that needs it. See [On-prem and air-gapped environments](/setup-apps-os/on-prem.md) for hosting patterns. There is no "verify" step inside Seal; verification happens in your downstream build (the dependency resolves to the sealed version you placed in your internal artifact server) or by your downstream scanner picking up the new SBOM.
The Download dialog on a sealed package's detail page on the Repository page

The Download dialog is the customer's entry point under Manual.

## When Seal publishes a newer iteration Manual has no automatic rollover. When Seal publishes `sp2` after `sp1`, you find out by: * Browsing the Repository page and noticing the new iteration on the package's detail page. * Whatever external tracking your team has in place (RSS-equivalent watch on the Repository, asking your Seal account team, and so on). Email notifications about newly available sealed versions are tied to what Seal can see you using on the Protection page. Under Manual, the platform has no visibility into your environment, so these notifications do not fire. To move to the new iteration, repeat the download-and-host cycle for the new `-sp[N]` and update your internal artifact server. ## Common situations ### A new vulnerability is disclosed in a package you already use You learn about this from your external scanner or vulnerability feed, not from the Seal UI. Once you know, check the Repository page for a sealed iteration that addresses it. If one exists, download and host it. If Seal needs to publish a new iteration, ask your Seal account team for the expected timeline. ### A developer adds a new vulnerable dependency Same path: your external discovery finds it, you check the Repository page, you download the sealed version, you place it on your internal artifact server, the build pulls from your server. The dev's PR does not show up anywhere in the Seal UI. ### A build pulls the wrong version after the artifact server is updated Look at your internal artifact server's logs, not at the Seal UI. The build is pulling from your server now, so Seal has no visibility into the build at all. The likely causes are: a stale cache in the build environment, a manifest still pinning the older version, or the new sealed artifact landing under a different identifier than the build expects. ## Related * [The Repository page](/discovering/repository-page.md): the day-2 entry point for browsing and downloading sealed versions. * [On-prem and air-gapped environments](/setup-apps-os/on-prem.md): the setup-side hosting patterns Manual relies on. * [Free assessment](/discovering/repository-page/free-assessment.md): the one-shot coverage check. * [Notification Center](/using-platform/notification-center.md): the email opt-in for new sealed version availability.