Applies to Cloud Spectra 1.0.0.
Practical answers about CloudAddress, followed by the known limitations of release 1.0.0. If your question is not here, see the User Guide or email support@cloudspectra.ai.
How it works
What exactly does my device "wear"?
The relay's identity address. On Azure, Google Cloud and Oracle Cloud that is the relay's private address in its cloud network, and the cloud maps the relay's public IP to it one-to-one -- so to the internet your device is the public IP, and to the relay's network it is a host at the private address. On DigitalOcean the public IPv4 is on the relay's own interface and your device wears it directly. setup and status print the worn address; the public IP is the relay address they print beside it.
Is my traffic NAT'd?
Not by the relay: CloudAddress is identity transfer, and inbound connections reach your device with the visitor's address intact. The only translation on Azure, Google Cloud and Oracle Cloud is the cloud's own one-to-one mapping between the public IP and the relay's private address. Two features you turn on yourself do translate: sharing the address with LAN devices (your machine translates their traffic to the worn address) and Inbound to your phone on the dashboard. If you need several devices behind one address, that is CloudVpn.
Can several devices use the same CloudAddress at the same time?
No. A relay has one wearer. A second device can take the address over with --takeover, which disconnects the first. To give several devices the address at once, either share it from one machine to devices on its LAN (--share-with), or use CloudVpn, where several devices share one address through NAT. For several separate addresses, run several relays.
How do I move my address to another computer?
Mint an enrolment token on the relay's dashboard and run connect --name <name> --relay <public-ip> --token <token> --takeover on the new computer. The old one is evicted and needs a new token to come back. The address -- and every allow-list and DNS record that names it -- does not change.
Will my address change if the relay is rebuilt?
Not on Azure, Google Cloud or Oracle Cloud, as long as you keep it: destroy and teardown keep the public address for the relay's instance index, and the next relay created with the same --instance-index in the same project and region (on Azure, with the same name too) wears it again. It changes only if you release it with --delete-address or --delete-all. On DigitalOcean the address is the droplet's own, so a rebuilt relay always has a new one.
Do I need a public IP, or open ports, on my side?
No. Your device dials out to the relay -- UDP 28302 for the tunnel and TCP 28300 to enrol -- so it works from behind home routers, carrier-grade NAT, hotel and mobile networks. On mobile and CGNAT paths, a relay created with --mtu-mobile starts from a smaller tunnel MTU.
Does it work on phones?
Yes, with the stock WireGuard app for iOS or Android. Enrol the phone by QR code from the relay's dashboard or with cloudspectra_relay_client qr. The phone then becomes the relay's wearer. See Phones and tablets.
Can my device reach private resources in my cloud?
On Azure, Google Cloud and Oracle Cloud, yes: the device wears an address in the relay's network, and the tunnel carries that network's range -- the whole range of a network the client created, or the relay's subnet in a network you already had (--vpc, --subnet). Your cloud's firewall rules still apply. A device that is not itself a cloud instance also reads the relay's instance metadata at 169.254.169.254.
Deploying
Which clouds are supported?
Microsoft Azure, Google Cloud, Oracle Cloud and DigitalOcean, in any region your account can use. See Supported clouds.
Why is AWS not supported?
In 1.0.0 the client's AWS path launches only a relay machine image that is already present in your own AWS account, and the release does not provide one, so a relay created with --provider aws boots without the relay software and never serves. Use one of the four supported clouds. If you created one, remove it with cloudspectra_relay_client destroy --provider aws --name <name>.
Can I deploy CloudAddress with Terraform?
In 1.0.0 CloudAddress relays are created with the cloudspectra_relay_client command-line client (setup or create). The cloudspectra/gateway Terraform provider does not create CloudAddress relays. The client is scriptable: every command takes --json, exit codes are a stable contract, and defaults can live in a configuration file.
How long does it take to create a relay?
A few minutes: the relay's first boot installs its software and kernel and reboots. The first relay in an Oracle Cloud region and release also imports the relay image into your tenancy, which takes several minutes more, once. setup waits up to 30 minutes by default (--timeout).
Which instance size should I use?
The default -- the cheapest type with at least 1 vCPU and 2 GiB -- is enough for one device. cloudspectra_relay_client list-instance-types compares the recommended types across clouds with their monthly Cloud Spectra cost; choose one with --instance-type, or raise the floor with --cpu and --memory.
Can I run several relays?
Yes, under one licence. Give each relay its own name, and each relay that runs at the same time in a project its own --instance-index. Every relay bills its own vCPU-hours; on the Developer plan they all count toward the account's 16-vCPU limit.
How do I find the relays I have created?
cloudspectra_relay_client list --provider <cloud> [--region <region>] [--all-projects]. Relays are found by their cloud tags, so this works from any machine with the cloud credentials. Destroyed relays whose address or network was kept are listed with what was kept.
Is there an apt repository, Homebrew tap or winget package?
Not for 1.0.0. Install the client from the direct downloads at https://downloads.cloudspectra.ai/gateway/1.0.0/clients/: a .deb for Debian and Ubuntu, a .pkg for macOS, an .msi for Windows, or the standalone binary (use it on RPM-based Linux distributions). See Installing the client.
Does the client update itself?
No. Install the newer release's package over the old one; enrolments are kept. Relays check for their pinned release at every boot; see Upgrades.
Day to day
Does my machine keep the address after it reboots?
Not with connect or setup --daemonize, whose background process ends with the session; reconnect afterwards with connect -- no token needed. For a machine that should wear the address permanently, enrol it with the client's background service (enrol then ctl connect), which raises the tunnel at every boot. See Keeping the address across reboots.
What happens when the relay reboots?
The relay keeps its keys, its enrolment and its addresses, so your device's tunnel recovers when the relay is back, without a new token. At each boot the relay also checks that it runs its pinned release before it starts serving.
Do I need administrator rights?
To raise or lower the tunnel, yes: it creates a network interface and changes routes. On macOS and Linux run setup, connect, disconnect, teardown, pause and resume with sudo -E (so your cloud credentials and licence file stay visible); on Windows use an elevated prompt. create, list and describe only call your cloud's API.
I lost the dashboard password. Can it be recovered?
No -- the relay holds only a bcrypt hash and Cloud Spectra never sees the password. Devices already enrolled keep working and reconnect without a token. To mint new tokens, rebuild the relay with a new --admin-password on the same instance index; on Azure, Google Cloud and Oracle Cloud it comes back on the same address, and devices then enrol again with new tokens.
Billing
What does CloudAddress cost?
Your cloud bills the relay's instance, disk, address and data transfer. Cloud Spectra bills the relay's vCPU-hours: $10 per vCPU per month on the Developer plan, $30 on Enterprise, metered hourly. Only the first 64 vCPUs of an instance count, and the second one is free -- so an instance bills at most 63 vCPUs, and 1- and 2-vCPU instances cost the same. There is no per-device, per-gigabyte or per-connection charge. See Pricing.
Can my business use the Developer plan for CloudAddress?
Yes. The Developer plan covers development, evaluation, personal use and CloudAddress for business. Its limit is 16 vCPUs per account across all your relays; Enterprise removes that limit and adds a response-time SLA, SSO and exported audit, with a 4-vCPU minimum per instance.
Do the devices cost anything?
No. Clients are free; you pay for the relay, whichever device wears its address.
What happens if I go over 16 vCPUs on the Developer plan?
The relay that would take the account over the limit is parked -- it serves nothing -- and unparks by itself when capacity frees up. Relays that were already running are not affected.
Is there a free trial?
Your first 30 days are free, once per account, at any scale. A month whose usage comes to less than $1 is not invoiced.
Does pausing a relay stop billing?
pause stops the relay's instance and its Cloud Spectra meter. Your cloud may still charge for the kept disk and public address while it is paused.
What can keep billing after I tear down?
By default a kept public address (billed by Azure and Google Cloud; free on Oracle Cloud), a cloud drive created with --cloud-disk, and a project's shared filesystem. teardown and destroy name everything they keep; --delete-all keeps nothing.
Security
Does Cloud Spectra see my traffic?
No. The relay runs in your cloud account, and tunnel traffic flows between your device, your relay and the internet. Your cloud credentials stay on your machine.
What does the relay send to Cloud Spectra?
Licence check-ins (every two minutes) and the usage it is billed for. At start-up it also presents the licence key to obtain its signed datapath, and it downloads its signed software package and kernel.
What if the Cloud Spectra control plane is unreachable?
A relay that has checked in successfully keeps serving for 24 hours, then parks. A relay starting with no valid licence parks immediately: its dashboard answers and says why, and it forwards nothing.
What if my licence key leaks or is lost?
Replace it from your Cloud Spectra account; the old key stops working immediately. Put the new key in your credentials file. Each relay holds the key it was created with, so rebuild relays created with the old key -- destroy, then create again on the same instance index, which keeps their addresses on Azure, Google Cloud and Oracle Cloud. Anyone holding a key can start relays on your subscription and take over an address you use, so keep it in a file readable only by you.
Is the relay's dashboard exposed to the internet?
Yes, on TCP 28300 of the relay's address, protected by the dashboard password (the relay holds only a bcrypt hash, and failed sign-ins are rate-limited). Its certificate is self-signed, so your browser warns on first visit.
Known limitations
These are the known limitations of CloudAddress in release 1.0.0.
| Area | Limitation |
|---|---|
| Clouds | AWS is not supported. A relay created with --provider aws boots without the relay software and never serves. Supported: Azure, Google Cloud, Oracle Cloud and DigitalOcean. |
| Deployment | Relays are created with the cloudspectra_relay_client CLI; the cloudspectra/gateway Terraform provider does not create CloudAddress relays. |
| One wearer | A relay's address is worn by one device at a time. Enrolling a phone from the dashboard replaces the current wearer; the CLI's qr command is refused while another device has a live session. |
| Scale | One relay holds one address. CloudAddress does not run as a fleet or behind a load balancer. |
| Reserved ports | Ports 28300-28349 on the address always belong to the relay and never reach your device. |
| Inbound | Only the ports admitted by the relay's cloud firewall reach your device; by default that is TCP 22. Ports are chosen at creation with --open-port; to change them later, edit the relay's firewall in your cloud console. |
| Full tunnel | Requires a relay with a public IPv4; refused on an IPv6-only (--addr ipv6) relay. |
| DigitalOcean | No reserved address: the relay's address is the droplet's own and is lost when the relay is destroyed. No spot market. |
| Dashboard password | setup does not display the dashboard password it generates. Pass --admin-password, or use create, which prints its generated password once. A lost password cannot be recovered. |
| Dashboard certificate | Self-signed by default; the client does not verify it unless you pass --verify-tls. |
| Relay release | A relay stays on the release it was created with. Moving to a newer release means rebuilding it on the same instance index (on DigitalOcean the address changes). |
| Client distribution | Direct downloads only: .deb, .pkg, .msi and standalone binaries. No apt, yum, Homebrew or winget channel, and no RPM package; the client does not update itself. |
| Reboots | A tunnel held by connect or setup --daemonize does not survive a reboot of the device; use the background service (enrol + ctl connect) for that. |
| Instance metadata | The relay's metadata at 169.254.169.254 is routed only for devices that are not themselves cloud instances. |
| Private networks | The device reaches the relay's network on Azure, Google Cloud and Oracle Cloud; in a network you already had, only the relay's own subnet is routed. |
| Platforms | Linux clients need kernel 5.10 or newer; macOS 13 or newer; phones use the stock WireGuard app. |
| Storage add-ons | --managed-fs and --shared-fs are available on Oracle Cloud only among the supported clouds. A managed filesystem is deleted, with its files, when its relay is destroyed. |
| Spot relays | A spot or preemptible relay can be reclaimed by the cloud, which drops the worn address until the relay is replaced. |