Choosing your deployment method

A decision page for the five Seal deployment methods, ordered by what they give you.

A Seal Project's deployment method is how Seal is integrated into the customer's environment: how sealed packages reach the build, and how Sealing Rules (or their absence) drive what gets replaced. Seal supports five deployment methods. The first three are flavors of the same setup ("the Seal CLI runs in CI/CD"); they differ only in the CLI fix mode the CLI is invoked with. The last two do not run the CLI in CI at all.

The five deployment methods

Deployment method	What runs in CI	Source of Sealing Rules
Remote	Seal CLI in remote mode	Sealing Rules from the Seal Platform UI
Local	Seal CLI in local mode	A .seal-actions.yml file checked into source
Automatic Remediation	Seal CLI in all mode	None: every vulnerable package is replaced automatically
Artifact Server	Nothing in CI; the Seal Artifact Server is a configured remote	Manifest pinning (the customer points specific versions at sealed counterparts in their dependency manifest)
Manual	Nothing in CI	None

If the Seal CLI can run in your CI/CD pipeline, the choice between Remote, Local, and Automatic Remediation is a single CLI flag: the same install, the same token, the same pipeline step, with a different fix-mode value. Switching between them later is a one-line change. The choice between CLI-in-CI and Artifact Server (or Manual) is the larger decision, because it changes what is set up where.

A decision tree

Two questions narrow the choice:

1. Can the Seal CLI run in your CI/CD pipeline?

   • Yes → run the CLI. Then pick the fix mode that fits where you want your Sealing Rules:

     • In the Seal Platform UI, managed centrally → remote fix mode → Remote.

     • In .seal-actions.yml files version-controlled with the code → local fix mode → Local.

     • No rules; replace every vulnerable package → all fix mode → Automatic Remediation.

   • No → continue to question 2.

2. Can your package manager be pointed at a configured remote?

   • Yes → Artifact Server.

   • No → Manual.

Who runs each method

A bigger factor than the technical setup is which team is going to operate the deployment day to day. The five methods differ on whether developers, the security team, or no one in particular has to act for a remediation to land.

• Remote: best for security teams who want to remediate independently. The team creates Sealing Rules in the Seal Platform UI, the next CLI run picks them up, the build ships sealed packages. No pull request, no waiting for a developer to merge. Rules are not tracked in source control, which is a slight loss in auditability traded for the agility to actually fix problems instead of nagging developers to prioritize them.

• Local: best for developers who want to be hands-on and keep the remediation process in their own change-review flow. Every Sealing Rule is a change to .seal-actions.yml, which means every Sealing Rule is a pull request. The plus side is that the rules are tracked in source control alongside the code. The down side is that anyone without merge rights, the security team in most organizations, has to go through someone with merge rights to land a rule. Local is most workable when the developers themselves are the ones adopting Seal.

• Automatic Remediation: requires no action from anyone in particular. The CLI runs in CI with --mode all, every vulnerable package is replaced. Useful when the policy is "always seal what we can" and there is no per-rule review to manage.

• Artifact Server: like Local in that the developers have to change the manifest and merge it; unlike Local in that there is no Sealing Rule abstraction, the manifest pinning is the rule. Same coordination cost as Local, with weaker discovery on top.

• Manual: the most labor-intensive for developers. Each fix is a download from the Repository page and a manual replacement of the artifact. Requires high technical knowledge and is the heaviest operational lift of the five methods, but customers do use it at scale when their environment leaves no other option.

Our recommendation, when more than one option fits

All five methods are workable at scale. When more than one is available to you, the one we recommend reaching for first is the one closest to the top of this list. The others remain perfectly good choices, and the right one for your environment is the one you can actually adopt.

1. Remote. Lets security teams remediate independently, and works fine for developer-led teams as well.

2. Local. Suits developer-led teams that want every change reviewed in source. The pull-request flow adds coordination cost when the security team does not have merge rights.

3. Automatic Remediation. The right fit when the policy is "seal everything we can" and there is no per-rule review to manage.

4. Artifact Server. The choice when the Seal CLI cannot run in your build. Discovery is weaker than the CLI-in-CI methods, as covered in the coverage caveats, and rules live in the manifest as pins rather than as Sealing Rules in the platform.

5. Manual. The right choice when nothing else fits the environment, including air-gapped environments and component handoffs from teams you do not own. Heavier developer effort per remediation than any of the others, but viable at any volume.

Trade-offs the choice drives

• Discovery accuracy. Remote, Local, and Automatic Remediation all run the CLI in CI, which feeds CLI-mode discovery (or source-code mode if SCM is also connected). Artifact Server feeds artifact-server-mode discovery, with weaker coverage. Manual feeds nothing.

• Where rules live. Remote rules live in the Seal Platform UI; Local rules live in source; Automatic Remediation has no rules; Artifact Server uses manifest pinning instead of rules; Manual has no rules.

• What needs to change in your build. The three CLI-in-CI methods all need the Seal CLI installed in CI plus a Seal Project's token. They differ only in the CLI's fix-mode flag: Remote runs the CLI with remote, Local with local, Automatic Remediation with all. Artifact Server needs your package manager configured to use the Seal Artifact Server. Manual needs nothing in CI; you download artifacts on demand.

• Whether automatic PRs are available. The GitHub automatic-PR feature writes proposed Sealing Rules into .seal-actions.yml, which only takes effect under Local. Automatic PRs are not relevant to Remote, Automatic Remediation, Artifact Server, or Manual.

Mixing methods

A tenant with multiple Seal Projects can use different deployment methods per project. This is common in larger organizations: a flagship application uses Remote, a small internal tool uses Local because its team wants their rules in source, and a vendor-built component running in air-gapped infrastructure uses Manual. Each Seal Project records its own method, and the deployment method does not propagate.

Related

• Seal Apps via the Seal CLI in CI/CD: the setup chapter for the three CLI-in-CI methods (Remote, Local, Automatic Remediation).

• Seal Apps via the Seal Artifact Server: the setup chapter for Artifact Server.

• On-prem and air-gapped environments: the setup chapter for environments where hosts cannot reach Seal directly. Covers both Seal Apps and Seal OS.

• Package discovery mode: how each deployment method's discovery side shows up in the Seal Platform.

• Network requirements: the hostnames every deployment method needs reachable.