Your intent, converted to cloud infrastructure.
Octo is an infrastructure-as-code framework. You describe your application: its accounts, regions, environments, servers and services. Octo derives the cloud resources those imply, writes the Terraform, and keeps the intent behind every resource it creates.
The question you stop having to askwho asked for this VPC?|
Cloud primitives, and no record of what any of them are for.
The words your team already uses. The cloud is derived from them.
Describe the thing you are building: an application, the places it runs, the services it needs.
Octo works out what that takes in the cloud, so the words you maintain are the ones your team already uses.
Every team has its own answer to “how do we set up networking here?”, and today that answer is buried in config that only works where it was written.
Octo lets you package it once, with what it needs and what it hands back written on the outside, so anyone can use it without reading a line of what is inside.
Point something at the wrong thing in Terraform and nothing complains until the provider rejects it, part-way through creating your infrastructure, with half a stack standing.
Octo checks every connection while it works out your intent, before a single line of Terraform exists.
A plan shows you buckets, policies and roles. It cannot show you the intent behind them, because by then the intent is gone.
Octo reviews your intent itself, with the cloud changes listed underneath it, and reports anything your intent does not explain as drift.
Octo is built on a graph, so what you get is not a pile of files. It is your application drawn out: every piece, every connection between them, and a boundary around the part each building block owns. The same picture covers what you asked for and what exists in the cloud underneath it.
Every connection carries the order it has to happen in, including the ones no tool can work out on its own. Take a permission away before deleting the thing it names, and Octo already knows, because whoever built the piece wrote it down once.
Every part of the picture remembers which building block created it. You can see exactly what one of them owns, what crosses between them, and what would move if you swapped one out for another.
Octo keeps the picture between runs, so a change is a comparison of two of them rather than a fresh guess. That is how it can tell what you asked for apart from what simply turned up.
Octo is not a replacement for Terraform, and it is not a new cloud to learn. It is the layer above them, where the decisions get made and written down.
Works with Terraform or OpenTofu 1.6 and newer, Terragrunt 0.78 and newer, on Node 20 and newer.
Adopting a new infrastructure tool usually means moving off the one you have, and relearning how a deploy works.
Octo works out what you meant and writes the code. Everything below it is the toolchain you already run, and pointing it at OpenTofu instead of Terraform changes nothing above.
The only file most people ever open is a YAML file, listing the pieces they want and the values those take.
When you want a building block of your own, you write it in TypeScript, with real types, the autocomplete you already get, and the test runner you already use.
Terraform names its provider on every line, which is what makes moving between clouds, or mixing two of them, a rewrite rather than a decision.
In Octo the cloud lives in the building blocks, not in what you write, so the same description can be pointed at another provider, or split across two. The blocks we publish today cover AWS, and anything else needs its own written first.
Picking up a new tool usually starts with an empty directory and a page of setup you copy from somewhere else.
One command writes you a working project from a template, and there are more for when you want a building block, a model or a resource of your own.
Octo does not replace anything in your toolchain. It adds the step above it, where the decisions get made, and hands the result to the tools you already run.
Octo is not a black box in the middle. It writes ordinary Terraform, one folder per building block, and those files land in your repository where a reviewer can read them next to the change that caused them. Your existing pipeline runs them.
Two runs cannot fight over the same infrastructure. The steps that change things take a lock first, and a second runner stops immediately, naming who holds it, before it plans anything at all.
Every run leaves a browsable page of what happened, and the same thing as data. That is what you post on a pull request so the person approving it sees the intent, not four hundred lines of resource changes.
Octo keeps the intent behind every resource, so the next person to read your infrastructure does not have to guess.
Octo is an open-source project built with passion and dedication. Your support helps us continue improving and maintaining this tool for the community.
Star us on GitHub to show your support and help others discover Octo.
Contribute code, documentation, or ideas to help improve Octo.
Join our Discord community to connect with other Octo users and developers.
Share your feedback, report issues, or suggest new features.