Why We Wrote a Provisioning Engine in Rust

When we started building LeetProvision, the obvious choice was to build on top of Terraform's Go SDK. The DevOps community lives in Terraform — HCL, state files, and plan output are the lingua franca of infrastructure management. But we hit a wall almost immediately: planning and applying changes across a multi-thousand-resource environment took minutes, which made iterative development painfully slow.

We evaluated several alternatives: extending Terraform with custom providers, forking OpenTofu, and writing a new engine in Rust with Terraform-compatible state. Rust won for three reasons. First, its ownership model eliminates entire classes of memory bugs without a garbage collector, which is critical in a long-running provisioning process. Second, its zero-cost abstractions mean we can write expressive, modular code without paying a runtime penalty. Third, its ecosystem for concurrent I/O (tokio) lets us parallelize API calls across cloud providers dramatically.

The result is a provisioning engine where the hot path — dependency resolution, diff computation, API orchestration — runs in Rust, while module definitions use familiar HCL or TypeScript. On our benchmark suite, LeetProvision plans a 3,000-resource environment in 12 seconds — roughly 20x faster than an equivalent Terraform run. Platform engineers iterate faster, test more configurations, and ship infrastructure to production with higher confidence.