> ## Documentation Index
> Fetch the complete documentation index at: https://docs.envsecrets.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Secrets & Versions

> And how we define them on our platform.

## Defining a "secret"

The following is a single key-value pair:

```
API=https://api.example.com
```

However, the entire array comprising of **all key-value pairs** in an environment (of a project) is considered a single "secret."

<Info>
  This is in-line without how GCP and AWS define secrets as well.
</Info>

For example, the following payload is **a single secret**.

```
API=https://api.example.com
AUTH_URL=https://api.example.com/auth
STORAGE_URL=https://api.example.com/storage
```

## Versioning

### What is a "version" of a secret?

To update the aforementioned definition of a secret: *the entire array comprising of **all key-value pairs** in an environment (of a project) is considered **a single version** of a "secret."*

#### Example

<AccordionGroup>
  <Accordion title="Version 1">
    ```
    KEY_1=value_1
    ```
  </Accordion>

  <Accordion title="Version 2">
    ```
    KEY_1=value_1
    KEY_2=value_2
    ```
  </Accordion>

  <Accordion title="Version 3">
    ```
    KEY_1=value_1
    KEY_2=new_value_2
    ```
  </Accordion>
</AccordionGroup>

## Rollbacks

* You **cannot** edit existing version of a secret.
* Everytime you create/mutate your secrets, that change is reflected in a new version of your secret.
* In case you made a mistake, you can rollback the secret to a previous version with older values.

<Tip>
  In the `get`, `ls` and `run` commands of the CLI, you can use the `--version` flag to filter the version of the secret you want to execute the command for.
</Tip>

<Info>
  Changelogs are auto-generated whenever your team members mutate the secrets. This helps in auditing.
</Info>