# Choosing your deployment method

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](/new-documentation/new-docs/creating-a-seal-project.md#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](/new-documentation/new-docs/package-discovery-mode/artifact-server.md).
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](/new-documentation/new-docs/package-discovery-mode/cli.md) (or source-code mode if SCM is also connected). Artifact Server feeds [artifact-server-mode discovery](/new-documentation/new-docs/package-discovery-mode/artifact-server.md), 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](/new-documentation/new-docs/tokens.md). 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](/new-documentation/new-docs/connecting-source-control/github.md#automatic-pull-requests) 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](https://github.com/seal-community/gitbook/blob/main/new-docs/setup-apps-os/cli-in-cicd/README.md): the setup chapter for the three CLI-in-CI methods (Remote, Local, Automatic Remediation).
* [Seal Apps via the Seal Artifact Server](https://github.com/seal-community/gitbook/blob/main/new-docs/setup-apps-os/artifact-server/README.md): the setup chapter for Artifact Server.
* [Seal Apps in standalone on-prem environments](https://github.com/seal-community/gitbook/blob/main/new-docs/setup-apps-os/standalone-on-prem/README.md): the setup chapter for Manual and air-gapped variants.
* [Package discovery mode](/new-documentation/new-docs/package-discovery-mode.md): how each deployment method's discovery side shows up in the Seal Platform.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sealsecurity.io/new-documentation/new-docs/choosing-deployment-method.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.