Skip to content
Back to

Self-hosted deployment

Self-hosted deployment means you operate the machine, network, and change control for a Fontana host: on-premises datacenter, private cloud, or an isolated environment without Fontana managing the box day to day. You still run the same governed stack, cluster-per-workspace layout, and pinned releases as cloud customers.

When to choose self-hosted

Section titled “When to choose self-hosted”
  • Data residency or air-gap requirements that keep the host inside your facility
  • Existing Kubernetes operations teams who want Fontana as a standard Helm/k3d workload
  • Private registry policy: mirror Fontana images internally instead of pulling from GHCR at runtime
  • Customer-operated change control: your CAB, backup, and DR procedures own the host lifecycle

What you operate

Section titled “What you operate”
AreaYour responsibility
Hardware or VMSizing, OS patching, disk encryption policy on the underlying volumes
NetworkIngress (443), SSH for break-glass, firewall rules, corporate DNS
Kubernetes hostk3d clusters for platform + each workspace; CLI-driven lifecycle
Backups and DRSnapshot retention policy, off-host backup of volume archives where required
UpgradesPin release tags, run fontana apply in approved windows, validate with fontana status

What Fontana supplies

Section titled “What Fontana supplies”
  • Pinned release bundles and container images (GHCR or mirrored into your registry)
  • Fontana CLI to reconcile platform and tenant clusters from fontana.yaml
  • Same architecture as cloud: platform cluster for shared services, one cluster per workspace
  • Documentation for observability, identity, compliance, and upgrade/rollback semantics

Dedicated vs shared host

Section titled “Dedicated vs shared host”

On a shared self-hosted host, multiple workspaces use separate clusters on one Linux machine (soft multi-tenancy at the kernel). A dedicated host gives one customer the entire box for a smaller blast radius. The cluster-per-workspace isolation model is identical in both cases.

Local and lab installs

Section titled “Local and lab installs”

Developers often run a local *.localhost install on a laptop or build server for integration testing. That uses the same CLI and topology at smaller scale. Production self-hosted runbooks differ mainly in TLS, DNS, and backup policy, not in application architecture.

Getting started

Section titled “Getting started”
  1. Size a host (CPU, RAM, encrypted data disk) per Fontana guidance for your tenant count.
  2. Install the Fontana CLI from the GHCR release bundle (or your private registry mirror).
  3. Author fontana.yaml with baseDomain, tenants, and pinned source.tag for production.
  4. Run fontana apply, then configure SSO, BYOK, and observability in the workspace.
Section titled “Related documentation”