Getting Started

Tabbify builds OCI images from application repositories and runs them as CPU-only Firecracker microVMs. Workloads use tenant-private networking and can receive a public URL, custom domain, and TLS at the edge. Selected operations are available through the web console, REST API, CLI, and MCP. This page is the orientation; the Quickstart is the hands-on deploy.

The model

• Tenant environment - the boundary for applications, private networking, data resources, secrets, and access policy.
• Application - one workload identity with a stable UUID and route across deployments.
• Deployment target - one selected Firecracker-capable supervisor. Omitting a target lets Tabbify choose the current default.
• Data resource - an early-access PostgreSQL, KV, or S3-compatible service owned by the tenant and subject to its documented limits.

The shortest path

The recommended path is a GitHub workflow. Put a tabbify.toml, a Dockerfile, and a small GitHub Actions workflow in a repository. A push submits an asynchronous remote deployment; Tabbify clones the selected commit, builds an OCI image, and starts it on one workload target. You can submit the same remote deployment manually with tcli deploy --remote.

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. The action prints the app URL, but wait for deployment status to report running before treating it as live:

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: submission returns a deploy ID, and the status operation reports the current build or activation stage. Activation is gated on the configured workload health check. Status may include a bounded tail of recent application output from the selected host; it is diagnostic output, not a durable log archive.

The full walkthrough - the four files, where to store the token, and how to inspect deployment status - is in the Quickstart. A healthy candidate is activated only after the gate passes, but applications must still tolerate a release interruption or failed activation.

Next steps

• Core concepts — the mental model behind tenants, applications, runtimes, networks, and service access.
• 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 — generated REST discovery and the partial MCP surface.
• CLI workflows — supported commands, including tcli deploy --remote.
• Self-hosting a node — join your own machine to the mesh as a supervisor.