Deploy a Qube

Deploying on qubepods is one command:

$ qube deploy

It reads the qube’s own qube.json5, bundles the code, and publishes to the project’s stable URL: https://<name>.qubepod.app/. That’s the whole interface — no config files for the platform, no wrangler, no pipeline.

The two verbs

• qube deploy — publishes what you have to the project’s public URL.
• qube run — runs your current working code in the shell’s Preview pane, against the project’s stores. Iterate here between deploys.

Two places to run it

The command is the same everywhere; only the login story differs.

In the web shell (no login needed)

Open your project at app.qubepods.com and use the shell — you are already signed in, and the shell is already scoped to the project, so there is nothing to configure:

$ qube deploy
deploying myapp → myapp (production)…
deployed ✓ myapp → https://myapp.qubepod.app/

In a terminal — macOS, Linux, or Windows

From your own machine (or CI), authenticate once with a project token minted in the console (Project → API tokens, deploy scope), then deploy from the qube’s directory:

$ qube pod login --token <qube_…>
$ qube deploy

qube pod login saves the token (and the API origin, if you pass --url) in ~/.qube/pods.toml; every later qube deploy uses it. Tokens are pinned to their project — a manifest targeting a different project is rejected.

Staging: give it its own project

A project is an environment. There is no staging toggle, --env flag, or preview route to configure — when you want a staging setup, create a second project. The pattern:

1. Create two projects in the console — say myapp-stage and myapp — both deploying the same qube from the same git repository.
2. Build in the stage project. Iterate, qube deploy there whenever you like — you get a real, shareable myapp-stage.qubepod.app running against the stage project’s own data.
3. Ship by deploying the prod project. When stage looks right, open the prod project’s shell (or check out the same commit locally with the prod project’s token) and run qube deploy. Done.

Git makes this natural: one repository, two projects, one command each. And because each project brings its own everything — key-value store, SQLite database, object storage, variables & secrets, API tokens — the environments are genuinely isolated:

• stage data never bleeds into production,
• a leaked stage credential never unlocks prod,
• you can wipe and reseed stage freely.

The token pinning is exactly what makes this pattern safe in CI: the stage pipeline holds the stage project’s token and cannot touch prod.

What gets deployed

qube.json5 decides the shape:

• Static-asset Qube — static: { dir: "web" } ships the folder as-is; no compile, no backend.
• Component Qube — component: { emit: true } (q64) or component: { language: "javascript", module: … } (a classic worker); the platform runs it and wires the stores your manifest’s imports declare.

Either way the deploy is atomic: the new version goes live when the upload completes, and the URL never changes.

Deploy also validates the manifest’s declared variables & secrets: if the qube requires a value that isn’t set on the project, the deploy is rejected with a message naming exactly what to set — a misconfigured qube never goes live.