Terrateam

Terrateam executes infrastructure plans and changes through pull request comments while keeping all cloud credentials and state files inside private runners. Written in OCaml with a PostgreSQL backend, the control plane coordinates concurrency locks and drift detection without storing cloud keys on third-party servers. Automation workflows and access rules live as versioned code inside the repository.

Why Terrateam instead of Terraform

Terraform defines cloud resources, while commercial platforms like Terraform Cloud manage team collaboration and run execution. That hosted model introduces privacy risks: organizations must upload administrative cloud credentials, environment variables, and state files containing plaintext secrets to an external vendor. Terrateam reverses this approach by decoupling orchestration from execution. The self-hosted server acts solely as a coordinator, dispatching jobs to private runners inside your own network where Terraform or OpenTofu runs directly against cloud accounts.

This architecture ensures sensitive credentials and infrastructure state never leave private perimeters. Teams can use temporary OpenID Connect tokens rather than storing static cloud keys. Workflows and approval rules live in a configuration file within the repository, ensuring changes undergo standard peer review. The trade-off is operational overhead: while hosted SaaS handles its own maintenance, Terrateam requires operating a containerized server and a PostgreSQL database.

What it does well

• Pull request workflows: Team members propose, review, and approve infrastructure changes in standard code reviews before applying them to live environments.
• Private runner execution: Plans and applies execute on self-hosted runners within your private network, ensuring state files and access keys remain internal.
• Concurrency locks: Apply-only locking prevents simultaneous deployments from conflicting, while still permitting teams to run planning checks in parallel.
• Tag-based configuration: Tag queries in repository configuration files let administrators manage rules across thousands of workspaces without duplicating files.
• Automated drift detection: Scheduled background runs identify when live cloud resources diverge from stored definitions, alerting teams to unintended modifications.
• Policy enforcement: Integrates Open Policy Agent checks to block infrastructure changes that violate organizational security guidelines.