Running one system should not mean living in five different consoles.
That is the whole origin story. A pile of Terraform, a browser full of provider tabs, a terminal full of half-remembered SSH aliases — and not one surface that shows you the thing you actually built. So we drew it instead.
CrossXCloud is one visual surface for multi-cloud infrastructure. Drag a resource onto the canvas, wire it to another, read exactly what will change, and apply it. It is the diff-before-apply discipline of Terraform without the tab-hopping, and without the pretence that four clouds are one cloud.
We would rather cut scope than describe something that is not there.
It is a desktop app, because that is where your credentials already live and where they should stay. The web app is its companion: accounts, organisations and projects in the browser, then open the project in the desktop app to build. Two surfaces, one product, and a line you can see between what runs on your machine and what runs on ours.
Everything below is checkable. Each of the three is either written into the licence we ship or visible in the app the first time you use it — which is the point of putting them on a page like this rather than in a mission statement.
Plan, then apply
Nothing reaches your cloud that you have not read first. Every change is diffed against what is really there, ordered into steps, and shown to you. Apply is the only button that spends anything, and it never runs a step you did not see.
Your keys are yours
Credentials are sealed in a passphrase vault on your own disk and decrypted in memory only while it is unlocked. They are never sent to us. The canvas talks to your cloud directly — which is also why the parts that run on your hardware stay free, in the licence rather than in a blog post.
A stub is not a feature
The editor can render nodes that exist only behind a demo flag, and they are never documented as features. The docs describe what the app does today, and the support matrix moves before the marketing does.
The first two are why the third matters: a tool that can change your infrastructure has to be believable about what it will do, and about what it already does. Read clause 4.3 of the EULA →
A small team, working in the open.
- We use it ourselves. The canvas runs against our own cloud accounts before it runs against yours. Most of what gets fixed was found that way.
- We cut scope, not corners. A feature that cannot be planned, diffed and read the way the rest of the app can is not ready, however good it looks in a screenshot.
- We publish what changed. Every release lands in the changelog with what moved and what broke, rather than a vague "improvements and bug fixes".
CrossXCloud is made by Honology, a small team building infrastructure tools we want to use ourselves. See what we shipped, or tell us what is missing.
