Overview
Fontana runs on Kubernetes and ships the same governed stack whether Fontana operates the host or you run it in your own environment. Production releases are pinned and immutable so upgrades are reproducible and audit-friendly. Every workspace lives in a separate cluster with its own data, secrets, and identity, regardless of deployment model.
Topics
Section titled “Topics”- Architecture - platform and workspace clusters, shared services, isolation
- Cloud deployment - Fontana-managed cloud and customer VPC on AWS, Azure, or GCP
- Self-hosted deployment - on-premises Kubernetes, private registry mirrors, and customer-operated hosts
- Backup and restore - platform snapshots, rollback, and Admin configuration backup
- Fontana CLI - install, configure, apply, and tenant lifecycle on the host
Where Fontana runs
Section titled “Where Fontana runs”| Model | Summary |
|---|---|
| Cloud deployment | Managed cloud (Fontana operates the host) or customer VPC in your cloud account |
| Self-hosted deployment | On-premises or customer-operated Kubernetes in your facility or private cloud |
| Dedicated host | One customer per physical box; available in cloud or self-hosted arrangements |
Upgrades and releases
Section titled “Upgrades and releases”Workspace upgrades use immutable release tags and automatic pre-upgrade snapshots so you can roll back if needed. Host operators reconcile changes with the Fontana CLI; application configuration can be exported from Admin → Deployment → Backup/Restore. See Backup and restore for both paths.
Related documentation
Section titled “Related documentation”- Security - isolation, encryption, supply chain, SOC 2 control summary
- Compliance evidence - workflow lineage and immutable audit trail
- Observability - HyperDX onboarding during install and upgrade
- Identity and access - Zitadel provisioned per workspace cluster
- Platform overview - runtime components and platform capabilities