Skip to main content
Tembo self-hosted overview
Tembo offers a self-hosted deployment for teams that need Tembo to run inside infrastructure they control. With self-hosted, Tembo runs in your environment instead of Tembo-managed infrastructure. Tembo provides the packaged release, upgrade path, and support, and you decide how it is deployed, networked, and operated. Tembo self-hosted works across AWS, GCP, Azure.

​
How it works

At a high level, self-hosted Tembo is a small set of core services that you run in your own environment. If you want the simplest deployment model, Tembo can run on a single VM. At a lower level, a standard deployment runs 6 core services:
  • Web app for the user interface
  • API for product workflows, auth, and orchestration
  • Sandbox service for executing your sessions in isolated VMs
  • Cron for scheduled jobs (kicked off from tembo’s Agents feature or via tool calls from coding agents)
  • Redis
  • Postgres
Postgres can run on that same VM, or you can point Tembo at a separate Postgres instance using your own connection string. This makes the deployment straightforward: you can start with a simple single-VM setup, or connect Tembo to customer-managed infrastructure where needed. For larger environments, auto scaling is the default posture.

​
What you manage

You manage the infrastructure, networking, secrets, backups, and day-to-day operations of the environment. Tembo provides the application release, deployment guidance, and support for upgrades. You can also work with the Tembo team more directly through support packages, including optional FDE support for features specific to your team. If you want help operating the VM layer, the Tembo team can help manage your VMs and stay ahead of scaling, availability, and downtime risks as usage grows. For releases and updates, Tembo can manage them for you, or your team can manually opt in to changes through the installer web UI that ships with the deployment by default.

​
Security and networking

Self-hosted is designed for teams that want Tembo inside a private cloud, dedicated network, or on-prem environment.
  • You control ingress, DNS, TLS, and firewall policy
  • Application data and runtime configuration stay in your environment
  • Outbound access can be limited to the systems Tembo needs to reach, such as git providers, model endpoints, or internal services
  • Upgrades happen on your schedule

​
Who it is for

  • Teams that need Tembo inside infrastructure they control
  • Organizations with security or compliance requirements around source code, credentials, or runtime data
  • Companies that want a simple single-VM deployment, with the option to use an external Postgres database
  • Buyers who want a predictable, customer-managed upgrade process
If you do not need that level of control, the hosted SaaS product is usually simpler to adopt and operate.

​
Next steps