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

# Plan your setup

> Understand common IaC provisioning models and VCS options before setting up env zero, so you can choose the right governance structure for your team.

Before connecting your first repository, it helps to identify how your team currently provisions infrastructure and where you want env zero to fit in. This page covers the main provisioning models and VCS considerations to help you make those decisions.

## Provisioning models

Most teams fall into one of four patterns. Knowing which applies to you helps determine how to configure templates, policies, and access in env zero.

### Command & control

A central DevOps team owns and deploys all IaC. Application teams submit tickets; the DevOps team provisions resources on their behalf.

* Works well when: security requirements are strict, the infrastructure surface is small, or the team is early in its IaC journey
* env zero fit: use [approval policies](/guides/policies-governance/approval-policies) for change control; expose [audit logs](/guides/admin-guide/audit-logs) for compliance; route deployments through the platform rather than local `terraform apply`

### Self-service with IaC

Application developers submit pull requests to modify infrastructure code. An approval process triggers deployment when the PR merges.

* Works well when: developers have IaC knowledge and ownership of their infra is a goal
* env zero fit: enable [plan on PR](/guides/admin-guide/environments/plan-and-apply-from-pr-comments) so developers see the impact before merge; use [OPA policies](/guides/policies-governance/approval-policies) to enforce standards without blocking velocity

### Self-service with UI

A service catalog lets engineers request or create infrastructure through a UI, with guardrails enforced in the background.

* Works well when: not all consumers know IaC, or a unified interface is preferred over repo-level access
* env zero fit: env zero's UI is the service catalog; [templates](/guides/admin-guide/templates) are the catalog items; [policies](/guides/policies-governance/policies) and [RBAC](/guides/admin-guide/user-role-and-team-management/rbac) are the guardrails

### Fully distributed

Each application team chooses its own tools and processes. There is no unified IaC standard.

* Works well when: teams are highly autonomous and central standardization is not a goal
* env zero fit: connect teams individually; use project-scoped templates and policies to introduce lightweight standards without mandating a single workflow

## VCS options

### SaaS VCS (GitHub, GitLab, Bitbucket, Azure DevOps)

env zero integrates natively with all four. Plan on PR, continuous deployment, and PR comment-triggered applies work out of the box with no agent required. The API and webhooks are available for VCS providers not in this list.

### Self-hosted VCS

env zero also supports the self-hosted editions of GitHub, GitLab, and Bitbucket. Connecting to a self-hosted VCS requires the [env zero self-hosted agent](/guides/admin-guide/self-hosted-kubernetes-agent), which runs inside your own network.

Each self-hosted instance requires its own agent. If you run multiple Bitbucket Data Center instances, for example, you need one agent per instance.

The self-hosted agent is also the right choice for teams with high-security requirements that need all clone operations, plan runs, and deployment logs to stay within their own data center.

## Next steps

* [Quick start](/guides/getting-started/getting-started) - Deploy your first environment end to end.
* [Migrate from Terraform Cloud](/guides/admin-guide/tfc-migration) - Move existing TFC workspaces to env zero.
* [Templates](/guides/admin-guide/templates) - Understand how reusable IaC configurations work in env zero.