tb_sys_cloud_selection
Cloud Selection
Rule
- If user provides FQDN -> remote cloud.
- If no FQDN provided -> Dream local by default.
- For Dream/local, do not run backend-contacting
taucommands until Dream/universe readiness is confirmed.
Steps
- Inspect:
tau --defaults --yes json current - Remote mode:
tau select cloud --fqdn <cloud_fqdn> tau --defaults --yes json current- If the next operation includes
tau clear application, immediately re-check context and re-select remote FQDN if drifted:tau --defaults --yes clear application tau --defaults --yes json current tau --defaults --yes select cloud --fqdn <cloud_fqdn>
- If the next operation includes
- Dream default mode:
dream status universe default - If Dream status fails or not running:
# If you have newer Dream: dream start # If you have stable/older Dream (no `dream start`): dream new multiverse --daemon --universes default dream new universe default dream status universe default - Select Dream cloud:
tau select cloud --universe default tau --defaults --yes json current
Remote context hard check
- For any remote mutation (
tau push,tau import,tau new domain --generated-fqdn,tau delete domain), context must show:Cloud Type: remoteCloud: <cloud_fqdn>
- If not, stop and re-select the cloud before proceeding.
Dream readiness protocol
- Confirm Dream is reachable (
dream status universe default). - If unavailable, start Dream:
- Newer Dream:
dream start - Stable/older Dream:
dream new multiverse --daemon --universes defaultThen create/selectdefaultuniverse.
- Newer Dream:
- Only after readiness is confirmed, continue with list/query/select operations that contact backend services.
Dream deployment prerequisites (local)
- Before
dream inject push-all/push-specific, ensure Docker is running:docker info - If Docker is not available on Windows, start Docker Desktop and re-check.
- Record Dream/Docker readiness state in
tb_sys_context_log.
More from taubyte/skills
creating-taubyte-resources
Creates Taubyte resources non-interactively via `tau new` for domain, website, library, function, application, database, storage, messaging, and service. Encodes the project-vs-application scope rule, the database `min < max` constraint, the website/library `--generate-repository` + import sequence, and the forbidden `--generated-fqdn-prefix` flag. Use when adding any resource to a Taubyte project's config repo.
12diagnosing-dream-builds
Diagnoses Dream local-cloud builds when `tau list/query builds` is empty or unreliable, by hitting the jobs HTTP endpoint directly (`GET /jobs/<project_id>`, `GET /job/<job_id>`) using the GitHub token from `~/tau.yaml`, then downloading logs with `tau query logs --jid`. Use when Dream builds appear silent, the build table is empty after `dream inject`, or you need raw job ids and logs for a failing build.
11taubyte-resource-creation
Scope-aware resource creation workflow. Uses non-interactive mode by default and references the shared flags catalog.
11taubyte-push-build-verify
Pushes config/code and verifies builds/logs. Includes website/library push handling with tau command first, git fallback.
11taubyte-scope-routing
Routes project-level vs application-scoped work; defaults to a website when a browser UI is logically appropriate; avoids unnecessary applications for simple website/function-only tasks unless needed.
11understanding-taubyte-architecture
Explains the Taubyte mental model — `tau` CLI vs `dream` local cloud, remote-vs-local cloud types, GitHub as the single source of truth, and the config/code/website/library repo layout that drives builds. Use when the user asks how Taubyte fits together, why pushes don't show up, what repos are needed, or whether to use Dream or a remote cloud.
11