We rebuilt a 108,511-line Terraform platform in 1,235 lines of Orbi.
What a Terraform-to-Orbi migration actually looks like. 26 repos, 63 dependencies, and 108,511 lines of HCL — rebuilt in 10 files and one binary.
The problem
26 repos. 63 dependencies. Config drift across environments. A real production platform — EKS cluster, 3 Aurora PostgreSQL databases, Redis, Kafka, S3, monitoring, DNS, email, 22 microservices — managed with Terraform, Helm, CloudFormation, and Ansible.
It worked. It also had 108,511 lines of infrastructure code across 1,086 files.
The cost wasn't failure — it was friction. Onboarding a new engineer took 30-60 minutes of "which repo do I look at?" conversations. Adding a service touched 16+ files across 2 repos. Environment config drifted because it lived in 211 duplicated files. State was an opaque JSON blob you grep'd through.
None of this is unusual. If you manage infrastructure at scale with Terraform, you know this shape. The question is whether it has to be this way.
The rebuild
Same infrastructure. 10 files. One binary. 1,235 lines of Orbi's SQL-like language.
orbi-templates/ ├── 00-providers.kvmql ├── 01-network.kvmql ├── 02-compute.kvmql ├── 03-data.kvmql ├── 04-storage.kvmql ├── 05-security.kvmql ├── 06-dns-email.kvmql ├── 07-monitoring.kvmql ├── 08-services.kvmql └── 09-verify.kvmql
Each file is named for what it manages. Providers first, then network, compute, data, and so on. Numbered for execution order. No modules directory. No variable inheritance chains. No backend config blocks.
The total line count across all 10 files: 1,235.
Head-to-head
Scale
| Metric | Terraform | Orbi | Reduction |
|---|---|---|---|
| Files | 1,086 | 10 | 99x |
| Lines | 108,511 | 1,235 | 88x |
| Dependencies | 63 | 3 | 21x |
State management
Terraform state is an S3-backed JSON blob locked with DynamoDB. You can read it with terraform state list and terraform state show. Anything more complex — filtering by type, counting resources, cross-referencing — means piping JSON through jq.
Orbi state is SQLite. You query it with SQL.
SELECT id, resource_type, status FROM resources ORDER BY resource_type;
No wrapper scripts. No jq pipelines. The state file is the query engine.
Environment management
The Terraform setup had 211 duplicated config files for staging, production, and DR environments. Three tfvars files per module per environment, each slightly different, each a potential source of drift.
In Orbi, environment config is a variable:
SET @pg_version = '15.10';
One file. Override per environment with CLI flags or an env block. No duplication, no drift surface.
Adding a service
In the Terraform codebase, adding a new microservice meant touching 16+ files across 2 repos: a Helm chart, values files per environment, a Terraform module invocation, variable declarations, output wiring, CI pipeline config.
In Orbi, it's 6 lines:
CREATE RESOURCE 'k8s_deployment' id = 'newservice' namespace = 'services' image = @registry || '/newservice:latest' replicas = 2 port = 8080 ON PROVIDER 'k8s';
One file. One statement. The deployment, service discovery, and resource registration happen in the same execution.
Post-deploy verification
After a Terraform apply, you verify with manual kubectl commands, custom scripts, or a separate monitoring check. It's a different tool, a different syntax, a different workflow.
Orbi has built-in ASSERT statements that run as part of the same execution:
ASSERT EXISTS (
SELECT 1 FROM tcp_probe('api.example.com', 443)
WHERE status = 'open'
),
'API gateway not reachable';Verification is a first-class operation. No bash wrapper, no separate CI step, no "hope it works" gap between apply and check.
Honest tradeoffs
Terraform has a decade of ecosystem maturity. Thousands of providers. A massive community. Every DevOps engineer knows it. Most cloud platforms ship official Terraform providers. That matters.
Orbi is v0.6.x — early, smaller community, fewer integrations. If you need a niche provider that Terraform supports today, Orbi probably doesn't yet. If your team has years of Terraform muscle memory, there's a real switching cost.
But maturity is a trailing indicator. The question is whether the architecture is better — and on scale, state management, onboarding, day-to-day developer experience, and built-in verification, we think it is.
We're not asking you to rip out your Terraform tomorrow. We're saying: look at the actual numbers, try the simulation, and decide for yourself.
How to try it
# Install curl -fsSL https://raw.githubusercontent.com/epyphite/orbi/main/install.sh | sh # Run the full platform in simulation mode orbi --simulate exec orbi-templates/*.kvmql
Install. Simulate. Import your existing state. Diff. Decide.
No credentials required for simulation mode. It runs the full DSL against realistic fake clouds so you can see the execution plan before pointing it at anything real.