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 |
| Public Ubuntu host | Operate a reachable single-node installation with HTTPS | Public hosting |
| Optional multi-node Lima fleet | Explore capacity and placement across six VMs | 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 for code deployment. The application guides apply without changes to the Worker binding APIs. Platform 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.