CrossXCloud

One task.
Done twice.

The task Give me a VM on Hetzner, a VM on Google Cloud, and a network that both of them sit in.

Step by step comparison

The traditional way

Two consoles, or a folder of HCL and a state file.

  1. Find the credentials

    A Hetzner token in one password manager entry, a Google service account JSON in another. Export both into the right env vars, in the right shell.

  2. Write it out

    Two providers, two resource vocabularies, two sets of naming rules for the same idea.

    provider "hcloud" { token = var.hcloud_token }
provider "google" { project = var.gcp_project }

resource "hcloud_server" "web" {
  server_type = "cx22"
  image       = "ubuntu-24.04"
  location    = "nbg1"
}

resource "google_compute_instance" "api" {
  machine_type = "e2-medium"
  zone         = "us-central1-a"
  # ...and a boot_disk block, and a
  # network_interface block, and...
}

  3. Mind the state file

    It has to live somewhere shared, locked, and backed up — before the second person on the team touches anything.

  4. Plan in a terminal

    Read a wall of +/− lines and decide whether the diff you just read is the diff that will run.

    $ terraform plan
Plan: 3 to add, 0 to change, 0 to destroy.

  5. Apply, then go look

    Open both consoles to confirm what actually happened. The regions are named differently on each, so the answer arrives in two dialects.

  6. Draw the diagram afterwards

    In a separate tool. It's accurate until the first person changes something by hand — usually the same afternoon.

Tabs open
4+
Sources of truth
HCL, state, 2 consoles, 1 diagram
Diagram accuracy
until someone clicks

The CrossXCloud way

One canvas, one plan, one apply.

  1. Connect the providers once

    Each provider the way that provider expects — a Hetzner API token, a Google service account. Stored in the vault on your machine, tested the moment you add them.

  2. Draw it

    Drag two server nodes and a network onto the canvas. Connect them. The inspector fills with that provider's real regions and machine types.

  3. There is no state file

    The canvas is the desired state, and it lives with the project. Nothing to lock, nothing to lose, nothing to back up by hand.

  4. Plan, and read it in the picture

    Every step listed before anything runs — across both providers at once. Planning is free, so you can read it twelve times while you argue about instance sizes.

    Plan · 3 steps
 + hetzner  server   web
 + gcp      instance api
 + network  10.0.0.0/16

  5. Apply, and watch it on the canvas

    Each step reports its own result where you drew it. One credit per step that changed something — refunded for any step that turned out to be a no-op.

  6. The diagram can't go stale

    It isn't a drawing of the infrastructure; it's what the infrastructure was built from. Every apply is committed to history with the author, the plan and the results.

Tabs open
0
Sources of truth
the canvas
Diagram accuracy
always — it is the source

The difference isn't the drawing

Plenty of tools will draw your infrastructure. The difference is which direction the arrow points: a diagram made from your infrastructure is out of date the moment someone clicks something. A diagram your infrastructure is made from cannot be.

Try it on the free plan