# Environments

## Definition

An Environment represents a deployment stage or context within a Product. Environments isolate Version history, settings, automation rules, and policy evaluation so that different stages of your software lifecycle can be managed independently.

## Default Environments

Interlynk ships with three default Environments:

| Environment     | Purpose                                                              |
| --------------- | -------------------------------------------------------------------- |
| **Default**     | Catch-all for SBOMs uploaded without an explicit environment target. |
| **Development** | Feature branches, development builds, pre-merge artifacts.           |
| **Production**  | Release builds, production deployments, release-tagged artifacts.    |

Custom Environments are not supported. All Products use the same three default Environments.

## Isolation Behavior

Each Environment within a Product is fully independent:

* **Settings**: Import actions (vulnerability scanning, SBOM checks, automation rules) are configured per Environment.
* **Versions**: Each Environment maintains its own Version history. The same SBOM version string (e.g., `v1.2.0`) can exist in multiple Environments with different SBOMs.
* **Policies**: Policies can be scoped to specific Environments or applied across all Environments.
* **Automation Rules**: Rules are defined per Environment and do not cascade across Environments unless explicitly copied.

## Environment Settings Inheritance

```
Organization Defaults
  └── Environment Settings (per Environment)
```

1. When a new Environment is created, it inherits settings from **Organization Defaults** (see [Environment Defaults](https://docs.interlynk.io/administration/environment-defaults)).
2. After creation, Environment settings are **independent** — changes to Organization Defaults do not propagate to existing Environments unless the administrator explicitly clicks "Apply to All Projects."
3. Individual Environment settings can be customized at any time.

## Environment Rules

Environment rules automate the routing of SBOMs from source control events (pushes, pull requests) to the correct Environment. See [Environment Rules](https://docs.interlynk.io/administration/environment-rules) for details.

## Managing Environments

Every Product ships with the three default Environments. Environments cannot be added or removed.

**Via MCP:**

```
list_environments      # List environments for a product
get_environment        # Get environment details
```

### Configuring Environment Settings

1. Navigate to the **Product** detail page.
2. Select the target **Environment** from the environment selector.
3. Open the **Settings** tab.
4. Configure import actions, data retention, and scanning options.
5. Save changes.

## Promotion Workflows

Interlynk does not enforce a built-in promotion pipeline, but you can implement promotion workflows by:

1. **Uploading the same SBOM to successive Environments.** For example, upload to `development` during CI, then re-upload to `production` on release.
2. **Using Environment Rules** to automatically route SBOMs based on branch patterns (e.g., `feature/*` → development, `main` → production).
3. **Combining with policies** so that stricter policies in `production` act as promotion gates — SBOMs that fail production policies are flagged before deployment.

## Best Practices

* **Apply stricter policies in production.** Development Environments may warn on critical vulnerabilities; Production Environments should fail.
* **Enable vulnerability scanning in all Environments.** Catching vulnerabilities early in development reduces remediation cost.
* **Use Environment Rules for CI/CD.** Automate Environment routing based on branch patterns rather than relying on manual `--env` flags in every pipeline step.
* **Use the default Environment names consistently.** The three Environments (`default`, `development`, `production`) map to standard deployment stages. Use them consistently across Products so that organization-level policies and rules apply predictably.
* **Review Environment settings after applying Organization Defaults.** The "Apply to All Projects" action overwrites per-Environment customizations.

## Common Misconfigurations

| Issue                                             | Symptom                             | Fix                                                                                  |
| ------------------------------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------ |
| All SBOMs land in `default`                       | No environment-specific data        | Configure Environment Rules or add `--env` to CLI/CI commands                        |
| Vulnerability scanning disabled in an Environment | No vulnerability data after upload  | Enable "Run Vulnerability Scan" in Organization Defaults or per-Environment settings |
| Environment Rules wildcard at highest priority    | All events match the catch-all rule | Set wildcard rules to the lowest priority (highest number)                           |