If the same OpenTofu code runs in dev, staging and prod, you shouldn't have to read the same plan three times. Infranautic plans every environment a pull request touches and shows you one combined plan. After you merge, it applies what you approved, and stops to ask if anything else has crept in.
Access is by invitation while we onboard our first customers.
Every pull request is planned against each copy of the code it affects, such as app-dev, app-staging and app-prod. The plans are merged into one. A change that's the same everywhere appears once, and anything that differs is shown for each copy, labelled with its name. You approve this combined plan one to cover all the environments.
Things can change after you review a plan. Someone edits a resource by hand, or another pull request lands first. So we plan again right before applying and compare the result with the plan you approved.
If it's no more than you approved, it goes ahead without asking you again. If not, it waits for you and shows only what's different.
You choose the stages, such as dev, then staging, then prod. Inside each stage, things apply in dependency order, which we work out from your plans, so the network goes before the database that sits in it.
A stage can also run a health check script from your repository, and if it fails, the later stages don't start.
Every plan and apply is also a drift check, and a deployment that hasn't had one in a day gets checked anyway. If your infrastructure no longer matches the code, you decide whether to put it back.
Apply chosen resources on a cron schedule, for jobs like certificate renewal.
Pause applies to chosen components during a change window. Plans and drift checks carry on.
Worked out from remote state and data source lookups, with nothing to declare. They set the apply order, and on a pull request they show which deployments in other repositories depend on what you're changing.
Search every resource we've planned or applied, by name or cloud ID, and see which deployment manages it.
Modules are validated on every pull request. If you change one, you'll see the deployments in other repositories that use it.
Each operation runs in its own single-use micro-VM, on our runners or on a runner cluster in your own AWS account.
Access follows your repository permissions on GitHub, and there's no charge per user.
We're onboarding our first customers personally, so access is by invitation. Email us about your setup and we'll get you going.