Team environment management
Environment variable management for teams
RunEnv gives engineering teams a controlled place to organize environment variables and secrets across projects, environments, and the tools used to ship software. Replace ad-hoc .env sharing with a workflow people can inspect and operate.
The workflow
A clearer operating model for configuration.
Each page is grounded in a workflow RunEnv supports today. Use the examples and documentation links to decide whether the model fits your team.
Move beyond shared .env files
A local .env file is useful for a first prototype, but it does not show who changed a value, which environment it belongs to, or whether another teammate is working from an outdated copy. RunEnv keeps configuration in a project and environment model that the team can operate together.
- Keep development, staging, production, and custom environments distinct.
- Manage secret metadata and values from the dashboard with scoped access.
- Use audit history to understand changes instead of comparing anonymous files.
Give each environment a clear boundary
Teams can link a repository to a selected project and environment, then run the application with the context that belongs to that workflow. The same project model supports local development, staging checks, and production operations without mixing credentials by accident.
- Use `development` for local work and `staging` for pre-production checks.
- Select an environment explicitly with the CLI when a workflow needs an override.
- Keep access decisions at the organization, project, and environment boundary.
Connect the tools your team already uses
RunEnv supports a dashboard-led workflow with CLI, SDK, VS Code, Desktop, and GitHub Actions integrations. Engineers can use the interface that fits the job while the underlying project and environment context stays consistent.
- Bootstrap a repository with `runenv quickstart`.
- Run a local command with `runenv run -- <your-command>`.
- Use an SDK or GitHub Action when configuration must be delivered inside an application or pipeline.
How it works
Start with the boundary your team needs.
- 01
Create a project and environments
Set up the application boundary, then create the development, staging, and production environments your team actually operates.
- 02
Add configuration with the right access
Manage values in the dashboard and use project membership, environment permissions, and audit history to keep ownership visible.
- 03
Run the application with its environment
Link the repository and use `runenv run` so the selected process receives its authorized configuration without requiring a shared .env file.
Continue learning
Read the implementation details.
The documentation explains the supported commands, permissions, retention boundaries, and delivery modes behind this workflow.