---
title: "Self-hosted and managed service boundary"
description: "What the public Tedix product includes, what Tedix Cloud operates for you, and what is deliberately out of scope."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.tedix.dev/llms.txt
> Use this file to discover all available pages before exploring further.



# Self-hosted and managed service boundary

> **Availability:** Tedix Cloud is the recommended evaluation path for invited
> beta testers. Source publication is being prepared; self-hosting remains
> experimental and unsupported. Fresh-account certification and a supported
> self-hosted channel are deferred and do not block the source beta. See
> [Release status](./release-status.md).

## Available today

- Tedix Cloud is available to existing and invited private-beta organizations.
- The standalone CLI is available as a checksum-verified public beta.
- Authorized private-beta testers can evaluate the source release candidate,
  the credential-free local demo, and the Cloudflare installation path with
  maintainer coordination.
- Anonymous source cloning, stable self-hosted releases, and community support
  for self-hosted installations are not available.

## Public product scope

The planned source beta will include the **complete tenant product**: identity,
runtime, memory, skills, Work Items, policy, approvals, evidence, rationale,
audit, export, the MCP platform, the CLI, contracts, schemas, and the deployment
path. There will be no feature-crippled community edition — basic governance
and auditability are the product promise at every tier, not an upsell.

What you pay Tedix Cloud for is **operation**: certified releases, upgrades,
credential custody, backups, fleet management, compliance evidence, incident
response, and support. The paid boundary is a service boundary, not a feature
switch.

## Future self-hosting direction

If supported self-hosting is prioritized, its unit will be the **tenant product
deployed into a customer-owned Cloudflare account** — not a detached SDK and not a community
fork. "Self-hosted" means the Tedix product and its durable tenant state run in
your Cloudflare account; upstream vendors such as an identity provider or model
provider connect through explicit adapters and your own accounts.

Tedix is designed for Cloudflare: Workers, Durable Objects, Workflows, D1, R2,
and related bindings are the canonical platform. There is deliberately **no
supported deployment** on AWS, GCP, Azure, Kubernetes, or Docker Compose, no
replacement implementations of Cloudflare primitives, and no plan to add them.
If your hard requirement is arbitrary-infrastructure portability, Tedix is the
wrong choice — we would rather say so here than after a procurement cycle.

## Support statement

| Surface                   | Source-beta contract                                                                   |
| ------------------------- | -------------------------------------------------------------------------------------- |
| Tedix Cloud               | Recommended for invited beta testers; managed support follows the applicable agreement |
| Public `main`             | Planned, not yet published; fast-moving source with no stable compatibility promise    |
| Local demo                | Optional source evaluation aid, not the primary onboarding path                        |
| Self-hosted installations | Experimental and unsupported; fresh-account and lifecycle certification deferred       |
| Signed stable releases    | No supported channel yet; a separate future support decision                           |

Nightly, candidate and LTS channels are not promised at source-beta launch.

Running Tedix yourself makes you the operator: you own upgrades, migrations,
backup verification, restore drills, provider accounts and credentials,
observability, cost control, and incident response. The installation tooling
(preflight, provisioner, manifest certification) exists so those duties are
tractable — not so they disappear.

## What the public product will include

Every planned deployment profile will ship with:

- tedi identity, the Agent runtime, durable memory, skills, and
  Work Items
- policy, approvals, budgets, evidence, rationale, and audit trails
- the MCP edge and app platform, CLI, API contracts, schemas, and extension
  SDKs
- runtime entitlement enforcement that works without any commercial provider
  dependency (`billingSettlement` defaults to explicit `disabled`; no Stripe
  secrets required)
- stable export/import and customer-owned data contracts
- the Cloudflare deployment path: installation manifest, account capability
  preflight, resource provisioning, sanitized bootstrap, and Wrangler overlays

Deployment profiles (`developer`, `smb`, `enterprise`) define what a
profile-ready installation must declare; the requirements are additive and
machine-checked. Identity integration and data export are required at **every**
profile — they are never managed-only.

## What is managed-only

These capabilities are part of the paid Tedix Cloud service. The planned public
repository may contain their implementation; the private side will hold only
their live configuration, credentials, and operational authority:

- certified releases, managed upgrades, migrations, rollback, and incident
  response
- managed provider credentials: OAuth applications, connector custody, key
  rotation, quota escalation
- managed backups, restore drills, monitoring, retention, legal hold, regional
  controls, and private networking
- curated, supply-chain-reviewed catalog content and marketplace promotion
- multi-installation fleet operation, cross-installation administration, usage
  settlement, provider-cost reconciliation, SLAs, and premium support
- customer-account operation under contract

In a self-hosted installation the fleet-commercial plane is off
(`TEDIX_FLEET_AUTHORITY_MODE=disabled`): commercial API procedures refuse
before touching storage, commercial schedules do not dispatch, and payment
webhooks reject. This is enforced by classification-driven tests, not
convention.

### Work Item coordination is tenant product

The Work Item board — claiming, settling, commenting, evidencing, and the
thirteen `work_item_*` tables — is tenant product and ships in full. It is how a
tenant's own workers coordinate; an installation that could not run it would
have the coordination schema and no API to drive it.

Tedix-owned-channel authorization and publication receipts plus
cross-installation marketing evaluations are fleet-scoped. They live in the
separate `fleetMarketing` namespace, where classification-driven coverage
requires every procedure to carry the fleet-authority guard. The tenant
`workItems` namespace contains no fleet-commercial exceptions.

## External prerequisites

A self-hosted installation needs, at minimum, a Cloudflare account with the
Workers Paid plan and the product capabilities its profile requires (the
installer preflights these and fails before mutation), plus customer-owned
accounts for the identity provider and any model or graph providers the
installation declares. Some enterprise capabilities — workstation containers,
browser automation, email routing — may require additional Cloudflare account
plans or product access.

For Descope-backed Tedix OS installs, use an operator-owned project and
configure the exact deployed hostnames as Approved Web Domains. A dedicated
non-production project is recommended during alpha and beta. The installer
performs a read-only project readiness check before interactive apply; see the
[identity-provider readiness procedure](./installation-manifests.md#identity-provider-readiness).

## Choosing

Today, choose **Tedix Cloud** when you have private-beta access and want the
product without the operator duties:
certified upgrades, custody, compliance evidence, and someone to page.

Treat **self-hosting evaluation** as experimental, with authorized source access
before publication and your own Cloudflare/provider accounts. Source launch
will not automatically make it supported. Prioritize it later if deployment
ownership becomes a real user requirement; do not require beta testers to
operate infrastructure before discovering the product's value.

After launch, managed and self-hosted deployments will use the same public
tenant product. In both current and future operation, your organization's
memory, skills, evidence, and operating history remain yours to export.

Source: https://docs.tedix.dev/self-hosted-boundary/index.mdx