Needs you today
A server in your network accepts remote desktop connections from any address on the internet.
Approve fixin Orders
For the platform lead accountable for cloud infrastructure governance
Staxly turns a list of resources into the applications you actually own — then tells you which ones need your attention, and which ones are fine.
We set up the first scan with you — tell us about your estate and a real person replies, usually within one business day. No card, and nothing to install.
Every cloud gives you a findings list, and each of them gives it away free. What none of them tells you is which of your applications is affected — because no cloud records what an application is. Staxly works it out from how your resources are actually connected, so it still works on an estate nobody has tidied up.
Grouping comes mainly from how things are wired. Tags and names add confidence when they exist, and Staxly does not need them.
Your logging, networking and hosting are used by everything, so they are counted on their own rather than blamed on one application.
Anything Staxly cannot place is shown as exactly that, rather than quietly filed under an application to make the picture look complete.
Example company and numbers.
Application
Orders is made of 5 parts. Two have problems, one of them urgent.
This is how its parts connect. Click any part to see what it does, what we found, and how we know it belongs here.
Holds order receipts and invoices.
Anyone with a link can open a file without signing in.
Example company and numbers.
One property, on one resource. Staxly reads the current value again before writing, refuses if somebody changed it since you looked, and reads it back afterwards to confirm. It recorded what it was, so it can put it back.
Nothing changes on its own. Staxly shows the exact change and what it costs you; a person approves it, and the change runs under an identity you set up and can take away.
Five applications, not ninety-seven resources — plus the parts nothing connects to anything, shown as exactly that.
Auth and Reporting are clear. Checked this morning against 128 security checks, nothing to do. “Clear” is a dated answer here, not an absence of bad news.
Orders today. Billing this sprint. Each one says what it would change and what that affects, before you decide.
Every change, what it was before, and who approved it — kept in a record your auditor can read.
Give Staxly read-only access once, as wide as your whole tenant or as narrow as one resource group. No credentials stored.
Full inventory, 128 security checks, dependencies, cost.
One change at a time: approved by a person, applied by Staxly, reversible.
Roles, approvals, frameworks, audit trail.
One scan and you can see everything you are running, what depends on what, which bits are production, what each part costs, and what nobody is using any more.
Example company and numbers.
Example company and numbers.
Which benchmark control each one answers is inside, for whoever needs it.
128 checks that read your actual settings rather than guessing — answering 80 of the 339 recommendations in the current CIS Azure benchmarks in full and 69 in part; 92 need a person, by their nature. Every answer is the same code every time, so two scans of an unchanged estate never disagree.
Governance for platform teams running 50–500 engineers. Set who can approve a change, decide which frameworks you are audited against, and keep a complete record of every change — its before and after values, and who approved it.
Example company and numbers.
Staxly maps each technical control to every requirement it counts toward, so a single fix shows up against all the frameworks it actually helps with.
Each of these requirements also has a procedural half — policies, training, access reviews — that no infrastructure tool can satisfy. Staxly says so on every report rather than implying otherwise.
Catches a security gap while it is still in a change your team is reviewing, instead of after it is live. Staxly checks the change and stops it going through — so the problem is never in your cloud to find later. Nothing has to leave your network to do it.
Azure is live. AWS and Google Cloud are in beta: you can connect an account the same way, but the scan there uses an open-source scanner rather than Staxly’s own checks, there is no application view yet, and no real account has been through either. No key is ever stored on any of the three: your own role issues short-lived credentials and you can revoke them without telling us.
What a scan finds ↓
For consultancies and managed service providers: every client account in one console with its own posture, kept completely separate. Never scanned and scanned-and-clean never look the same.
Not every change should be made by us. For anything your code owns, Staxly will not change it directly — it gives you the fix as Terraform for your own pull request, because changing it underneath Terraform would be undone on the next deploy.
The fix comes as standard Terraform you can copy or download, and Staxly’s pull-request check blocks a change that would add a violation. Having Staxly open the pull request for you is not self-serve yet.
Not available yet. Today you export the record of every change (CSV or JSON) into the queue your team already works from; a Jira connection that raises the ticket for you is on the way.
Not available yet. Export the record today; a ServiceNow connection that raises the change record for you is on the way.
We start with a security review of your cloud, and we do that for nothing. The full report, and the fixes, come with a subscription.
Your resources, grouped into the applications your team actually owns — reconstructed mainly from how they are wired, so it works on an estate nobody has tidied. Tags and names, where you have them, only add confidence. Shared infrastructure is counted as shared, and anything we cannot place is shown as exactly that instead of being folded into an app.
How the grouping works ↓
Everything you are running in an Azure subscription, in one place: what depends on what, which parts are production, who created them, what each one costs, and what nobody is using. Plus 128 security checks that read your actual settings — answering 80 of the 339 recommendations in the current CIS Azure benchmarks in full, and 69 in part.
What a scan finds ↓
Staxly shows the exact property that would change, what it would change from and to, and what that costs you. A person approves it; Staxly applies it, reads it back, and can put it back. Resources your IaC owns get the fix as Terraform instead, because changing them underneath Terraform would be undone on the next deploy.
See what you approve ↓
An append-only ledger recording what was prevented in CI, what was found running, and what was fixed — each row carrying how it was verified and by whom. Exported per framework as JSON, CSV or a printable report.
A human reads the scan with you — what is actually urgent, what it costs to fix, what to do first. For teams who want the answer, not another dashboard.
Ask for an audit →
Answered as narrowly as they are true. Where Staxly does less than you might hope, that is the answer you will get here rather than in month three.
No, and there is no code path that could. Access works by federated identity: your own identity provider trusts a short-lived token Staxly signs, and no long-lived secret for your cloud exists anywhere in our system to be stolen or leaked.
You can revoke our access from inside your own cloud, at any time, without telling us or waiting for us.
Metadata about the shape of your estate, not what is inside it. Resource names, types, regions, resource groups, tags, the configuration properties our checks read, how resources are connected to each other, cost figures your provider reports, and the findings themselves.
Never the contents. Staxly does not read files in your storage, rows in your databases, or the values of secrets in your key vaults — it reads whether a key vault has deletion protection switched on, not what is in it.
When you turn logging on, your records stay in your Azure, in your own log workspace. Staxly reads an answer from them when it needs one and keeps only the answer: a count, a date, and the names and addresses that appear in the record, as they appear there.
Some resource names and types do, for some features. The one-line description of a detected application, the suggested wording of a fix, and the cost and health summaries are written by a model, and to do that it is sent the names, types and roles of the resources involved.
The security checks themselves use no AI at all. Every verdict about whether something passes or fails is ordinary code reading a property, with no model involved. Credentials, secret values and the contents of your resources are never sent.
There is no per-customer switch to turn the AI features off today. If your review requires one, tell us before you connect — it is a small change and we would rather build it than have you find out later.
No. Staxly does not use an agent; it works through your cloud provider’s own APIs.
Yes. Your organisation’s data is only ever reachable by your organisation, and access inside it is governed by roles you set — admin, member, or read-only.
The record of what was changed cannot be altered or deleted after the fact, including by us.
You see what it would affect before you approve it, and it can be put back. Every proposed fix changes one property on one resource — never a batch, never a redeploy — and before the button you are told what the value is now, what it would become, whether the change is safe, cautious or risky, and what else talks to that resource.
After applying it, Staxly reads the value back off your cloud to confirm it actually landed rather than trusting its own success response, and records what it was before. Undoing it restores exactly that.
If Staxly cannot work out how to undo a change, the fix is not offered at all.
No. Nothing runs on its own: every change is approved by a person first, and their name is stored with it. There is no setting that lets Staxly fix things unattended, and no plan tier that unlocks one. The identity that makes the change is one you set up and give a role to, so you can take that role away at any time.
Undoing a change is never gated behind a subscription either. If you paid to make a change, taking it back is not a second purchase.
Staxly will not change them directly. It gives you the change as standard Terraform to put through your own pull request instead, because changing a resource underneath the code that manages it would be silently undone on your next deploy — and you would be left wondering why the problem came back.
Any infrastructure code Staxly produces is standard Terraform using the official providers. If you stop using us, every fix we proposed keeps working.
Microsoft Azure is live and is the only cloud we have run against real customer accounts.
AWS and Google Cloud are marked beta, and the reason is specific: the connection works, the scan runs an open-source scanner rather than Staxly’s own checks, there is no application view for them, and no real estate has been through either. They stay marked beta until one has.
128 automated checks run against your resources. Between them they answer 80 of the 339 recommendations in the current CIS Azure benchmarks in full and 69 in part.
92 of those 339 need a person — a signed policy, an access review, a training record — and no infrastructure tool can produce those, ours or anyone else’s. Anything we cannot check is listed as not checked rather than quietly passing.
About two-thirds, on the one real estate we have measured: 47 of its 72 parts were placed in an application, 17 more were ones the customer had already labelled as shared, and 8 could not be placed at all. Anything we cannot place is shown in their own box labelled exactly that rather than folded into an application to make the number look better.
That limit is a property of what cloud platforms record, not of our implementation — no cloud models what an application is. You can close the gap yourself by labelling those resources, and Staxly will do the labelling for you once you tell it what they are.
Your cloud trusts a token Staxly signs, valid for minutes. No password or key for your cloud exists on our side, and a check on every code change refuses code that would store one.
Staxly provisions nothing and holds no state file. What it keeps on its side is a description of your estate, the findings, the record of each change, and any answer it reads from your logs — never the contents of your storage, databases or key vaults.
Standard Terraform HCL. Runs without Staxly. Zero lock-in.
Cloud-native API integrations only. Nothing installed.
CIS security findings, a dependency map and your IaC gaps, free. We connect the first subscription with you — read-only — and the scan itself takes minutes.
Book your free security review