tribenest CLI

Local dev for TribeNest code websites — pull a version to disk, edit it with your own coding agent (Claude Code / Cursor) and a local vite dev, then push / publish. Ships an MCP server so your agent inherits the platform agent's context + tools (real entity ids, media, the Forge manifest, content fields).

Install

npm i -g tribenest        # requires Node >= 20.19
tribenest upgrade         # later: self-update to the latest published version

Or, from the monorepo for local development:

cd packages/cli && npm run build && npm link    # exposes the `tribenest` bin

Use

# 1. Authenticate (mints a personal access token, stored in ~/.tribenest)
tribenest login --env local            # or --env production
#    or:  tribenest login --env staging --api-url https://api.staging.example.com

# 2. Clone a code website locally (pick a profile + version interactively;
#    creates <subdomain>_<version>/, or use `.` for the current folder)
tribenest clone
# later, refresh the checkout with the latest remote files:
tribenest pull

# 3. Run it locally against the backend
tribenest dev

# 4. Edit with your agent. Claude Code auto-loads the generated CLAUDE.md +
#    .mcp.json, so it has the same rules + the `tribenest` MCP tools:
#    list_entities, list_media, upload_media, create_event_with_tickets,
#    create_membership_tier, create_form, list_collections, get_collection,
#    create_collection, update_collection, add_collection_field,
#    update_collection_field, list_collection_entries, create_collection_entries,
#    update_collection_entry, publish_collection_entry,
#    read_content, set_content_fields, check_errors, build, publish

# 5. Save changes back, and deploy
tribenest push           # upload source changes
tribenest build          # build locally with the site's production config
tribenest publish        # build locally → push → deploy the built artifact
tribenest preview        # deploy a shareable preview (server-built)

publish builds on your machine and uploads the finished bundle, so production deploys don't spend build time (or memory) server-side. Publishing from the dashboard still does a full server-side build.

How it works

• Auth: a long-lived, revocable Personal Access Token (PAT). It resolves to your account; per-profile websites.* permissions are still enforced per call, so the CLI has exactly the access you already have. The PAT lives in ~/.tribenest/config.json (chmod 600), never in the committable tribenest.json.
• Files are local. pull writes the full buildable checkout (tenant files + chassis + a forge-pinned package.json) plus a .env with the per-tenant VITE_* vars, so vite dev talks to the backend just like the hosted sandbox.
• Context comes from the platform, live. The MCP server proxies the same list_entities / list_media / content endpoints the in-platform agent uses, so your agent never guesses ids or endpoints.
• Chassis is read-only. vite.config.ts, tsconfig.json, package.json, etc. are platform-managed — push never sends them.

Config files

• ~/.tribenest/config.json — { defaultEnv, envs: { name: { apiUrl, pat } } } (secrets).
• <project>/tribenest.json — { env, versionId, profileId, forgeTarballUrl, files } (committable).