Structuring development and test environments
How to isolate LiveKit apps across dev, staging, and production while keeping everything under a single enterprise subscription.
Last Updated:
Separating development, staging, and production reduces blast radius and keeps compliance neat, but you still want shared billing and plan controls. Here’s how to design that structure with LiveKit.
Key Concepts
- Projects are the main isolation boundary: API keys, environments, logs, and usage stay inside the project.
- Environments (dev/staging/prod) can live in their own projects for the cleanest separation, or share a project if that’s workable for your team.
- Plans determine entitlements. On the Enterprise plan, multiple projects can share the same agreement—one subscription, many isolated spaces.
Recommended Layout
- Create one project per environment (for example,
Realtime App - Dev,Realtime App - Staging,Realtime App - Prod). This isolates credentials, webhooks, and audit trails automatically. - Request plan linking once you’re on Enterprise: provide Support with each
project_id(they start withp_and appear in the dashboard URL). They’ll attach every project to the same plan so you only manage a single contract. - Decide how apps map to projects.
- Separate app per environment keeps configs simple but increases project count.
- One project hosting multiple apps can work if those apps trust each other; add environment-specific naming (e.g.,
voice-agent-dev,voice-agent-staging).
Managing Apps vs. Environments
| Approach | Pros | Trade-offs |
|---|---|---|
| Separate project per app per environment | Maximum isolation, easiest RBAC scoping | More projects to click through and monitor |
| Shared project per environment | Centralized metrics per environment | Apps share API keys/logs, so guardrails needed |
| Single project, environment tags | Simplest setup, fewer projects | Limited isolation; risky for regulated workflows |
Pick the option that matches your operational maturity. Many teams start with one project per environment and regroup later if overhead grows.
Sharing a Plan Across Teams
Need different teams (or business units) to stay on the same Enterprise subscription while keeping their own sandboxes? Do the following:
- Create or identify each team’s project(s).
- Send Support the list of
project_ids plus the plan you want them under. - They’ll “join” those projects beneath one subscription, so billing/usage roll up together even though the workspaces stay isolated.
This also works if you spin up short-lived projects for experiments—just share the IDs so they inherit the main plan limits automatically.
Operational Tips
- Use consistent naming. Prefix projects with team or product plus environment (
Payments-Prod,Payments-Staging). - Automate provisioning. Store
project_ids in infrastructure code or secrets managers so CI/CD knows where to deploy. - Review access by environment. Give QA engineers access to staging projects, but keep production roles tight.
- Retire unused projects. If a test project is no longer needed, archive it to keep plan management tidy.