Every deploy is a commit

01 / 08

Console fatigue is a small-team disease

The problem is not that any single cloud console is bad. It is that a small team ends up living in three of them at once. AWS, Azure and GCP each present a different mental model, a different log viewer and a different workflow for what is, from the team's point of view, the same handful of operations. Each console is learnable; the third one is not worth learning, because the cost is paid three times and amortised over almost nothing.

That is why the sharp end of this is small teams specifically — roughly one to ten engineers running containerized workloads on managed runtimes. A fifty-person org can afford someone whose job is knowing where the AWS log group lives. A four-person org pays for that knowledge in interruptions.

There is a second persona, and it is the one that shapes the permission model: the junior developer who should not hold cloud console credentials at all, but does need to ship. Any answer that hands everyone the console keys has solved the ergonomics and made the security worse.

02 / 08

The one workflow that has to work

A small team can deploy, observe, exec into and roll back a containerized service across any major cloud without ever opening a cloud console — and every change is captured. If everything else fails, that single workflow still has to work end to end.

The working positioning is shorter: Heroku-easy operations across AWS, Azure and GCP, with git as your audit log.

03 / 08

Broad on reading, deliberately deep on writing

"One interface, three clouds" is true, but it is true in two different strengths — and almost every misreading of what Mirsat does comes from missing which is in play. The boundary is not a roadmap accident. It is the shape of v1.

We would rather publish the table than a sentence that reads as though writes span all three. Reading breadth is genuinely multi-cloud across six managed runtimes: ECS, Azure Container Apps, Container Instances, ACA Jobs, Cloud Run and Cloud Run Jobs. The write path is one runtime, done properly.

04 / 08

A repository the customer owns

Every write action is captured as one human-readable commit in the customer's own GitHub repository. Not a log line in our database that we promise to keep — a commit, in a repo on their org, that they can clone, diff and read after they stop paying us.

That inverts the usual relationship. An audit log records that an action happened and who did it. A state repository records what the configuration became. One is an event stream you read; the other is a tree you can diff, revert and apply. Rollback stops being a feature we implement and becomes git revert plus apply.

Two states point in opposite directions and are resolved differently, which is why the interface never merges them into one "out of sync" badge. Drift is the live cloud having moved away from the last commit — reality diverged from the record, usually because someone touched the console. A pending change is a human edit to the committed state that has not been applied yet — the record ran ahead of reality.

05 / 08

Two ways the record and reality disagree

Drift and a pending change are the two states people most often collapse into a single "out of sync" badge. They point in opposite directions and are resolved differently, so the interface keeps them apart.

06 / 08

What makes a repo safe to hand over

Writing to someone else's repository is a serious thing to ask for. Three invariants make it defensible, and all three are enforced rather than promised.

• Never force-push. The app owns the repo and never force-pushes it. Every write takes an advisory lock and writes an audit row, and CI fails the build if a force-push appears in the codebase at all — the customer's history is not ours to rewrite.
• No silent writes over a human edit. Manual edits to committed state are detected and held for review before anything is applied. A tool that quietly overwrites the file a human just edited teaches everyone to stop editing the file.
• Recording ships with the capability, not after it. Browser exec arrived together with full session recording, role-gated UI, and idle and hard timeouts. There was deliberately never a milestone where exec worked and recording was coming next.

07 / 08

Isolation enforced where it cannot be forgotten

One organization's data is never visible to another — and that is enforced by Postgres row-level security at the database, not by remembering to add an org filter to every query. The distinction is not academic: a cross-module dashboard read that bypassed the filter was found and fixed as a defect, and row-level security is the reason it was a bug rather than a breach.

Roles are fixed at owner, admin, dev and viewer, issued through Auth0 organizations. Cloud credentials — an Azure service principal, a GCP service-account JSON — are encrypted at rest under a per-org data key sealed by KMS. Onboarding starts least-privilege: the initial policy lets Mirsat verify identity, list services and read logs. No write, deploy or secret access is granted until you decide to grant it.

08 / 08

Scope written down as decisions, not left as absences

Most of what Mirsat does not do in v1 is a decision with a reason attached. Self-hosted distribution is out of scope — SaaS first, with self-hosting a later artifact derived from the same engine. Deep EKS and AKS features, such as a full kubectl equivalent, are out too. And the breadth tier is capped on purpose, as the table above says plainly.

The cost of the git-as-source-of-truth model is worth naming as well: it adds a commit to the critical path of every write, and it assumes the customer wants a repository they now have to think about. For a team that already lives in git, that is free. For a team that does not, it is a new thing to own — and that is a fair reason to choose something else.