Self-Hosting

How to think about self-hosting Lit Chipotle, what is open source, and the operational tradeoffs compared with the hosted service.

Lit Chipotle is open source. The API server, Lit Actions runtime, dashboard/static assets, contracts, examples, and local development tooling are available in public repositories so teams can audit the stack, run it locally, and operate their own deployment when they need that level of control.

Self-hosting is most useful when you need infrastructure ownership, private deployment controls, custom compliance boundaries, or a deployment model that your users can independently verify. The hosted Lit service is still the fastest path for most teams because Lit operates the TEE infrastructure, deployment pipeline, monitoring, billing integration, and upgrades.

Interested in self-hosting?

Email the Lit team with your deployment goals, expected traffic, security requirements, and target environment.

Open source repositories

The main stack lives in the Chipotle repository:

Lit Chipotle

Core API server, Lit Actions runtime integration, dashboard/static assets, smart contracts, deployment files, examples, and docs.

Examples

Runnable example apps for signing, encrypted policies, oracles, private stablecoins, cross-chain flows, and more.

Lit Actions

The action execution runtime used by the API server to run JavaScript inside the TEE-backed environment.

API server

The Rocket-based HTTP service that exposes account management, Lit Action execution, attestation, billing, and configuration endpoints.

Static dashboard

The browser UI for account, key, wallet, action, group, and billing management.

dstack

The open-source TEE stack used for local simulation and Phala Cloud deployments.

What you can self-host

There are two common levels of ownership:

Model	What you operate	Best for
Local development	Anvil, dstack simulator, contracts, lit-api-server, lit-actions, and static dashboard from your workstation.	Development, testing, demos, and auditing behavior before deploying.
Production self-hosting	A TEE-backed deployment, Docker images, API server, Lit Actions runtime, chain configuration, RPC access, monitoring, release process, and verification evidence.	Teams that need infrastructure control, custom compliance review, private environments, or independently managed uptime.

For local development, start with the repository’s README.md and local_test.sh. For production-oriented deployment details, see the deployment and verification references below.

Where you can deploy

Lit Chipotle runs anywhere dstack runs. dstack is Docker Compose native, so the same images and compose files the hosted service uses deploy unchanged across any supported platform:

Platform	Status	Attestation
Bare metal Intel TDX	Available	TDX
Bare metal AMD SEV-SNP	Available	SEV-SNP
Phala Cloud (managed)	Available	TDX
GCP Confidential VMs	Available	TDX + TPM
AWS Nitro Enclaves	Available	NSM

dstack also supports NVIDIA Confidential Computing (H100, Blackwell) for confidential GPU workloads alongside the CPU TEE. This list tracks the dstack supported platforms table — as dstack adds platforms, they become self-hosting targets for Lit Chipotle. For preparing your own TDX or SEV-SNP host, see dstack’s hardware enablement and self-hosted onboarding guides.

Tradeoffs

Self-hosting gives you more control, but it moves more responsibility onto your team.

Area	Hosted Lit service	Self-hosted deployment
Time to production	Fastest path; create an account and call the API.	Requires infrastructure setup, release automation, configuration, and operations.
Infrastructure control	Lit operates the public service.	You choose the TEE provider, deployment topology, domain model, and operational controls.
Upgrades	Lit rolls out service upgrades.	You decide when to upgrade and are responsible for testing, rollout, and rollback.
Verification	Use Lit-published verification material and public attestation paths.	You publish or provide your own attestation and provenance evidence for your users.
Monitoring	Lit handles production monitoring and incident response for the hosted service.	You own logs, metrics, alerts, capacity planning, and incident response.
Billing	Built-in Stripe credit flow.	You can keep, replace, or remove hosted-service billing assumptions depending on your deployment.
Support surface	Lit supports the hosted API and dashboard.	You own day-to-day operations; Lit can discuss support options for self-hosted environments.
Customization	Standard public API and dashboard behavior.	You can fork, patch, and integrate the stack with your own systems.

Governing upgrades yourself

Self-hosting is not only an operational choice — it is a governance choice. When you self-host, you deploy your own DstackApp contract and point its owner at your own Safe (or wallet, timelock, or DAO). That means you decide which Lit Chipotle releases run, not Lit:

• You approve every release. Lit publishing a new version does not change what your enclave runs. A new compose hash only takes effect in your deployment when your signers whitelist it on-chain.
• On your own timeline. Pin a reviewed compose hash indefinitely, audit a new Lit release at your own pace, and whitelist it only when you are satisfied. There is no forced upgrade.
• With your own controls. Add a timelock for a mandatory review window, set a higher multisig threshold, or choose your own signers. The hosted service runs a 2-of-4 Safe with no timelock; your deployment can be as conservative as your compliance posture requires.

This is the deepest form of “don’t trust, verify”: you are not just verifying Lit’s releases, you are the one authorizing them. See Upgrade Governance for how the hosted service does this and what signers verify before approving.

When self-hosting makes sense

Consider self-hosting when:

• Your security model requires operating your own TEE deployment.
• Your users or auditors need verification evidence produced by your organization.
• You need custom networking, domains, data retention, monitoring, or compliance controls.
• You want to fork the dashboard, API surface, billing flow, or deployment automation.
• You need a private environment for internal workloads, regulated customers, or dedicated capacity.

The hosted service is usually the better default when you want to ship quickly, avoid infrastructure work, and use Lit’s standard operational path.

Operational checklist

A production self-hosted deployment usually needs:

• A TEE environment running dstack — any platform from Where you can deploy.
• A reproducible Docker build and release pipeline.
• Chain configuration and deployed permission contracts.
• RPC endpoints for the chains your actions and management flows depend on.
• Persistent configuration for API, billing, and account metadata where applicable.
• Monitoring for API health, action execution, chain RPC failures, billing failures, and TEE attestation endpoints.
• A documented upgrade and rollback process.
• A verification process your users can run or inspect.

References

Deployment guide

Production deployment notes for the API server and Lit Actions runtime on Phala Cloud.

Verification

How users can verify that a TEE deployment is running the expected code.

Full verification

Step-by-step attestation, image provenance, and code verification flow.

Local development

Run the full stack locally with the dstack simulator and Anvil.

Contact

For self-hosting discussions, email [e-mail]. Include the environment you want to run, whether you need production support, expected request volume, security/compliance requirements, and any customization you expect to maintain.