Cloud Management
Organize environments and provision cloud-hosted nodes from the control plane.
Overview
Cloud Management is ControlBird's cloud-based control plane, reached at app.controlbird.io (or your own enterprise-deployed Control Plane). It is where you sign up, organize your deployments into logical Environments, and provision, monitor, and manage cloud-hosted ControlBird Nodes through their full lifecycle: from creation and billing through start/stop, version upgrades, and deletion. Every long-running task is tracked so the UI can show real-time progress.
Use Cloud Management when you want ControlBird hosted for you rather than running it on your own hardware. You pick a subscription tier (Starter, Pro, or Enterprise) per node, which determines resource limits, the number of data tags, allowed protocols, and monthly egress bandwidth. Every environment owns a stable address: an alias that always resolves to whichever node is currently live. Cloud nodes do not peer with one another or synchronize data between themselves: each one is an independent instance with its own copy of your configuration and data. A second node in an environment is a candidate, typically stood up to test a newer ControlBird version, until you explicitly promote it. See A/B Node Upgrades for that workflow.
Prefer a guided tutorial?
New to this? Follow the Create Environment & Deploy a Node walkthroughs for a step-by-step tour, then come back here for the full reference.
Key Concepts
| Concept | What it does |
|---|---|
| Environment | A stable address (its alias) plus the node currently answering to it, typically named by stage (Production, Staging, Dev) or location (Home, Office). An environment can also hold one or more candidate nodes under evaluation. Environments are isolated from one another: nodes in different environments never interact. |
| Alias | The environment's own permanent hostname. It always resolves to whichever node is live, so anything that points at the alias (an NFC tag, a kiosk auto-login link, a tunnel adapter, an OAuth redirect) keeps working across a node upgrade with nothing to re-point. |
| Node | A single running ControlBird instance inside an environment, with its own permanent URL distinct from the alias. It tracks lifecycle status, live resource usage, health, and optional SSH tunnel access. A node is either live (the one the alias currently resolves to) or a candidate (any other node in the environment). |
| Subscription | The billing and feature plan for a node (one per node). It sets the tier, allowed protocols, and tag / session / bandwidth / disk caps. A candidate is billed as an ordinary node for as long as it exists, on top of the live node's subscription. |
| Node Operation | A long-running task (create, delete, start, stop, upgrade version, factory restore, upgrade tier) with a status and progress percentage that the UI shows for live updates. |
Subscription tiers
Each tier sets the resource limits that apply to a node: data-point and session caps, included protocols, bandwidth, and disk. For the full, up-to-date comparison of limits and pricing, see the pricing page.
Node lifecycle
A node moves through a well-defined set of statuses shown in the control plane. For Starter and Pro tiers, creation begins awaiting payment, moves to provisioning once checkout succeeds, and then to running once the node comes online. Enterprise nodes instead wait for an administrator to review and provision them, with no upfront payment.
Common Patterns
- Group nodes by stage or location. An environment is typically named for a deployment stage (Production, Staging, Dev) or a physical location (Home, Office). Nodes in one environment share that environment's alias and are billed and managed together; they are not networked together.
- Add a candidate to test a new version. Deploy a second node in an environment, pin it to the version you want to try, and evaluate it at its own URL before deciding whether to promote it. See A/B Node Upgrades.
- Watch live stats. The control plane shows live CPU, memory, and disk usage for each node, refreshed by a periodic health check. Once a node responds, its status becomes running and its health becomes healthy.
- Track operations for progress. Start, stop, delete, and version-upgrade actions run in the background. The control plane shows their status and progress rather than blocking on an immediate result.
- Billing stays in sync. Subscription state is kept up to date automatically, and available version updates are detected for you.
- Stay under the bandwidth cap. Each node accumulates egress for the current billing period. Crossing your tier's monthly limit moves the node into a bandwidth-exceeded state until the next period begins.
Troubleshooting & Limitations
Nodes are created inside an environment
Every node belongs to an environment, which enforces environment membership and billing association. Create the environment first, then add nodes to it. Environments do not share a network with one another, and, as of this release, nodes within the same cloud environment don't either; each node is independent.
A shared SSH tunnel credential covers the whole environment
The SSH tunnel credential is not scoped to a single node. If SSH tunnel access is enabled anywhere in an environment, treat that as access to every node in that environment, including a live production node sitting next to a candidate you're only using for testing. Don't rely on per-node isolation for SSH tunnel access within one environment.
- Subdomains are globally unique. A node's subdomain is unique across all users, and is assigned once at creation: renaming a node later does not change it.
- Node names are case-insensitive in DNS. Names are lowercased and sanitized to alphanumeric plus hyphens (1-63 characters, no leading or trailing hyphens), so
My-Nodeandmy-nodecollide. A node name only has to be unique among an environment's live nodes: a candidate may reuse the name of the node it's being tested against. - Enterprise nodes are not auto-provisioned. They wait for an administrator to provision them explicitly; changing the subscription alone does not trigger provisioning.
- Billing must be configured for paid tiers. If billing is not set up, Starter and Pro creation returns a "billing not configured" error. Enterprise is unaffected.
- A candidate is billed like any other node. Standing up a candidate to test a version starts a second, full subscription for the duration of the test; it is not a discounted or temporary charge.
- SSH tunnel needs both halves. Remote terminal access requires both a configured DNS provider and a server address. Missing either disables the tunnel.
- Resource limits do not back-sync automatically. A node's resource limits are set from its tier when the node is created. Changing the subscription applies to an existing node only when it is provisioned again.
- Bandwidth tracking is advisory. Usage is sampled by the periodic health check, so values can appear stale if it has not run recently.
- Eventual consistency on operations. An operation can be marked succeeded while the node status briefly lags behind, so keep watching until both agree.
- Deletion is gradual. A node first moves to a deleting state, then is removed in the background and marked deleted.
- Cascades. Deleting an environment cascades to all of its nodes. Deleting a node detaches its subscription; removing a subscription outright requires an explicit delete.
- Short-lived sessions. Sign-in sessions expire, so you re-authenticate per session. Each node also keeps its own sign-in state, so promoting a candidate signs everyone out: see A/B Node Upgrades.