Three ways to run Teable — pick by what you need:
| Teable Cloud | Full-featured self-host | Standalone self-host |
|---|
| Tables, collaboration, API, automation | ✅ | ✅ | ✅ |
| AI features (chat, agents) | ✅ | ✅ | ❌ |
| App Builder (build & deploy apps) | ✅ | ✅ | ❌ |
| Sandboxes / previews | ✅ | ✅ | ❌ |
| Runs on | teable.ai — nothing to deploy | one machine (Docker) or a Kubernetes cluster | one machine: app + PostgreSQL |
| Start here | teable.ai | Architecture → teableio/teable-deployment | Docker Deployment |
Standalone and full-featured are not a fork in the road: the full-featured
platform attaches a runtime plane next to your existing standalone Teable —
your data stays in place. Start standalone today, add AI later:
migration guide. Let an AI agent deploy it
The deployment repository is written to be driven by AI agents. Point your
agent harness (Claude Code, Codex, …) at
teableio/teable-deployment,
tell it which environment you’re deploying to, and it can take the deployment
end to end. Prepare three things:
- A domain — everything derives from one base domain, e.g.
teable.example.com.
- A DNS token — an API token for the platform hosting your DNS
(Cloudflare, Route 53, …), so DNS records and TLS certificates can be set
up automatically. Scope it to that one zone.
- Access to the deployment target:
| Target | What to hand the agent |
|---|
Your own machine — Docker all-in-one, local mode | Just Docker on the machine — no domain or DNS token needed (everything runs on *.localhost) |
| A cloud server — Docker all-in-one | SSH access to the machine |
| A managed cluster on AWS (EKS) / GCP (GKE) / Azure (AKS) | Create the cluster, then hand over its kubeconfig |
| Any existing Kubernetes cluster | A kubeconfig that can install Helm releases |
Last modified on July 15, 2026
