Connect a provider
CrossXCloud reaches your cloud accounts using credentials you store in a local, passphrase-sealed vault. Connect at least one provider before you can build on the canvas.
What CrossXCloud expects
Section titled “What CrossXCloud expects”| Provider | Credential type | What you paste into CrossXCloud |
|---|---|---|
| Hetzner | API token | A single token string with read and write scope |
| Google Cloud | Service account key | A JSON file downloaded from the Google Cloud console |
CrossXCloud tags every resource it creates with a managed-by=crossxcloud label and a crossxcloud-node label that maps back to the canvas node. Your credential needs enough scope to read and write resources with these labels.
1. Unlock the vault
Section titled “1. Unlock the vault”If the app just launched, unlock your vault with your passphrase. The vault status control in the top bar shows whether it is locked or unlocked.
You can save a credential while the vault is locked (saving only needs the public key), but you cannot use it until the vault is unlocked. See Credentials and the vault for the full lifecycle.
2. Create a credential on your provider
Section titled “2. Create a credential on your provider”What you need
Section titled “What you need”A Hetzner Cloud API token with read and write scope. Hetzner uses a single project-scoped token, not a key pair or OAuth flow.
Create the token
Section titled “Create the token”- Open the Hetzner Cloud Console and sign in.
- Select or create a project. CrossXCloud will manage resources within this project.
- In the project sidebar, go to Security and then API Tokens.
- Click Generate token.
- Give the token a name you will recognize later, such as
crossxcloud. - Set the permissions to Read & Write. CrossXCloud needs write access to create, update, and delete servers, networks, and floating IPs.
- Click Generate token and copy the token. It is shown only once.
Save it in CrossXCloud
Section titled “Save it in CrossXCloud”Open the Cloud Connections page in CrossXCloud, select Hetzner, and paste the token into the API token field. CrossXCloud validates the token immediately with a read-only call to the Hetzner API. If the token is invalid or lacks the right scope, you see an error before you try to build anything.
What you need
Section titled “What you need”A Google Cloud service account key (JSON) with permission to manage Compute Engine instances, VPC networks, firewall rules, and static external IP addresses. CrossXCloud extracts the GCP project ID from the JSON automatically.
Enable the required APIs
Section titled “Enable the required APIs”- Open the Google Cloud Console and select or create a project.
- Go to APIs & Services and then Library.
- Enable the Compute Engine API. This covers instances, machine types, images, zones, networks, subnets, firewalls, and addresses.
Create a service account
Section titled “Create a service account”- Go to IAM & Admin and then Service Accounts.
- Click Create service account.
- Give it a name you will recognize later, such as
crossxcloud. - Click Create and continue.
- Grant the service account the roles it needs. CrossXCloud manages compute instances, networks, firewalls, and addresses, so the account needs broad Compute Engine access. The Compute Admin role (
roles/compute.admin) covers all of these. If you prefer least-privilege, you can grant a combination of more specific roles:- Compute Instance Admin (v1) (
roles/compute.instanceAdmin.v1) for instances - Compute Network Admin (
roles/compute.networkAdmin) for networks, subnets, and firewalls - Compute Security Admin (
roles/compute.securityAdmin) for firewall rules
- Compute Instance Admin (v1) (
- Click Continue and then Done.
Create and download the key
Section titled “Create and download the key”- In the service accounts list, click on the account you just created.
- Go to the Keys tab.
- Click Add key and then Create new key.
- Select JSON as the key type and click Create.
- A JSON file downloads to your machine. This is the credential.
Save it in CrossXCloud
Section titled “Save it in CrossXCloud”Open the Cloud Connections page in CrossXCloud, select Google Cloud, and paste the full contents of the downloaded JSON file into the credential field. CrossXCloud parses the JSON and extracts the project ID automatically.
3. Confirm the connection
Section titled “3. Confirm the connection”The connections list shows the providers you have saved. A saved credential is usable the moment the vault is unlocked.
When you open a project canvas, CrossXCloud reads your current infrastructure from the connected provider and lays it out as nodes. This is your starting state. From there everything you do is an edit on top of it.
| Step | What happens | Where the credential is |
|---|---|---|
| Save | You paste a token or key. It is encrypted with the vault public key. | Encrypted blob in the keystore on disk. |
| Use | Plan or Apply needs the credential. The vault decrypts it in memory. | Plaintext in memory only, never written to disk. |
| Lock | You lock the vault or close the app. The private key is cleared. | Encrypted blob stays on disk, unusable until next unlock. |
Test the connection
Section titled “Test the connection”After saving a credential, use the Test action on the connection card. CrossXCloud makes a read-only call to the provider to confirm the credential works and has the right scope.
For Hetzner, this happens automatically when you save (the token is validated on save). For Google Cloud, the test call confirms the service account can reach the Compute Engine API for the project in the JSON.
If the test fails, check:
- The credential has not expired or been revoked on the provider side.
- The required APIs are enabled (GCP).
- The token or key has read and write scope.
Rotate a credential
Section titled “Rotate a credential”To rotate a credential, create a new one on the provider side, save it in CrossXCloud, and delete the old one from the connections list. The next Plan and Apply uses the new credential.
You do not need to re-lock or recreate the vault to rotate a credential. The vault guards the key that encrypts credentials, not the credentials themselves. See Credentials and the vault.
What happens to your credentials
Section titled “What happens to your credentials”Your credentials stay on your machine, sealed in the keystore, and are decrypted only in memory while the vault is unlocked. They are never sent to CrossXCloud, to CrossXWeb, or to any third party. The canvas talks to your cloud directly using them. This is the core security model, explained in Security and the vault.
With a provider connected, continue to Your first canvas to drag a node, join a network, and apply your first change.