Architecture overview
Tabbify Cloud combines a control plane, build and workload hosts, a tenant-private mesh, an OCI registry, and a public application edge. This page describes the currently available product path rather than future platform direction.
Control plane
The web console, REST API, CLI, and MCP server expose selected operations for applications, deployments, networks, credentials, and early-access data resources. Their coverage is not identical:
- use
/openapi.jsonand/swagger-uifor the REST operations deployed now; - use
tcli --helpfor the installed CLI version; - use MCP tool discovery for the tools exposed to the current session;
- use the console for the workflows visible in the current account.
Authentication scopes each control operation to an account and tenant network. Mesh join tokens separately admit infrastructure peers with authoritative tags. See Auth & join tokens.
Source-to-workload path
A GitHub workflow or manual tcli deploy --remote submits a remote deployment:
GitHub push or tcli
-> asynchronous deploy request
-> clone selected revision
-> build OCI image
-> authenticated OCI registry
-> one selected Firecracker-capable supervisor
-> configured health gate
-> running application
The public runtime is a CPU-only Firecracker microVM created from the OCI image. A deployment selects one workload target, either explicitly or through the current default. It does not create a redundant workload group. See Deploy pipeline, Runtime, and tabbify.toml.
Deploy status reports the current phase and lifecycle state. When available, it also includes a bounded tail of application output held on the selected host. This evidence helps diagnose the current deployment but is not a durable release record or central log archive.
Private data path
Each application receives a deterministic IPv6 ULA derived from its UUID. Applications in the same tenant can call one another over HTTP at those addresses. ACL-filtered mesh visibility prevents one tenant from treating another tenant's applications as a shared catalogue.
Production workload traffic currently uses the managed relay:
caller -> WireGuard joiner -> managed relay -> selected host -> application
WireGuard encrypts mesh packets. Certificate coverage is not uniform across every platform hop, and network reachability is not application authorization. Sensitive services must authenticate requests themselves. See Private Mesh and Services.
Public data path
The public edge terminates TLS and forwards an application request over the tenant mesh:
browser or API client
-> HTTPS application URL or configured custom domain
-> Tabbify edge
-> tenant mesh relay
-> application ULA on the selected host
-> Firecracker microVM
The standard route is https://app.tabbify.io/app/<uuid>/. A tenant can configure a custom domain through the current domain workflow; the edge validates the domain and serves it with TLS. Public ingress does not automatically add authentication to the application. See Routing & public access.
Early-access data
Tenant applications can use early-access PostgreSQL, KV, and S3-compatible resources. These are separate managed resources reached over approved paths. Each resource has service-specific limits, and the current offer is not a complete highly available or disaster-recovery data service. See Managed data before placing production state.
Current boundaries
The health gate is an activation check, not a guarantee of an uninterrupted release. The platform does not currently provide automated workload scaling, redundant workload copies, geographic failover, automated rollback, durable deploy history, a tenant-to-tenant service marketplace, or a complete platform telemetry suite. Contract-specific human release, recovery, and support processes are described separately in Managed operations.