# Environments

Managing environments for different stages of development.

Source: https://keyenv.dev/docs/web-app/environments/

Environments allow you to maintain separate sets of secrets for different stages of your development workflow.

## Default Environment

When you create a project, a `development` environment is created by default. You can add additional environments like `staging` and `production` as needed.

| Environment | Purpose |
|-------------|---------|
| `development` | Local development and testing |
| `staging` | Pre-production testing |
| `production` | Live application |

## Switching Environments

Use the environment tabs at the top of the secrets page to switch between environments.

Each environment maintains its own:
- Secret values
- Version history
- Access logs

## Environment Isolation

Secrets are completely isolated between environments:

```
# development
DATABASE_URL=postgres://localhost/mydb_dev

# staging
DATABASE_URL=postgres://staging-server/mydb_staging

# production
DATABASE_URL=postgres://prod-server/mydb_prod
```

This ensures you never accidentally use production credentials in development.

## Environment Permissions

Control who can access each environment with granular permissions.

### Permission Levels

| Role | Description |
|------|-------------|
| `none` | No access to the environment |
| `read` | Can view secrets (pull, list, get) |
| `write` | Can view and modify secrets (create, update, delete) |
| `admin` | Full access including managing other users' permissions |

### Managing Permissions

1. Navigate to an environment in your project
2. Click the **⋮** menu next to the environment tabs
3. Select **Manage Access**
4. Add team members and assign their permission level

> **Note**
>
> Team admins automatically have full access to all environments.

### Default Permissions

Set default permissions for new team members in **Project Settings → Default Permissions**. When a new member joins the team, they'll automatically receive these permissions for each environment.

## Best Practices

1. **Never copy production secrets to development** - Use separate credentials for each environment
2. **Use similar key names** - Keep the same keys across environments for consistency
3. **Document differences** - Use descriptions to note environment-specific requirements
4. **Restrict production access** - Use environment permissions to limit who can view production secrets
5. **Use read-only for CI/CD** - Service tokens for CI/CD only need `read` access

> **Note**
>
> The CLI defaults to the `development` environment. Use the `-e` flag to target other environments.