# 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](/administration/environment-defaults.md)).
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](/administration/environment-rules.md) 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)                           |


---

# 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.interlynk.io/interlynk-core-concepts/environments.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.