---
title: "Self-hosting"
---

> Documentation Index
> Fetch the complete documentation index at: https://ermahgerd-docs.t-bd7662a5eeb4.workers.ermahgerd.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Self-hosting

Run the platform on infrastructure you control. You are responsible for the
hosts, DNS, credentials, backups, maintenance, and any customers you invite.
The same services and application interfaces are used by the managed offering.

## Choose an installation

| Installation                   | Purpose                                                   | Starting point                                           |
| ------------------------------ | --------------------------------------------------------- | -------------------------------------------------------- |
| Local demonstration            | Evaluate the console and examples on a disposable Lima VM | [Local demo](/self-hosted/local-demo/)                   |
| Public Ubuntu host             | Operate a reachable single-node installation with HTTPS   | [Public hosting](/self-hosted/public-hosting/)           |
| Optional multi-node Lima fleet | Explore capacity and placement across six VMs             | [Deployment profiles](/self-hosted/deployment-profiles/) |

The default local VM uses 4 vCPUs, 16 GiB RAM, and a 64 GiB sparse disk. A public
host uses the compact topology too; multiple hosts are optional capacity, not
a prerequisite. Neither layout provides automatic replication or failover.

## Understand addresses before starting

The local demo uses `*.ermahgerd.localhost` and explicit forwarded ports.
Those URLs work on the development machine. Its documented bootstrap account
and tokens are only for that disposable environment.

A public installation uses its own DNS domain, trusted HTTPS certificates, and
fresh credentials. The checked-in Latitude inventory describes the project's
existing hosted installation. It is a reference to adapt, not a set of addresses
or credentials to reuse for an unrelated host.

## After installation

Use the tenant console to create application resources and
[Connect Wrangler](/build/connect-wrangler/) for code deployment. The
[application guides](/build/) apply without changes to the Worker
binding APIs. [Platform operations](/operations/) covers maintaining the
installation and supporting its customers.

Keep durable application data separate from the decision to rebuild a demo.
There is no built-in backup, restore, or failover workflow. A local `make destroy`
intentionally removes the selected demo's data.

Source: https://ermahgerd-docs.t-bd7662a5eeb4.workers.ermahgerd.io/self-hosted/index.mdx