Provisioning with Terraform

A universe’s infrastructure is Terraform, and it ships with the starter kit. You read it before you run it, you keep it in your own version control, and it creates everything in your own cloud account.

This is the artifact to hand a security review. It is a few hundred lines, and it states every resource, every firewall rule and every secret the platform needs.

Two layers that never merge

Terraform answers what exists. The deploy answers what runs on it. The handoff between them is one rendered environment file, and that file is complete. Nothing in it is hand-edited afterwards.

That seam is what makes the rest cloud-blind. The images, the CLI and every runbook are identical whichever provider you chose.

Five inputs

The whole contract is five values, implemented once per cloud.

Input	Values	What it decides
size	small, medium, large	The machine, the database tiers, the backup window, the connection budget
auth	byo-oidc, or cognito on AWS	Which identity provider signs your users in
domain	A DNS name	Every HTTPS URL, and the certificate
admin_email	An email address	The first administrator, holding every role
roles	A list of noun:verb	The role vocabulary your nodes and workflows can demand

Everything else has a default, including the sizes of every resource.

Roles are provisioned only when the platform owns the identity provider. With cognito, Terraform creates the groups and puts the administrator in them, so the roles exist because the apply ran. With byo-oidc your tenant is authoritative and Terraform touches none of it, so the list is documentation rather than provisioning.

Two roles must exist in whichever provider you use, or nobody can author or publish: workflow:author and marketplace:publish.

What it creates

Both stacks produce the same universe. They differ only in the managed services each cloud offers, and each has its own page.

Amazon Web Services

EC2, RDS, ElastiCache, Cognito, Bedrock

DigitalOcean

Droplet, managed Postgres and Redis, load balancer

Azure

Planned

Firewalling lives in the cloud rather than on the box. That is deliberate: a firewall on the VM has to contend with Docker writing its own rules, and moving the boundary into the provider removes that whole class of surprise.

Running it

unoverse deploy

That is the whole thing, from no server to a running universe. It asks which cloud, connects your cloud account, prefills terraform.tfvars from what it can discover and from the .env your universe already has, plans the change, summarises it in plain English with a monthly estimate, and applies the plan you approved. Then it ships the platform onto what was built, migrations included. DigitalOcean walks through it.

The wrapper does not hide Terraform, and does not decide for you. The saved plan is what runs, so what was approved is what happens; d prints the full technical plan; and anything being destroyed or replaced is called out. Answering no is Terraform’s no.

Your platform team can still drive it directly, and nothing about the ground assumes otherwise:

cd infra/aws          # or infra/digitalocean
cp terraform.tfvars.example terraform.tfvars
terraform apply

A universe created this way exists but is empty: unoverse deploy then reads the rendered configuration from your applied ground and installs the platform on it. The Runbooks cover that path.

Resizing

Change size, apply again, redeploy. The variable moves the machine, the database tiers and the connection budget together, which is the reason those numbers live in one place.

What Terraform does not do

It does not install or start the platform. It does not carry your content, which reaches a universe by publishing rather than by deployment. It does not manage your identity provider when you brought your own.

---

Next: Networking