Getting Started

Tabbify gives your AI an office. You describe an outcome in chat, your AI writes the code, and Tabbify runs it as a real service — with containers, domains, private networking, secrets, and an audit trail. This page is the orientation; the Quickstart is the hands-on deploy.

The model

• Office — the namespace you own: its apps, services, secrets, and approvals. Chat is the control plane; everything below is runtime.
• App — one workload identified by a UUID v7. You deploy it from a git push, and a single tabbify.toml is the source of truth for build, runtime, and deploy targets.
• Approvals — capabilities like telegram:send or domain:connect are requested before anything acts, and recorded in an append-only event log. Secrets never reach the prompt — they live in an encrypted store and are injected as environment. (The chat approval card is designed but not yet wired in the frontend.)

The shortest path

You deploy from a git push. Put a tabbify.toml, a Dockerfile, and a tiny GitHub Actions workflow in a repo, and every push ships a new version. You don't build images, run a server, or log into a registry — Tabbify clones your repo, builds it on its own machines, and runs it.

The workflow calls the tabbify-io/deploy@v1 action, which runs tcli deploy --remote against the node. That hands your repo URL, commit, and a short-lived clone token to Tabbify; the node clones the repo, builds the Dockerfile into an OCI image on a builder supervisor, pushes it to the mesh registry, and boots it as a Firecracker microVM.

# .github/workflows/deploy.yml
name: Deploy to Tabbify
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: tabbify-io/deploy@v1
        with:
          token: ${{ secrets.TABBIFY_TOKEN }}

The only secret you supply is TABBIFY_TOKEN — a deploy token you mint in the console under Deploy tokens (pick a network → Manage tokens → Mint deploy token → Copy; shown once), then store in the repo's GitHub Actions secrets. It's used as a Bearer token for the node API. Once the run goes green, your app is live at:

https://app.tabbify.io/app/<your-id>/

<your-id> is the id from your tabbify.toml. You can also run the same deploy from a terminal:

# clones + builds your repo on Tabbify's infra, then runs it
tcli deploy --remote
# deploy accepted: <deploy_id>
# poll: https://api.tabbify.io/v1/deploy/<deploy_id>/status

tcli reads TABBIFY_TOKEN for the node API (default endpoint https://api.tabbify.io) and a clone token for the git fetch. Deploys are asynchronous: POST /v1/deploy returns 202 {deploy_id}, and you poll GET /v1/deploy/<id>/status until it's running.

The full walkthrough — the four files, where to paste the token, and how new versions ship with zero downtime — is in the Quickstart. That git-push flow is the primary, recommended path.

Next steps

• Core concepts — the mental model behind offices, apps, and the mesh.
• The tabbify.toml manifest — the unified config format.
• The runtime — one runtime: every app builds an OCI image and runs as a Firecracker microVM.
• The deploy pipeline — what happens between git push and a running app.
• The Node API — the REST + MCP surface for driving apps.
• CLI reference — everything tcli does, including tcli deploy --remote.
• Self-hosting a node — join your own machine to the mesh as a supervisor.