# Choosing Your Deployment Method

The Seal platform is designed to adapt to your organization's unique processes. The most critical factor in choosing your deployment method is deciding on the desired level of automation and the distribution of responsibility between your security and development teams.

#### Recommended Workflow: CLI Integration

For the smoothest, most automated, and most efficient experience, we highly recommend integrating the Seal CLI directly into your CI pipeline. This approach eliminates the need for manual dependency changes and unlocks the three automated *Sealing Methodologies*.

#### CLI Integration Deployments (High Automation)

These deployments require the Seal CLI to be integrated into your CI/CD pipeline. The CLI is responsible for cleanly and automatically applying security fixes as configured.

[**Automatic Remediation**](https://docs.sealsecurity.io/fundamentals/deployments/automatic-remediation)

This is the **fully automated** deployment model, offering the fastest time-to-fix for newly disclosed vulnerabilities.

* Workflow: Vulnerable packages are automatically replaced with their sealed versions whenever the CI runs. No manual interference or configuration changes from developers or the security team are typically needed.
* Control & Responsibility: Provides the highest level of automation, guaranteeing your application is always up-to-date with the latest patches. All that's required is deploying the sealed version to production.

[**Remote Configuration**](https://docs.sealsecurity.io/fundamentals/deployments/remote-configuration)

This model provides **high automation** while keeping the security team fully in control of which fixes are applied.

* Workflow: Vulnerable packages are sealed according to remediation rules set by the **Security Team** through Seal's centralized web interface. The fixes are applied by the CLI during the build.
* Control & Responsibility: The Security Team defines the rules and can fix vulnerabilities independently from the developers. Critically, there is no Pull Request (PR) created, and the changes are not tracked in the source control's commit history, streamlining the security patch process.

[**Local Configuration**](https://docs.sealsecurity.io/fundamentals/deployments/local-configuration)

This deployment integrates sealing directly into the standard developer workflow, ensuring full source control visibility and developer sign-off.

* Workflow: Vulnerable packages are sealed based on remediation rules defined by **Developers** in each project’s local configuration file.
* Control & Responsibility: Developers have control over what is sealed. Every update to the local configuration file requires a Pull Request (PR) and a commit to the source control, ensuring full auditability. *Note: The Seal App can be connected to your source control to automatically create these PRs instead of requiring developers to create them manually.*

#### 2. Artifact Server Deployment (Manual)

This option provides maximum developer control without requiring the integration of the Seal CLI into your CI pipeline.

[**Manually Editing Dependencies**](https://docs.sealsecurity.io/fundamentals/deployments/artifact-server)

* Configuration: For this method, you must configure Seal as your artifact server for dependency resolution, or as an additional remote of your existing artifact server.
* Workflow: When a vulnerability is remediated, developers are responsible for manually editing the project's dependency manifest (e.g., `package.json`, `pom.xml`) to explicitly reference the sealed package version.
* Control & Responsibility: This gives the developers full control over version selection. However, it requires the most effort and can be technically challenging when dealing with updating transitive dependencies (dependencies of your dependencies) in some package managers.

#### Summary table: Deployment Comparison

| Feature              | Automatic Remediation        | Remote Configuration                     | Local Configuration              | Artifact Server                   |
| -------------------- | ---------------------------- | ---------------------------------------- | -------------------------------- | --------------------------------- |
| **CI Integration**   | Required                     | Required                                 | Required                         | Not required                      |
| **Control Owner**    | Security Team                | Security Team                            | Developers                       | Developers                        |
| **Sealing Rules**    | Automated                    | <p>Centralized,</p><p>on Seal Server</p> | Local configuration file         | Manual dependency file edits      |
| **Developer Effort** | None                         | None                                     | Moderate (PR Review / Merge)     | Highest (Manual dependency edits) |
| **Key Benefit**      | Maximum automation and speed | Centralized security control & speed     | Developer sign-off & audit trail | No CI integration required        |