Infranautic

Features

What happens to a change, from the pull request to the last environment.

Pull requests

Plans on every pull request

You describe your repository in a file called infranautic.yaml. Each directory of OpenTofu code is a component, and each copy of it with its own state, such as app-prod, is a deployment.

Every pull request is planned against each deployment it affects. On GitHub you get one check per component, and plan warnings show up as annotations on the files they're about.

The plans for a component are merged into one. A change that's the same everywhere appears once, and a value that differs is shown for each deployment, labelled with its name. One Approve button covers every deployment.

Push another commit and the new plans are compared with what you approved. If there's nothing new in them, your approval carries over. Stacked pull requests work too, and each one only asks you about what it adds.

The app component on a pull request. Three deployments, app-dev, app-staging and app-prod, are waiting for approval. Below them is one plan. The launch template's machine image changes to the same arm64 image everywhere, shown once. Its instance type changes differently in each deployment, from t3.small to t4g.small in dev, t3.medium to t4g.medium in staging, and t3.large to m7g.large in prod, each labelled with the deployment's name.
Three deployments of the app, read as one plan. Only the instance size differs between them.
Before every apply

The new plan is compared with the approved one

Things can change after you review a plan: someone edits a resource by hand, another pull request merges first, or a data source starts returning something newer.

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. If it isn't, the apply waits for a decision, and you're shown only what's changed since your review.

Some differences need no decision, such as a value that was unknown at plan time now being known, or a resource you approved deleting having already gone.

A pending approval for the app component. The plan now changes the machine image to a different ID from the one approved on the pull request, and a comment shows the approved value. Approve and Reject buttons sit above the plan.
The approved machine image is shown beside the one the new plan wants.
After the merge

Promotion through your environments

Merging a pull request starts a promotion through the stages you list in infranautic.yaml. Each stage picks its deployments by label.

Stages run in the order you write them, or in parallel. Within a stage, a deployment that reads another's state applies after it.

A stage can run a health check script from your repository. It gets each deployment's outputs, and if it fails, the later stages don't start.

promotion:
  stages:
    - match: {environment: dev}
    - match: {environment: staging}
      health_check:
        script: scripts/healthcheck.sh
    - match: {environment: prod}
A promotion page with three stages. Dev has completed. Staging has applied network, database and app and is running its health check. Prod is waiting.
Staging runs its health check before prod starts.
Drift

Drift detection

Every plan and apply is also a drift check, so a busy deployment rarely needs a separate one. A deployment that's gone a day without a plan or apply gets checked anyway.

When your infrastructure no longer matches the code, the drift page shows the plan that would put it back. If you accept, we apply the code again, limited to that plan. Otherwise nothing is touched.

A drifted deployment, network-prod, on the drift page. The plan would change the app security group's HTTPS ingress CIDR block from 10.0.0.0/8, set by hand, back to 0.0.0.0/0 as the code says. Accept and Refuse buttons sit above the plan.
Someone narrowed the app's HTTPS rule by hand. Accepting puts back the rule from the code.
History

What changed, and when

The Activity page lists every resource change across your deployments, newest first, and each row says why it happened, whether that was a pull request, a drift fix you accepted or a scheduled apply.

Changes made outside Infranautic show up too, marked as observed, from the moment a plan noticed them. During an incident, jump to a time and see what moved. Search for any resource by name or cloud ID to see everything that's happened to it.

The Activity page. The newest row says app-staging's target group vanished, observed just now by a plan. Below it, database-staging's database was updated 36 minutes ago by a drift healing promotion, and the app's launch template in prod, staging and dev was updated an hour ago by pull request 2, Move the app to the September machine image.
A target group deleted by hand, noticed by a check. Below it, the drift fix you accepted and the app update from pull request 2.
Dependencies

Dependencies found from your plans

A deployment depends on another when it reads something the other manages. We find these links in your plans, from remote state and data source lookups, so there's nothing to declare.

They set the apply order within a stage, and on a pull request they show which deployments in other repositories depend on the ones you're changing.

The deployment graph. Arrows run from network-prod to database-prod and from database-prod to app-prod. The legend says the edges are remote state.
The production deployments and the state they read from each other.

Also included

Scheduled applies

Apply chosen resources on a cron schedule, for jobs like certificate renewal.

Freezes

Pause applies to chosen components during a change window. Plans and drift checks carry on, and pull requests can still merge.

Shared modules

Modules are validated on every pull request. If you change one, you'll see the deployments in other repositories that use it.

Cloud credentials

OpenTofu Operations get short-lived credentials for AWS, Google Cloud or Azure through OIDC federation. Plans and applies can use different roles.

Runners

Each operation runs in its own single-use micro-VM. Use our runners, or register a runner cluster in your own AWS account.

Your state stays where it is

Your OpenTofu state stays in the backend you already use, and your code stays on GitHub. We keep each operation's plan and results for 30 days, and no value marked sensitive is stored in a readable form.

Sign in with GitHub

Anyone who can write to a repository on GitHub can approve its plans, and there's no charge per user.

OpenTofu

Operations run OpenTofu, which runs standard Terraform code.

Try it on your own repository

We're onboarding our first customers personally, so access is by invitation. Email us about your setup and we'll get you going.

Request access See pricing