> ## Documentation Index
> Fetch the complete documentation index at: https://www.latitude.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Shared responsibility
> How responsibilities split between Latitude.sh and you across the cluster lifecycle.
Latitude.sh delivers a running Kubernetes cluster on dedicated bare metal, including the control plane, worker nodes, network fabric, and a LoadBalancer IP announced over BGP. Once you receive your kubeconfig, day-2 operations (workloads, upgrades, observability, backups) are yours.
This page details what each side owns.
## At a glance
Bare metal, control plane availability, worker node provisioning, kubeconfig delivery, LoadBalancer IP allocation, and BGP advertisement.
Workloads, Kubernetes version upgrades, ingress, storage classes, monitoring, backups, network policies, and node OS patching.
## RACI matrix
The matrix uses standard RACI definitions:
* **Responsible (R):** performs the work.
* **Accountable (A):** owns the outcome.
* **Consulted (C):** opinion is sought (two-way).
* **Informed (I):** kept up to date (one-way).
| Task / deliverable | Latitude.sh | Customer | Notes |
| --------------------------------------------------- | ----------- | -------- | ----------------------------------------------------------------------------------------------------------------- |
| Bare metal provisioning (rack, power, network) | A/R | I | Physical hardware health and connectivity. |
| Control plane availability | A/R | I | API server and etcd uptime. |
| LoadBalancer IP allocation | A/R | I | Provisioning the entry point for traffic. |
| Worker node OS (initial image) | A/R | I | Ubuntu 24.04 LTS shipped as the base image. |
| Worker node patching (day 2) | I | A/R | OS-level security updates. |
| Cluster scaling (adding nodes) | R | A | Customer triggers; Latitude.sh provisions. Limits: control plane 1-3, workers 0-10. |
| Kubernetes version upgrades | C/I | A/R | Customer manages the upgrade cycle and testing. |
| Workload deployment (pods, services) | I | A/R | All containerized applications. |
| Ingress controller management | I | A/R | Mapping the LoadBalancer IP to internal services (Nginx, Traefik, HAProxy, etc.). |
| Monitoring and logging stack | I | A/R | Prometheus, Grafana, ELK, etc. |
| Backup and disaster recovery | I | A/R | Volume backups (e.g. Velero) and etcd snapshots. |
| Core networking (CNI, kube-proxy, CoreDNS, MetalLB) | A/R | I | Opinionated RKE2 stack, not customer-replaceable. MetalLB announces the LoadBalancer /32 over BGP. |
| Storage add-ons (CSI) | I/C | A/R | No default StorageClass shipped. Customer installs. |
| Other add-ons (cert-manager, ingress, etc.) | I | A/R | Not preinstalled. Customer installs and maintains via Helm or manifests. |
| Network policies and security | I | A/R | RBAC and internal traffic firewalls. |
| Kubeconfig delivery and rotation | A/R | I | Issued at provisioning, retrievable from the dashboard or API. |
| Service API token | A/R | – | Internal credential created by Latitude.sh so the management cluster (CAPI) can act on the project. |
| SSH keys (nodes) | R | A | Customer supplies keys at creation; Latitude.sh injects them into nodes. Post-creation changes not yet supported. |
| Billing and metering | A/R | I | Hourly bare metal. Cluster cost = sum of nodes (control plane + workers). |
| Limits | A/R | I | 1 cluster per project, control plane 1-3, workers 0-10. |
## Where the boundaries are
As a bare metal provider, Latitude.sh handles the physical lifecycle.
* **Hardware replacement:** if a node goes offline due to a hardware fault, Latitude.sh is responsible for the physical remediation.
* **Network fabric:** Latitude.sh owns the leaf-spine architecture and the handover to your LoadBalancer IP.
Latitude.sh delivers the running cluster. Once you receive the kubeconfig, accountability for what happens inside the API server shifts to you.
* **Bootstrap and availability:** Latitude.sh keeps the control plane up.
* **What runs on it:** RBAC, CRDs, controllers, and operators are yours to manage.
You are the cluster operator.
* **Maintenance:** coordinate node drains and cordons during maintenance windows.
* **Add-ons:** if you need a specific StorageClass for persistent volumes or an ingress controller for HTTP routing, installation and troubleshooting are yours. The core networking stack (CNI, kube-proxy, CoreDNS, MetalLB) ships as an opinionated RKE2 setup and is not customer-replaceable.
* **Observability:** Latitude.sh will not alert you if your pods are in `CrashLoopBackOff`. Own the monitoring stack (Prometheus, Alertmanager, etc.) to catch workload-level failures.
## LoadBalancer and BGP boundary
Latitude.sh allocates a `/32` LoadBalancer IP at cluster creation and advertises it over BGP from the underlying network fabric, terminating at MetalLB inside the cluster.
**What Latitude.sh guarantees**
The IP is reachable. BGP advertises it from the cluster nodes; the network fabric routes traffic to those nodes.
**What you own**
* Creating a Kubernetes `Service` of `type: LoadBalancer` (which claims the IP through MetalLB).
* Any ingress controller (Nginx, Traefik, HAProxy) sitting behind it.
* Application-level troubleshooting. If the IP is reachable at L3/L4 but the application returns `404`, `502`, or connection refused, the cause is on the customer side: Service selectors, Endpoints, Ingress rules, Pod readiness, etc.