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.

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

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.

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.