Glossary

The terms qubepods uses, and what they mean precisely. The q64 language has its own vocabulary (Qube, qube, Continuum); this page covers the platform.

Projects & applications

Project — the unit of everything: one dataset (KV / SQLite / R2), its own variables & secrets, its own tokens, its own twins. A project is an environment — staging is simply a second project from the same repo, never a flag or a route.

Application (app) — one deployable member of a project: a frontend, an API, a twin. Each has its own manifest, deployments, and versions. A project groups many applications; they share the project’s stores.

Workspace — a repo holding several members (applications) of one project, each in its own folder with its own manifest.

Deployment — one immutable release of an application: the artifact plus its manifest, created by qube deploy (or POST /api/deploy).

Releases

Release slot (blue / green) — every application has two. One serves traffic; the other stages the next release. The first deploy of a new app goes straight live; every deploy after that parks in the idle slot at 0% traffic.

Slot preview — the staged release at a real URL (?slot= on the app’s URL, returned as slotPreviewUrl by the deploy) — everything except traffic, against the project’s real stores.

Promote — flip the staged slot live. Atomic; the previous version stays in the other slot, so rollback is just promoting again. Console button, qube pod promote, or POST …/promote with a project token.

Canary — send a percentage of visitors to the staged slot instead of flipping all at once, sticky per visitor. Splittable runtimes only.

Twins

Backend twin — any always-on instance running on the platform’s stateful plane. A twin is a deployment, not a route: deploying one yields no URL, it yields a running instance the platform pairs by the project. Its WebSocket rides the app’s own URL.

Device twin — a backend twin the platform runs one per device, declared by twin: { of: "<device app>" } in the manifest. Each enrolled device’s readings run its own twin instance — typically the single writer of that device’s data into the project database.

Dashboard twin — the project’s single aggregator twin (a stateful app without a twin pairing): every browser holds one WebSocket to it, and it fans live updates out to all of them. One per project — every frontend and device converge on the same state.

Devices & the fleet

Node — your own hardware enrolled into a project: role device (a sensor/actuator endpoint) or host (runs workloads). Nodes dial outbound only; nothing listens on your network’s edge.

Enrollment — the one-time token exchange that gives a node its private credential. After it, presence, telemetry, and readings are automatic.

Fleet roster — the live device list (name, OS, address, last reading) the platform serves read-only at /.well-known/fleet on the dashboard twin’s URL, so dashboards can label gauges without identity ever riding the data frames.

Storage & access

Project database — the project’s SQLite database, shared by every application in the project. The console’s Database page shows it live; twins write it via env.db.

Project stores — the dataset every project brings: KV, the project database (SQLite), and R2 objects, all metered against one storage pool.

Project token (qube_…) — the credential for CLI/agent access, minted in the console and pinned to its project: scoped (e.g. deploy), and useless against any other project. Treat a leaked token as burned.

Hostname — the app’s public name under a wildcard pool (<name>.qubepod.app), chosen in the console or with qube pod hostname.