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.

Recommended ordering

If more than one option is available to you, prefer them in this order.

1. Remote. Optimal. Centralized rule management, full automation, and no source-control changes required.

2. Local. Good. Rules are tracked in source via .seal-actions.yml, which suits teams that want every change reviewed in code.

3. Automatic Remediation. Suitable when no per-rule review is desired and every vulnerable package should be replaced. Less control, more coverage.

4. Artifact Server. Shallow. The Seal Platform sees only what your build pulls; manifest pinning is a manual maintenance burden, and discovery is correspondingly weaker. See the coverage caveats.

5. Manual. The most rudimentary usage. Works, but provides almost no platform value because Seal does not see what you are using. Typically used for evaluation or air-gapped environments.

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.

• Seal Apps in standalone on-prem environments: the setup chapter for Manual and air-gapped variants.

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