bootstrapping-taubyte-projects
Bootstrapping Taubyte Projects
When to use
- "Create a new Taubyte project"
- "Import an existing project into this cloud"
tau validate configfails with/config.yaml:2:7: invalid variable nametauis on a cloud but doesn't see the project you expect- First-time project setup on Dream or remote
Snake_case naming rule (critical)
tau validates the project name as a YAML variable inside the config repo. Use snake_case (or lowercase_alnum_underscores) — never dashes.
| Project name | Outcome |
|---|---|
my_project |
OK — tau validate config passes |
team_app_v2 |
OK |
my-project |
FAILS — /config.yaml:2:7: invalid variable name |
If you (or a teammate) created a project with dashes, the cleanest fix is to recreate it under a snake_case name and re-import.
Preconditions
tauauthenticated to GitHub (see authenticating-taubyte-cli).- A cloud is selected (Dream local or remote) — see selecting-taubyte-context.
- For Dream: the universe is up — see inspecting-dream-status.
A — Create a brand-new project
tau new project creates the config + code repos on GitHub, clones them locally, and selects the project on the active cloud.
tau --defaults --yes new project <project_name> \
--location <local_dir> \
--private \
--no-embed-token
Resulting layout on disk:
<local_dir>/<project_name>/
├── config/ # cloned from <org>/tb_<project_name>
└── code/ # cloned from <org>/tb_code_<project_name>
Concrete example (snake_case):
tau --defaults --yes new project my_project \
--location "$HOME/projects" \
--private \
--no-embed-token
After creation, immediately re-select and verify (CLI selection is global per profile, not per repo folder):
tau --defaults --yes select project --name <project_name>
tau --defaults --yes json current
Project in the JSON output must equal <project_name> exactly. If it doesn't, see selecting-taubyte-context.
B — Import an existing project pair
tau import project registers an existing GitHub config/code repo pair into the currently selected cloud. It expects repo fullnames or ids, not local filesystem paths.
tau --defaults --yes import project <project_name> \
--config <org>/<config_repo_fullname> \
--code <org>/<code_repo_fullname>
Concrete example:
tau --defaults --yes import project my_project \
--config <org>/tb_my_project \
--code <org>/tb_code_my_project
Notes:
- The positional
<project_name>is mostly a label; the cloud derives the canonical project name from the repos. - After import,
tauselects the imported project automatically, but still verify withtau --json current. - First time on a remote FQDN: if
tau list projectsomits the project,tau import project …on that cloud is mandatory beforetau pushattaches real builds; then alignconfig/config.yamlid:withtau query project <name> --json(next subsection).
Align config/config.yaml id: after import (Dream or remote)
On Dream or after tau import project onto any cloud, the cloud’s canonical project id may not match the id: at the top of config/config.yaml. Jobs can then fail with project ids not equal or substrate drift.
After tau import project ... on the selected cloud, set config/config.yaml root id: to the value from:
tau --defaults --yes query project <project_name> --json
Then push config (tau push project --config-only -m "...") before relying on builds.
C — Clone an already-imported project locally
When the project already exists on the selected cloud and you just want a local checkout:
tau --defaults --yes clone project \
--location <local_dir> \
--no-embed-token
Result on disk:
<local_dir>/<project_name>/
├── config/
└── code/
If you get project not found, the selected cloud doesn't know the project — switch clouds or import it first.
D — Validate the project's config
tau --defaults --yes validate config -b main
Expected output: Config is valid.
If it errors at /config.yaml:<line>:<col>: invalid variable name, the most common cause is dashes in the project name; recreate with snake_case.
Workflow checklist
New-project progress:
- [ ] Auth verified (tau --json current shows expected cloud + profile)
- [ ] Cloud selected (universe for Dream, fqdn for remote)
- [ ] Run tau new project <snake_case_name> ...
- [ ] tau select project --name <same name>
- [ ] tau --json current shows Project = <same name>
- [ ] tau validate config -b main → "Config is valid"
- [ ] Set notification.email in config/config.yaml (git config user.email is a good default)
Gotchas
tau --json currentshows aProjectbut this cloud has no clone yet: the CLI can display a project name from profile/history while the selected cloud still lacks the GitHub config + code pair. Runtau new project <snake_case_name> --location ...on that cloud (ortau import project ...for an existing pair), then verifyProjectand thatconfig/+code/exist under--location.- Selection drift after
new project: even thoughtau new projectprintsSelected project:, the global profile selection can still point at a previous project. Always re-runtau select project --name <same>and verify before anytau import/tau push/tau newresource. - Dashes break validation. Re-emphasized because every other failure mode is downstream of this.
- Empty
notification.email.config/config.yamlshould have a real email undernotification.email; an empty value can fail the config-compiler later withmail: no address. Prefergit config user.email. tau pull projectmay printalready up-to-dateas an error. This is a CLI-output quirk; in git terms it's success. Don't chase it.
Related skills
authenticating-taubyte-cliselecting-taubyte-contextcreating-taubyte-resourcespushing-taubyte-projects
More from taubyte/skills
verifying-taubyte-functions
Verifies a Taubyte Go function locally via the `taubyte/go-wasi` Docker recipe (preferred over `tau build`, with tmpfs+bind-mount-ro to avoid root-owned artifacts in the source tree), and verifies a function actually serves on Dream by curling the gateway with the right `Host:` header (plus `/etc/hosts` mapping for `*.localtau`). Use when locally compiling a Go function to WASM, when smoke-testing a function before pushing, or when probing a Dream-hosted HTTP function from the laptop.
12creating-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.
11