# Syself — Full AI Index > Syself is a Kubernetes management platform that simplifies the deployment, operation, and lifecycle management of production-ready Kubernetes clusters on Hetzner infrastructure (both cloud VMs and bare metal servers). Syself reduces Kubernetes operational costs by up to 80% through automation, self-healing, zero-downtime upgrades, and declarative GitOps-compatible configurations — no Kubernetes expertise required. For a concise summary, see: https://syself.com/llms.txt ## About - Organization: Syself GmbH - Headquarters: Eschborn, Germany (GDPR-compliant, European infrastructure) - Website: https://syself.com - Contact: https://syself.com/contact - Contact Email: contact@syself.com - Contact Phone: +49 6196 586 9180 - Support Email: support@syself.com - Sales / Demo: https://syself.com/demo - Support: https://syself.com/support - GitHub: https://github.com/syself - LinkedIn: https://www.linkedin.com/company/syself/ - Founded: 2021 - Infrastructure provider: Hetzner (Cloud VMs + Bare Metal / Dedicated servers) - Open-source foundation: Built on Cluster API (CAPI) - Managing Board: Sven Batista Steinbach (CEO), Janis Kemper (COO / Authorized Officer) - Registry Court: Frankfurt am Main, HRB 129924 - VAT-ID: DE340786139 - Remote-first company, team spans four continents ## What Syself Offers - Syself Autopilot: Fully managed Kubernetes management platform on Hetzner - Managed Databases: PostgreSQL, MariaDB, ClickHouse, MongoDB hosted inside Kubernetes clusters using high-performance local NVMe storage - Two deployment modes: SaaS (shared management cluster, zero overhead) and Dedicated (your own isolated management cluster) - 14-day free trial, no commitment required - Billing is usage-based (calculated from Hetzner infrastructure usage) ## Core Value Propositions - Up to 80% cost reduction vs. AWS/Azure/GCP by running on Hetzner - 7x faster time to market for infrastructure provisioning - Self-healing clusters: automatic detection and remediation of node failures, unhealthy pods, and configuration drift - Zero-downtime cluster upgrades via versioned Cluster Stacks (released every 2-3 weeks) - No Kubernetes expertise required — abstract away complexity while staying Kubernetes-native - Full infrastructure ownership: Syself has no access to your clusters or data - GDPR-compliant, German headquarters, European infrastructure - GitOps-ready: works with Argo CD, Flux, and any Kubernetes-native tooling - GPU support (Nvidia) on Hetzner bare metal — auto-detected, drivers auto-installed - ARM server support (Ampere-based Hetzner CAX machines) - Cluster Autoscaler integration: auto-scale nodes based on workload - OIDC-based authentication and role-based access control (RBAC) - Zero Trust security model with mTLS via service mesh - 100M+ daily users processed by customer infrastructure running on Syself - Infrastructure as Software approach — continuous reconciliation, not one-time provisioning like Terraform/Ansible - Bare metal servers treated as first-class citizens — automated lifecycle management - Managed node images: heavily tested, frequently updated OS images with security patches - Founding member of the Sovereign Cloud Stack (SCS) Forum - Winner of the German government's KaaS framework tender (SCS VP-05) ## Customers and Use Cases Syself powers infrastructure for companies including LanguageTool (250 bare-metal GPU servers, 20,000 req/s), eKool (70% of Estonian schools, 200K monthly users), Hesse.ai (AI education platform), Maxroll.gg (gaming guides platform), CCSolutions.io (tech agency managing 50+ clusters), and the Federal Ministry for Economic Affairs and Energy (Germany). Industries include SaaS, AI/ML, government, edtech, gaming, digital agencies, and managed service providers. Syself serves customers across 28 countries. --- ## Core Concepts (Deep Descriptions) ### Syself Autopilot https://syself.com/docs/hetzner/apalla/getting-started/introduction-to-syself-autopilot Autopilot is Syself's managed Kubernetes platform built on top of Cluster API (CAPI). It provides a management cluster that serves as the central control plane for creating, updating, and scaling workload clusters on Hetzner. Users never interact with raw Hetzner APIs directly — everything is declared via Kubernetes custom resources in the management cluster. Autopilot enhances CAPI with additional automation, abstraction layers, user identity management, and a built-in health and self-healing system. Available in SaaS mode (namespace in Syself-hosted management cluster) and Dedicated mode (user-hosted management cluster). The management cluster includes Cluster API Provider Hetzner, Cluster Stack Operator, and all lifecycle automation components. Users interact via kubectl + kubelogin (OIDC). Documentation is versioned — new users should use the latest version, while existing cluster users should select their current cluster version for upgrade guides. ### Cluster Stacks https://syself.com/docs/hetzner/apalla/concepts/cluster-stacks A Cluster Stack is a versioned, pre-tested bundle of all components needed to provision a production-grade Kubernetes cluster: Kubernetes version, CNI (Cilium), CSI (hcloud CSI or TopoLVM), OS image, kubeadm configuration, and all add-ons. Think of it as a Dockerfile for your cluster. Syself releases new Cluster Stack versions every 2-3 weeks. Each version is extensively tested including upgrade paths between versions. Upgrading a cluster means selecting a new Cluster Stack version — Autopilot handles the orchestration, sequencing, and validation automatically. Cluster Stack names follow the pattern `hetzner-apalla-{k8sversion}-v{stackversion}` (e.g., `hetzner-apalla-1-32`). Benefits include predictable upgrades (tested end-to-end), faster provisioning (bundled and pre-configured), simplified operations (consistent baseline), and full infrastructure control (runs on user infrastructure). Upgrades are atomic at the stack level — no individual components out of sync. If a GPU is detected during provisioning, drivers and runtime components are automatically installed. ### Management Cluster vs. Workload Clusters https://syself.com/docs/hetzner/apalla/concepts/mgt-and-wl-clusters The management cluster is hosted and maintained by Syself. It includes CAPI, Cluster Stack Operator, and all lifecycle automation components. Users interact with it via kubectl + kubelogin (OIDC). Workload clusters are the actual Kubernetes clusters running user applications — provisioned on the user's own Hetzner infrastructure. They are isolated, independently upgradeable, and separated from the management plane. This separation enables zero-downtime cluster lifecycle operations and independent scaling of multiple clusters. Users never have to worry about running or updating the management cluster — it is fully managed by Syself. The management cluster acts as the interface between users and their infrastructure. Scaling to multiple clusters becomes straightforward because the management cluster orchestrates everything. ### Self-Healing https://syself.com/docs/hetzner/apalla/concepts/self-healing Syself runs a health daemon on every node performing hundreds of lightweight real-time diagnostic checks: hardware degradation (CPU, disk, memory), kubelet and container runtime health, network latency and packet loss. At the cluster level, node health is validated from outside the node, catching silent network partitions instantly. When failures are detected, Autopilot automatically replaces or reboots crashed nodes, restarts unhealthy control plane components, reschedules misbehaving pods, and re-applies configuration drift. No engineer intervention required. This is a core advantage over tools like Terraform, Ansible, and Pulumi — Syself Autopilot reconciles infrastructure continuously, not only when triggered. Self-healing is an inherent property of Kubernetes when configured and managed correctly, and Autopilot extends this through declarative cluster state, automated reconciliation loops, and health checks with safe remediation strategies. ### Zero Trust Security https://syself.com/docs/hetzner/apalla/security/zero-trust Syself implements Zero Trust security by default. Rather than relying on network perimeter ("walled garden") security, every service-to-service interaction is authenticated, encrypted, and authorized. Achieved via a service mesh enforcing mutual TLS (mTLS): both ends of every connection are authenticated and all traffic is encrypted end-to-end. Key benefits: no VPN required, fine-grained RBAC, full auditability, reduced lateral movement risk, simplified developer onboarding. All Kubernetes clusters are configured to log every service mesh request for forensic traceability. Zero Trust eliminates the single point of failure of perimeter security, provides granular security controls, reduces lateral movement, enables comprehensive auditability, improves developer productivity (no VPN management), and scales seamlessly in dynamic cloud-native environments. Companies like Google, Microsoft, and Netflix have pioneered Zero Trust architectures. One enterprise customer transitioning from private network to Zero Trust saw a 40% reduction in operational overhead, faster developer onboarding (weeks to days), and improved compliance. --- ## Getting Started (Autopilot on Hetzner) ### Prerequisites https://syself.com/docs/hetzner/apalla/getting-started/prerequisites Install kubectl (the Kubernetes CLI) and kubelogin (OIDC login plugin via Krew). kubectl is available for Linux (amd64/arm64), macOS (amd64/arm64), and Windows. Install kubelogin via `kubectl krew install oidc-login` or Chocolatey on Windows. Both tools are required before accessing the Autopilot management cluster. ### Hetzner Account Preparation https://syself.com/docs/hetzner/apalla/getting-started/hetzner-account-preparation Steps: (1) Create a Hetzner Cloud project and generate an API token with read/write access. (2) Upload an SSH key to the Hetzner Cloud project. (3) For bare metal: create a Hetzner Robot webservice user. (4) Store all credentials as environment variables: `HCLOUD_TOKEN`, `SSH_KEY_NAME`, `HETZNER_ROBOT_USER`, `HETZNER_ROBOT_PASSWORD`, `HETZNER_SSH_PUB_PATH`, `HETZNER_SSH_PRIV_PATH`. (5) Create Kubernetes secrets in the management cluster: `hetzner` secret (hcloud token + optional robot credentials) and `robot-ssh` secret (SSH key for bare metal provisioning). Verify with `kubectl get secrets`. ### Accessing the Management Cluster https://syself.com/docs/hetzner/apalla/getting-started/accessing-the-management-cluster Download the kubeconfig from Syself and configure it: set the namespace to match your organization (e.g., `org-yourcompany`), set file permissions with `chmod 600`, and export `KUBECONFIG`. Access uses OIDC — `kubectl get clusters` opens a browser for authentication. After login, all standard kubectl commands work. First-time users will see "No resources found" — this is normal and means no clusters have been created yet. To log out: `rm -rf ~/.kube/cache/oidc-login`. ### Creating Clusters https://syself.com/docs/hetzner/apalla/getting-started/creating-clusters Step 1: Apply a `ClusterStack` and `HetznerClusterStackReleaseTemplate` YAML to the management cluster. Node images start building (~5 minutes). Check with `kubectl get HetznerNodeImageReleases`. Step 2: Apply a `cluster.yaml` defining the `Cluster` resource with desired control plane replicas, worker MachineDeployments, machine types, region, and SSH key. Step 3: Monitor progress with `kubectl get machines` — all in "Running" phase means ready. Step 4: Retrieve the workload cluster kubeconfig with `clusterctl get kubeconfig `. The cluster includes a HA control plane, CNI, and CSI pre-installed. If you already have a ClusterStack applied from a previous cluster, there is no need to apply it again since the HetznerNodeImageReleases and ClusterStackRelease are already there. --- ## Cluster Configuration How-To Guides ### Access Your Cluster Through a Domain https://syself.com/docs/hetzner/apalla/how-to-guides/cluster-configuration/access-your-cluster-through-a-domain Create a Hetzner Load Balancer (lb11/lb21/lb31), copy its IPv4 address, and create a DNS A record at your registrar pointing to that IP (propagation up to 24 hours; verify with `dig`). Add `clusterEndpointHost` (your domain), `clusterLoadBalancerType`, and `clusterLoadBalancerName` to `spec.topology.variables` in the Cluster resource. The domain cannot be changed after the cluster is provisioned. Autopilot manages adding/removing targets to the LB but does NOT manage LB lifecycle — it persists after cluster deletion and must be removed manually. ### HA Kubernetes Control Plane https://syself.com/docs/hetzner/apalla/how-to-guides/cluster-configuration/ha-kubernetes-control-plane Always use an odd number of control plane nodes. With 1 or 2 nodes, any failure causes full cluster unavailability. With 3 nodes, the cluster tolerates 1 failure; with 5 nodes, 2 failures. Set `spec.topology.controlPlane.replicas` in the Cluster resource. Never use a single control plane for anything beyond disposable test clusters. 3 replicas is acceptable for smaller clusters; 5 is recommended for production workloads. ### etcd Encryption https://syself.com/docs/hetzner/apalla/how-to-guides/cluster-configuration/etcd-encryption Enables AES-CBC encryption for Secrets stored in etcd. Add `etcdEncryptionSecretRef: {enabled: true}` to `spec.topology.variables` in the Cluster resource. Create an `etcd-encryption` Kubernetes Secret containing an `EncryptionConfiguration` resource with a randomly generated AES key (`openssl rand -base64 32`). After enabling, newly created/updated Secrets are encrypted automatically. Pre-existing Secrets must be manually re-encrypted by annotating them or running a bulk replace command. Verify by reading a Secret directly from etcd with `etcdctl` and checking for the `k8s:enc:aescbc:v1:` prefix. ### OIDC Configuration https://syself.com/docs/hetzner/apalla/how-to-guides/cluster-configuration/oidc-configuration-for-your-cluster Configure OpenID Connect authentication by setting `oidcIssuerUrl`, `oidcClientID`, `oidcUsernameClaim`, and `oidcGroupsClaim` in `spec.topology.variables`. Create `ClusterRole` and `ClusterRoleBinding` resources to map OIDC groups to Kubernetes RBAC permissions. Update the kubeconfig to use `kubelogin get-token` for authentication. Each kubectl invocation will trigger an OIDC token flow via the configured provider. ### Using Specific Cluster Stack Versions https://syself.com/docs/hetzner/apalla/how-to-guides/cluster-configuration/using-specific-clusterstack-versions Add a `versions` array to the `ClusterStack` spec to pin specific releases (e.g., `v1`, `v2`). With `autoSubscribe: true`, the latest release is always fetched in addition to pinned versions. With `autoSubscribe: false`, only explicitly listed versions are available — you must enumerate all desired versions, otherwise no ClusterStackRelease will be available for cluster creation or upgrade. --- ## Server Management ### Adding HCloud Servers https://syself.com/docs/hetzner/apalla/how-to-guides/server-management/hcloud-server-management Workers are defined as `machineDeployments` in the Cluster spec. Each deployment has one machine type, a replica count, a failure domain (region), and optional metadata labels. Multiple machine deployments can coexist with different machine types. Control planes are set via `spec.topology.controlPlane.replicas`. All supported VM types require at least 4GB RAM. Recommended machine types: - Control Planes: CPX42 (8 AMD vCPUs, 16GB RAM) or higher - General workers: CPX22/CPX32/CPX42/CPX52/CPX62 (Regular Performance AMD) - High-memory/dedicated: CCX13 through CCX63 - Cost-optimized: CX33/CX43/CX53 (Intel/AMD, older hardware, variable performance — recommended only for autoscaling burst) - ARM: CAX21 (4 vCPU, 8GB) / CAX31 (8 vCPU, 16GB) / CAX41 (16 vCPU, 32GB) Note: Only single-region control planes are supported. Multi-region has no real benefit given single-region Load Balancers. ### Adding Bare Metal Servers https://syself.com/docs/hetzner/apalla/how-to-guides/server-management/adding-baremetal-servers-to-your-cluster Create `HetznerBareMetalHost` resources in the management cluster with each server's Robot server ID and boot disk WWN. If the WWN is unknown, omit `rootDeviceHints` initially — the controller will write discovered hardware details to the resource status from which the WWN can be copied. Use `matchLabels` in worker MachineDeployments to target specific hosts. If servers were previously using RAID, wipe disks before adding them. Autopilot handles OS installation, Kubernetes bootstrapping, and cluster joining — it does NOT purchase or own servers. By default, newly purchased machines come with RAID enabled; it is recommended to disable it if unsure. ### Using ARM Servers https://syself.com/docs/hetzner/apalla/how-to-guides/server-management/using-arm-servers ARM nodes (Ampere architecture) offer better performance-per-euro for parallel and multi-threaded workloads. Requires adding ARM-specific node images to `HetznerClusterStackReleaseTemplate` (`controlplanearm64hcloud`, `workerarm64hcloud`). Use the `workerarm64hcloud` class in MachineDeployments. For ARM control planes, also set `controlPlaneMachineArchHcloud: arm64` and `controlPlaneMachineTypeHcloud` in variables. Supported: CAX21, CAX31, CAX41. ARM bare metal is not currently supported (contact Syself support). ### Placement Groups https://syself.com/docs/hetzner/apalla/how-to-guides/server-management/placement-groups Placement Groups ensure each node is scheduled on a different physical Hetzner host, reducing the risk of multiple nodes failing simultaneously. Only `spread` type is supported (Hetzner limitation). Define placement groups in `spec.topology.variables.hcloudPlacementGroups`, then reference them in worker MachineDeployments via the `workerMachinePlacementGroupNameHcloud` override and in control planes via `controlPlanePlacementGroupNameHcloud`. Essential for production HA clusters. ### Labelling and Assigning Roles on Nodes https://syself.com/docs/hetzner/apalla/how-to-guides/server-management/labelling-and-assign-roles-on-nodes Add labels via `spec.topology.workers.machineDeployments[].metadata.labels`. Labels propagate to workload cluster nodes if they meet one of these criteria: `node-role.kubernetes.io/` prefix, `node-restriction.kubernetes.io/` domain, or `node.cluster.x-k8s.io/` domain. Labels persist through node reprovisionings and cluster upgrades. Create multiple MachineDeployments to assign different roles to different node groups. ### Remove Specific Nodes https://syself.com/docs/hetzner/apalla/how-to-guides/server-management/remove-specific-nodes Annotate the CAPI `Machine` object (NOT HCloudMachine or HetznerBareMetalMachine) with `cluster.x-k8s.io/delete-machine=""`. Then reduce `spec.topology.workers.machineDeployments[].replicas` to trigger deletion. Annotated machines are deleted first; additional deletions are chosen randomly if needed. ### SSH Into Nodes https://syself.com/docs/hetzner/apalla/how-to-guides/server-management/sshing-into-nodes Option 1: Find external IP from `kubectl get nodes -o wide`, then `ssh root@ -i `. Option 2: `kubectl debug node/ -it --image=busybox` for basic tools, or `--image=nicolaka/netshoot` for advanced networking debugging. ### Rebooting Bare Metal Nodes (In-Place) https://syself.com/docs/hetzner/apalla/how-to-guides/server-management/rebooting-baremetal-servers For in-place reboots preserving local disk data: (1) Annotate the Machine with `cluster.x-k8s.io/paused=true` in the management cluster. (2) Drain the node in the workload cluster. (3) SSH into the server and run `reboot`. (4) Uncordon the node. (5) Remove the paused annotation. Incorrect annotation name will trigger automatic reprovisioning — double-check spelling. ### Taints (Not Supported) https://syself.com/docs/hetzner/apalla/how-to-guides/server-management/taints Taints cannot be set persistently via Autopilot due to a Cluster API limitation — CAPI cannot add taints to existing workload cluster nodes. Manually applied taints are lost after upgrades or reprovisioning. Workaround: use node labels combined with `nodeSelector` or affinity/anti-affinity rules to influence pod scheduling. --- ## Networking ### Configuring a Hetzner Load Balancer https://syself.com/docs/hetzner/apalla/how-to-guides/network/configuring-a-hetzner-loadbalancer Expose workloads with a Kubernetes Service of type `LoadBalancer`. Annotate the Service with `load-balancer.hetzner.cloud/location` (must match the Cluster's region, e.g., `fsn1`) and `load-balancer.hetzner.cloud/type` (e.g., `lb11`). The hcloud Cloud Controller Manager handles LB provisioning and external IP assignment. ### Exposing Applications with Ingress or Gateway API https://syself.com/docs/hetzner/apalla/how-to-guides/network/exposing-apps Expose applications using Ingress or Gateway API on a Kubernetes cluster, with Hetzner Cloud Load Balancer annotations. Example uses Traefik installed via Helm with `load-balancer.hetzner.cloud/location` and `load-balancer.hetzner.cloud/type` annotations on a `LoadBalancer` Service. The controller Service receives an external IP from a Hetzner LB. Then create Ingress or Gateway/HTTPRoute resources to route traffic to applications. ### Preserving Source Client IP https://syself.com/docs/hetzner/apalla/how-to-guides/network/preserving-source-client-ip Annotate a LoadBalancer Service with `load-balancer.hetzner.cloud/uses-proxyprotocol="true"`. Enables preserving original client IP for use in IP allowlisting, analytics, or rate limiting. ### Egress Gateway with Static Node IP https://syself.com/docs/hetzner/apalla/how-to-guides/network/egress-gateway Route outbound traffic from specific pods through a bare metal node with a static public IP using Cilium's `CiliumEgressGatewayPolicy`. Use bare metal servers as egress gateways — hcloud VMs receive new IPs after upgrades/reprovisionings. Bare metal servers offer up to 10 Gbit/s NIC bandwidth vs. 1 Gbit/s for cloud VMs. Steps: (1) Label the egress node in MachineDeployment metadata. (2) Create a `CiliumEgressGatewayPolicy` with `podSelector`, `destinationCIDRs`, `nodeSelector`, and `egressIP`. (3) Verify with `kubectl exec -it egress-test -- curl -s ifconfig.me` from a test pod. ### Pod and Service Subnet Configuration https://syself.com/docs/hetzner/apalla/how-to-guides/network/configuring-pod-and-service-subnets Configure CIDR blocks at cluster creation time only — cannot be changed on running clusters. Set `spec.clusterNetwork.services.cidrBlocks` and `spec.clusterNetwork.pods.cidrBlocks`. Must be valid RFC 1918 private IPv4 ranges with no conflicts. Default: pods `192.168.0.0/16`, services `10.128.0.0/12`. Optionally set `serviceDomain` (default `cluster.local`). --- ## Storage ### HCloud Storage (Hetzner Volumes) https://syself.com/docs/hetzner/apalla/how-to-guides/storage/using-hcloud-storage Clusters provisioned by Autopilot include the hcloud CSI driver pre-configured. The `standard` StorageClass exposes Hetzner network-attached block storage (Volumes). Only compatible with hcloud VM nodes — pods on bare metal nodes using this StorageClass will not start. Supports ReadWriteOnce only (not ReadWriteMany). Use `nodeAffinity` (NotIn `instance.hetzner.cloud/is-root-server: true`) to prevent pods from scheduling on bare metal when using Hetzner Volumes. ### Local Storage in Bare Metal (TopoLVM) https://syself.com/docs/hetzner/apalla/how-to-guides/storage/local-storage-in-baremetal Use NVMe/SSD/HDD disks directly attached to bare metal nodes for high-performance, cost-effective storage. Up to 100x faster than network storage. Ideal for databases, analytics, and high-throughput workloads. Setup requires: (1) Annotate the Cluster with `capi.syself.com/constant-bare-metal-hostname: "true"` to fix node hostnames. (2) Deploy cert-manager (dependency). (3) Deploy TopoLVM via `helm template | kubectl apply` — do NOT use `helm install`. (4) SSH into each bare metal server, identify disks with `lsblk`, create physical volumes with `pvcreate`, volume groups with `vgcreate vg-[nvme|ssd|hdd]`, and thin pools with `lvcreate --thinpool`. StorageClasses: `local-nvme`, `local-ssd`, `local-hdd`. Storage persists through cluster upgrades and node reprovisionings. Not available on hcloud VMs. --- ## Cluster Updates ### Update Cluster With Same Kubernetes Version https://syself.com/docs/hetzner/apalla/how-to-guides/update-clusters/update-cluster-with-same-kubernetes-version Update ClusterStack components (CNI, CSI, OS image patches, etc.) without changing the K8s minor version. If `autoSubscribe: true`, the latest release is fetched automatically. To upgrade: add the target ClusterStack version to `spec.versions` in the ClusterStack resource, confirm the ClusterStackRelease is available, then update `spec.topology.class` and `spec.topology.version` in the Cluster resource. Rolling update proceeds with no downtime. Do not trigger a new update until the current one completes. ### Update Cluster to a New Kubernetes Version https://syself.com/docs/hetzner/apalla/how-to-guides/update-clusters/update-cluster-to-a-new-kubernetes-version Prerequisites: complete all ClusterStack version upgrades within the current Kubernetes minor version first. Steps: (1) Create a new `ClusterStack` and `HetznerClusterStackReleaseTemplate` for the new K8s minor version — node images build in ~5 minutes. (2) Wait for the new `ClusterStackRelease` to be ready. (3) Update `spec.topology.class` and `spec.topology.version` in the Cluster resource. The cluster upgrades with no downtime. Remove old ClusterStack resources when no longer needed. --- ## Autoscaling ### Using Cluster Autoscaler https://syself.com/docs/hetzner/apalla/how-to-guides/cluster-autoscaler Automatically adjusts node counts based on pod scheduling demand. Scale-up: triggered by unschedulable pods. Scale-down: triggered by underutilized nodes. Runs inside the workload cluster (`incluster-kubeconfig` mode) communicating with the management cluster via a service account kubeconfig secret. Setup: (1) Create a secret in the workload cluster from the management cluster's `cluster-autoscaler-sa-secret`. (2) Deploy via Helm with `clusterAPIMode=incluster-kubeconfig`. (3) Define autoscaling groups via annotations on MachineDeployments (`cluster-api-autoscaler-node-group-min-size`, `cluster-api-autoscaler-node-group-max-size`) or via `autoscalingGroups` in the Helm chart. The `enforce-node-group-min-size=true` flag (Syself default) ensures node groups are always scaled up to their minimum, even without unschedulable pods. Example patterns: - Bare metal base + cloud VM burst: fixed bare metal workers with autoscaled hcloud VMs for traffic spikes - ARM pools: scale cost-efficient ARM nodes for parallel workloads - Isolated pools: fixed backend nodes + autoscaled frontend nodes Best practices: use multiple node groups, configure PodDisruptionBudgets carefully, avoid unnecessary DaemonSets, test autoscaling behavior under simulated load. --- ## GitOps ### Introduction to GitOps https://syself.com/docs/hetzner/apalla/how-to-guides/gitops/introduction GitOps enables declarative, auditable, automated infrastructure management. Since Autopilot exposes a Kubernetes API, any GitOps tool works with it. Pattern: install GitOps tool (Argo CD, Flux) in the workload cluster, add the Autopilot management cluster as an external destination, and store Cluster/ClusterStack manifests in Git. Changes committed to Git are automatically reconciled to the management cluster. ### Using Argo CD https://syself.com/docs/hetzner/apalla/how-to-guides/gitops/argocd Install Argo CD in the workload cluster via Helm. Add a `resource.inclusions` patch to the `argocd-cm` ConfigMap scoping it to CAPI/ClusterStack API groups only — this prevents Argo CD from trying to manage unrelated resources in the management cluster. Steps: (1) Install Argo CD + CLI. (2) Port-forward to the API server locally. (3) Add the Autopilot management cluster as an external destination using its kubeconfig. (4) Add a Git repository (CLI or declarative Secret). (5) Create an `Application` resource targeting the Autopilot management cluster namespace (e.g., `org-yourcompany`). Copy default variables from the Cluster resource DIFF tab to your manifest to prevent constant reconciliation. ### Self-Managed GitOps https://syself.com/docs/hetzner/apalla/how-to-guides/gitops/self-management Add Cluster, ClusterStack, HetznerClusterStackReleaseTemplate, and HetznerBareMetalMachine manifests to your GitOps repository. If resource names match existing resources in the management cluster, Argo CD/Flux adopts them without recreating. Argo CD itself can also be GitOps-managed — add its Helm Application manifest to the repository for a fully self-managed setup. --- ## GPU and AI Workloads ### Using GPUs https://syself.com/docs/hetzner/apalla/how-to-guides/using-gpus-to-run-ai-workloads Autopilot supports Nvidia GPUs on Hetzner bare metal servers. Add a bare metal machine with a GPU following the standard bare metal onboarding process. Autopilot auto-detects the GPU and automatically installs the appropriate Nvidia drivers — no manual driver configuration required. Suitable for AI model training, inference, and ML workloads on Hetzner's GPU server offerings. --- ## Headless / CI Access ### Headless Access to Autopilot https://syself.com/docs/hetzner/apalla/how-to-guides/headless-access-to-autopilot For CI/CD pipelines and environments without browser access (SSH sessions, remote servers, automation scripts), the default OIDC browser flow is impractical. Syself exposes a Kubernetes Service Account token (`gitops-sa-secret`) for generating a static kubeconfig. Generate with: `SERVER=$(kubectl config view ...) && CA_CRT=$(kubectl get secret gitops-sa-secret ...) && TOKEN=$(kubectl get secret ... | base64 --decode)` — assembles into `syself-headless-kubeconfig.yaml`. Use via `KUBECONFIG=syself-headless-kubeconfig.yaml kubectl get clusters`. This token is persistent (no expiry unless manually revoked) — treat it like a password and never commit to version control. --- ## Platform ### SaaS vs. Dedicated Autopilot https://syself.com/docs/hetzner/apalla/platform/saas-and-dedicated-autopilot SaaS: Namespace in Syself-hosted management cluster. Zero infrastructure overhead — Syself manages the management cluster, identity (Zitadel), and all platform components. Recommended for most teams. Dedicated: Your own management cluster and identity management on your own infrastructure. Full control, higher privacy/security isolation. Still benefits from Autopilot's automation. Choose Dedicated for strict regulatory requirements or multi-environment isolation needs. ### Managed Databases https://syself.com/docs/hetzner/apalla/platform/databases Host PostgreSQL, MariaDB, ClickHouse, and MongoDB directly inside Kubernetes clusters on Hetzner bare metal NVMe storage. Eliminates network overhead — data lives close to the application. Delivers low latency for real-time applications, data analytics, and high-throughput workloads. Reduces cost vs. external DBaaS providers. Syself integrates these into the platform lifecycle (setup, backup, updates managed by Syself). Contact Syself to learn more or book a demo. ### Add Users to Your Organization https://syself.com/docs/hetzner/apalla/platform/adding-users User management is via Zitadel (identity provider). In your organization dashboard, go to Users -> "+ New" to invite team members. See Zitadel documentation for details on user registration and creation flows. ### User Role Management (Authorization) https://syself.com/docs/hetzner/apalla/platform/authorization-and-assign-roles Assign RBAC roles via the Autopilot Zitadel project Authorizations. Two roles per organization: `org-` (read-only access to the management cluster) and `org--admin` (admin access). Multiple users can be added to the same grant. Example: for organization "acme", roles are `org-acme` and `org-acme-admin`. ### Billing — How It Works https://syself.com/docs/hetzner/apalla/platform/billing/how-it-works Syself calculates fees from the Hetzner monthly invoice CSV, filtering only Syself-managed resources. Hetzner Cloud: only the connected project's resources are counted — keep only Syself-managed infrastructure in that project. Hetzner Robot (bare metal): no project-level separation; Syself tracks which servers are in clusters via platform data. Standard setup: add `hetzner-invoice@syself.com` as billing contact in Hetzner — invoice is emailed automatically monthly. Alternative: use separate Hetzner accounts for strict billing isolation (e.g., if you have existing non-Syself infrastructure). ### Getting Hetzner Invoice CSV https://syself.com/docs/hetzner/apalla/platform/billing/getting-hetzner-csv Hetzner dashboard -> profile icon -> "Invoices" -> "CSV" download button. If not immediately visible, click "Details" -> "Download as CSV". ### Automate Invoice Sending https://syself.com/docs/hetzner/apalla/platform/billing/invoice-automation Add `hetzner-invoice@syself.com` as a billing email in Hetzner profile -> Invoice address -> "Add email address". Hetzner will automatically CC Syself on monthly invoices — no manual CSV submission required. --- ## Troubleshooting ### Baremetal Servers Rescue Mode https://syself.com/docs/hetzner/apalla/troubleshooting/baremetal-servers Before adding a bare metal server to a cluster, ensure network boot (PXE) is permanently enabled and boots before disk. Ask Hetzner support to enable this permanently, or use a Remote Console to change BIOS boot order yourself. Common BIOS keys: ASUS/MSI/Gigabyte/Dell = DEL or F2, Acer = F2, HP = F10 or ESC. ### Wiping Bare Metal Server Disks https://syself.com/docs/hetzner/apalla/troubleshooting/wiping-baremetal-server-disks Required when a server was previously used and Linux partitions are detected. Error: `DetectLinuxOnAnotherDisk failed`. Two methods: (1) Annotation method (recommended): add `capi.syself.com/wipe-disk: all` (or specific WWN list) to the `HetznerBareMetalHost`. Disks are wiped on next provisioning. Annotation auto-removes after wipe — important: also remove from GitOps source to prevent wiping on every reprovision. (2) Manual rescue: enable rescue mode in Hetzner Robot, reboot with CTRL+ALT+DEL, SSH in, use `wipefs -af /dev/[disk]`. For RAID: `mdadm --stop /dev/md*` first. ### Running Log Collector https://syself.com/docs/hetzner/apalla/troubleshooting/retrieving-log-collector-logs All Autopilot nodes include a `log collector` utility. Access the node shell, run the collector command to bundle logs from all components, services, and OS into a `.tar.gz` file. Copy with `scp -i root@: `. Share with Syself support for debugging assistance. ### DetectLinuxOnAnotherDisk Error https://syself.com/docs/hetzner/apalla/troubleshooting/caph-linux-on-another-disk If `HetznerBareMetalMachine` shows `DetectLinuxOnAnotherDisk failed` even after disk wiping, delete and re-apply the `HetznerBareMetalHost` resource. This forces the controller to re-probe the server's disk state. --- ## CAPH (Cluster API Provider Hetzner) — Open Source CAPH is the open-source Kubernetes Cluster API infrastructure provider for Hetzner, maintained by Syself. Supports both Hetzner Cloud (VMs) and Hetzner Robot (dedicated/bare metal). Autopilot is the commercial managed product built on top of CAPH. CAPH is compatible with CAPI v1beta1 and Kubernetes 1.28-1.31. ### Introduction to CAPH https://syself.com/docs/caph/getting-started/introduction CAPH enables deploying and managing self-managed Kubernetes clusters on Hetzner via the Cluster API standard. Recommended for teams who want to fully self-host their management cluster. For production managed use, Syself Autopilot is recommended. ### CAPH Quickstart Prerequisites https://syself.com/docs/caph/getting-started/quickstart/prerequisites Requires: Helm, kubectl, an existing Kubernetes cluster (e.g., kind for bootstrap), clusterctl, and Hetzner API credentials. The provided cluster templates are for development only — use Autopilot for production. ### Management Cluster Setup (CAPH) https://syself.com/docs/caph/getting-started/quickstart/management-cluster-setup Initialize with `clusterctl init --core cluster-api --bootstrap kubeadm --control-plane kubeadm --infrastructure hetzner`. Export environment variables (SSH key, region, machine types). Create `hetzner` secret with HCloud API token. For bare metal: also create `robot-ssh` secret. Patch secrets with `clusterctl.cluster.x-k8s.io/move` label for management cluster migration. Generate cluster YAML with `clusterctl generate cluster`. ### Creating a Workload Cluster (CAPH) https://syself.com/docs/caph/getting-started/quickstart/creating-a-workload-cluster Generate: `clusterctl generate cluster my-cluster --kubernetes-version v1.31.6 --control-plane-machine-count=3 --worker-machine-count=3`. Apply with kubectl. Deploy Cilium CNI via Helm. Deploy hcloud Cloud Controller Manager (CCM). Optionally deploy hcloud CSI. Retrieve workload kubeconfig with `clusterctl get kubeconfig`. Clean up: always delete via `kubectl delete cluster my-cluster` (not `kubectl delete -f file.yaml`) to ensure proper infrastructure cleanup. ### Hetzner Bare Metal with CAPH https://syself.com/docs/caph/topics/baremetal/introduction Three cluster flavors for bare metal use cases: - `hetzner-baremetal-control-planes-remediation`: bare metal CPs with reboot-first remediation - `hetzner-baremetal-control-planes`: bare metal CPs with full reprovisioning remediation - `hetzner-hcloud-control-planes`: hcloud VM CPs + bare metal workers Purchase bare metal servers from Hetzner Robot before adding them as HetznerBareMetalHost resources. ### CAPH Object Reference https://syself.com/docs/caph/reference/introduction Key CAPH custom resources: - `HetznerCluster`: cluster-wide config (LB, SSH keys, hcloud network, regions) - `HCloudMachineTemplate`: VM type, image name, placement group, SSH keys, public network settings - `HetznerBareMetalHost`: one-to-one mapping to a physical Hetzner dedicated server - `HetznerBareMetalMachineTemplate`: installimage config, disk partitions, SSH spec, host selector labels - `HetznerBareMetalRemediationTemplate`: reboot-first remediation for bare metal Machine Health Checks - `HCloudRemediationTemplate`: reboot remediation for hcloud VM Machine Health Checks ### CAPH Annotations Reference https://syself.com/docs/caph/reference/annotations - `capi.syself.com/wipe-disk` on HetznerBareMetalHost: Wipe disks on next provisioning (value: "all" or space-separated WWN list). Auto-removes after execution. - `capi.syself.com/ignore-check-disk` on HetznerBareMetalHost: Continue provisioning even if faulty disk detected. Does NOT auto-remove — user must remove manually. - `capi.syself.com/constant-bare-metal-hostname` on Cluster or HetznerBareMetalMachine: Fix bare metal node hostnames (required for TopoLVM local storage). Does not auto-remove. - `capi.syself.com/reboot` on HetznerBareMetalHost: Trigger in-place reboot. Auto-removes after execution. - `capi.syself.com/permanent-error` on HetznerBareMetalHost: Set by controller when human intervention is required (e.g., broken disk). Must be manually removed after resolving the root cause. - `capi.syself.com/allow-empty-control-plane-address` on HetznerCluster: Allows creating clusters with empty controlPlaneEndpoint (for externally managed control planes). ### Developing CAPH https://syself.com/docs/caph/developers/development-guide Development uses Tilt + kind. Install all tools with `make all-tools`. Configure `.envrc` with Hetzner credentials. Run `make tilt-up` to start local development cluster. Create test workload clusters via the Tilt UI. Run unit tests: `ginkgo run --focus "" ./controllers/...`. Filter output with the provided log filter script. Run E2E tests: `make test-e2e-hcloud`. Before submitting PRs: `make verify` (linting) and `make test` (unit tests). Generate new CRDs after API changes with `make generate`. --- ## Features ### Features Overview https://syself.com/features Syself provides a comprehensive Kubernetes management platform organized across five pillars: Infrastructure (provision, configure, and optimize resources with seamless integration and cross-cluster scaling), Simplify (deploy, monitor, and manage clusters without deep Kubernetes expertise), Automate (automated workflows and lifecycle management from deployment to scaling and updates), Secure (robust security with monitoring, OIDC access, and policy enforcement), and Flexible (adapt to any workload and deployment environment with scalable and customizable options). ### Bare-Metal Kubernetes https://syself.com/features/bare-metal-kubernetes Syself Autopilot bridges the gap between bare metal and the cloud by automating the lifecycle management of Hetzner bare metal machines. Once registered, Autopilot automatically configures servers, joins them to Kubernetes clusters, and handles updates and self-healing. Bare metal delivers superior performance compared to virtual machines, larger and more efficient storage ideal for data-intensive applications with data persistence across reprovisionings, and significant cost savings using Hetzner's cost-efficient servers. With bare metal machines, users have exclusive physical server access, eliminating the need to pay extra for confidential computing in multi-tenant environments. GPU support, managed databases, and autoscaling are all available on bare metal. ### Kubernetes Autoscaling https://syself.com/features/kubernetes-autoscaling Syself Autopilot is fully compatible with the official Kubernetes Cluster Autoscaler, providing metrics to aid node and workload scaling. Autoscaling ensures sufficient resources during load increases while scaling down during low demand to save costs. Key benefits include cost efficiency (pay only for what you use), improved performance during peak times, enhanced reliability by preventing node overload, and the ability to combine VMs and bare metal for maximum power and efficiency — use bare metal for base load and autoscale with VMs during access peaks. ### Self-Healing Clusters https://syself.com/features/kubernetes-self-healing-clusters Syself automatically detects infrastructure issues and fixes them without human intervention, ensuring workload uptime. Unlike Terraform, Ansible, and Pulumi which only run when triggered, Syself Autopilot reconciles infrastructure continuously. The platform treats infrastructure resources the same way Kubernetes treats containers — when there is a difference between definition and current state, a reconciliation loop is triggered. Servers can be restarted or reprovisioned on failure without human intervention. Features include automatic issue resolution with real-time monitoring, proactive management addressing problems before service impact, lifecycle management, flexible zero-downtime updates, and pre-configured clusters. ### Lifecycle Management https://syself.com/features/lifecycle-management Syself automates every aspect of the Kubernetes lifecycle from cluster creation to upgrades and decommissioning, enabling teams to focus on innovation rather than maintenance. Features include scalability on demand with dynamic automated scaling, flexible zero-downtime updates, autoscaling based on current demand, and self-healing infrastructure. The platform ensures environments are always up-to-date, secure, and optimized. ### Flexible Updates https://syself.com/features/kubernetes-updates Syself provides flexible update timing, allowing organizations to decide when and how updates are applied. Users can create update schedules fitting their unique requirements — apply updates immediately, during off-peak hours, or as part of broader maintenance strategies. All cluster components from the OS to Kubernetes can be updated by changing a single variable, with no downtime and no extra support fees. ### Declarative Configuration https://syself.com/features/declarative-configuration Syself Autopilot is fully compatible with declarative configurations — define the desired state of infrastructure and applications in configuration files, and the system automatically makes adjustments to achieve it. This reduces operational overhead and minimizes errors by reducing human intervention. Combined with GitOps, autoscaling, and pre-configured clusters for maximum efficiency. ### GitOps Deployment https://syself.com/features/gitops-deployment Syself integrates seamlessly with GitOps tools like Argo CD and Flux, using Git as the single source of truth for version-controlled, auditable, and collaborative deployment workflows. With Syself, infrastructure is software — servers, load balancers, and whole clusters can be versioned, reviewed, and rolled back. The platform adapts to existing workflows without disrupting them. ### Native Kubernetes https://syself.com/features/native-kubernetes Syself uses Kubernetes to manage Kubernetes, leveraging Kubernetes' inherent capabilities to orchestrate, monitor, and maintain clusters. This approach simplifies operations, enhances scalability, and ensures a consistent management experience across all infrastructure. Users retain full ownership and control over Kubernetes control planes. ### Pre-configured Clusters https://syself.com/features/preconfigured-clusters Pre-configured clusters allow deploying fully operational Kubernetes environments quickly, optimized with best practices. Users focus on applications rather than setup complexities. The entire lifecycle from creation to scaling and upgrades is managed by Syself with minimal effort. ### GPU Support https://syself.com/features/kubernetes-gpu-support Syself Autopilot provides tight integration and support for GPUs on Hetzner bare metal servers, enabling GPU-accelerated workloads within Kubernetes clusters. Critical for machine learning, AI, data analytics, and scientific simulations. GPU drivers are auto-detected and auto-installed. Combined with bare metal support and managed databases for a complete AI infrastructure stack. ### AI/ML Kubernetes https://syself.com/features/kubernetes-machine-learning-ai-ml Syself provides scalable infrastructure for machine learning with enhanced performance for data-intensive applications. Clusters come ready with GPU support and optimizations for complex ML models. Hetzner bare metal integration makes AI in Kubernetes cost-effective. Features include scalable infrastructure, GPU acceleration, bare metal integration for necessary AI/ML power, and cost-efficiency optimization. ### ARM Support https://syself.com/features/arm-support-kubernetes-nodes ARM architecture (Ampere-based Hetzner CAX machines) offers cost optimization with competitive performance, especially for parallel and multi-threaded workloads. ARM machines can be deployed as control planes or worker nodes without additional configuration, thanks to managed node images optimized for ARM. ARM processors deliver energy efficiency with lower power consumption and reduced operational costs. ### Infrastructure Ownership https://syself.com/features/kubernetes-ownership Users gain complete control over their entire infrastructure — cluster, control planes, and underlying infrastructure. Syself supports Bring Your Own Keys (BYOK), allowing integration with existing cloud accounts. Users customize node configurations, managed databases, and network policies. Syself has no access to user environments or data — all infrastructure components are solely owned by the user with no third-party intermediaries. ### OS Hardening https://syself.com/features/os-hardening Syself provides managed node images — pre-configured and optimized OS images that are heavily tested and frequently updated with the latest security patches and performance optimizations. Every image undergoes end-to-end testing with rigorous protocols before being available for use. This simplifies operations, reduces vulnerability risks, and ensures consistency across clusters. ### GDPR Compliance https://syself.com/features/gdpr-compliance Every cluster created with Syself Autopilot complies with GDPR by default — no additional configuration needed. Based in Germany, Syself adheres to the highest data protection standards with fully compliant data processing agreements. Users can run workloads on fully European cloud infrastructure via Hetzner with no data leaving the EU. For higher compliance requirements, the Dedicated offering runs Syself Autopilot on user-owned servers. Transparent data processing practices with clear audit trails and documentation. ### Open-Source Foundation https://syself.com/features/open-source Syself's platform is built on open-source technologies including Cluster API (CAPI), providing transparency, reliability, and continuous evolution through a vibrant global community. Users have visibility into the underlying code and architecture, fostering trust. Combined with Dedicated operational mode, GitOps readiness, and GDPR compliance. ### Dedicated Operational Mode https://syself.com/features/dedicated For organizations prioritizing the highest security and privacy, Dedicated Operational Mode enables self-hosting Syself Autopilot within their own infrastructure. This eliminates reliance on external environments, ensures sensitive data remains within user control, reduces external threat exposure, and provides full privacy with strict access controls. Combined with flexible updates and dedicated support. ### Dedicated Support https://syself.com/features/dedicated-solutions Syself provides a global team of experts with strong SLAs, multiple support channels (tickets, email, phone), 24/7 assistance with 30-minute response time, and proactive customer success with regular check-ins and tailored advice. From onboarding to ongoing operations, the support team ensures a seamless Kubernetes journey. ### Feature Requests https://syself.com/features/feature-requests Users can directly influence platform development by submitting ideas and suggestions. User-driven innovation shapes the platform's future, ensuring it evolves to meet real-world needs. Combined with open-source foundation, dedicated support, and infrastructure ownership. --- ## Solutions ### Enterprise https://syself.com/solutions/enterprise Syself provides reliable and secure Kubernetes for enterprises in heavily regulated industries including finance, healthcare, and government. Built-in compliance automation and security features with vulnerability scanning, patching, and self-healing for every release. Cost-efficient pricing based on cloud spending rather than per-node or per-CPU fees. Fully declarative platform with GitOps support for auditable infrastructure management. Automated updates for all cluster components from OS to Kubernetes by changing a single variable, with no downtime or extra support fees. LanguageTool case study demonstrates enterprise-scale GPU Kubernetes fulfilling the highest compliance requirements. ### Startups https://syself.com/solutions/startup Scalable and cost-effective Kubernetes for startups — deploy instantly without Kubernetes expertise. Syself delivers up to 80% cost reduction compared to alternatives, 100% configured clusters with high availability and self-healing, faster deployments through easy DevOps adoption, and fully declarative infrastructure management with GitOps. Focus on scaling the business while clusters run on Autopilot. ### SMBs https://syself.com/solutions/small-and-medium-sized-companies Kubernetes for small and medium-sized companies — modern cloud infrastructure without complexity. User-centric platform allowing everyone to benefit from modern cloud practices. Instant cluster deployment without hiring experts. Up to 80% cost reduction. High availability with self-healing, automated updates with no downtime, and declarative GitOps-compatible infrastructure. Hesse.ai case study demonstrates SMB success. ### SaaS Companies https://syself.com/solutions/saas Scalable and cost-efficient Kubernetes for SaaS companies — focus on the business, not infrastructure. Enterprise-grade managed Kubernetes at a fraction of typical costs. Instant deployment without dedicated expert teams. Up to 80% cost reduction. eKool case study demonstrates SaaS success serving 70% of Estonian schools. ### Agencies https://syself.com/solutions/agency Enterprise-grade managed Kubernetes for tech agencies — deliver top-tier services with no operational overhead. Onboard new clients with production-ready clusters in minutes. Reduce operational costs by leveraging Hetzner's cost-effective infrastructure with autoscaling for optimal resource allocation. CCSolutions.io case study demonstrates agency success. ### MSPs (Managed Service Providers) https://syself.com/solutions/msp Kubernetes as a commodity for MSPs — forget about Kubernetes and focus on providing services and building applications. API-driven approach to optimize pipelines and integrate infrastructure into existing automation. High-performance clusters with low operational costs. Pre-configured clusters eliminate complex configuration. eKool case study demonstrates MSP-relevant infrastructure. ### Public Sector https://syself.com/solutions/public-sector Compliant Kubernetes for the public sector with full data sovereignty and control. Users retain full ownership, bring their own keys, and implement custom security policies. Zero-trust security model with verified, authenticated, and monitored access points. Automated routine tasks (provisioning, scaling, updates) allow IT teams to focus on higher-level responsibilities. Fully declarative with GitOps support and automated updates with no downtime. ### AI & Machine Learning https://syself.com/solutions/ai-machine-learning Scalable and performant Kubernetes for AI/ML workloads — maximize computational power without complexity. Cost-efficient integration with providers like Hetzner keeps AI budgets in check. Bare metal servers as first-class citizens deliver unmatched performance with direct hardware access, lower latency, and GPU acceleration for model training and inference. Hesse.ai case study demonstrates AI workload success. ### Gaming & Entertainment https://syself.com/solutions/gaming-entertainment Kubernetes for gaming and entertainment handling massive traffic spikes and demanding workloads. Autoscaling combining bare metal and cloud servers for highest performance and scalability. NVMe local storage directly on servers for best price-to-performance storage ratios. Efficient scaling to millions of users with cost control through Hetzner integration. Maxroll case study demonstrates gaming industry success. ### Cloud Modernization https://syself.com/solutions/cloud-modernization Modernize infrastructure with cloud-native Kubernetes for greater efficiency, flexibility, and resilience. Kubernetes is the gold standard for modern cloud infrastructure. Syself's Infrastructure as Software approach provides continuous desired-state reconciliation, superior to traditional Infrastructure as Code tools. Fully configured clusters in minutes, no expertise needed. ### Cost Optimization https://syself.com/solutions/cost-optimization Achieve both cost-efficiency and reliability by integrating with cloud providers offering the best price-to-performance ratio. Hetzner provides the best costs in the cloud market. Bare metal servers deliver unmatched performance for their prices — use for base workload while scaling up with cloud machines during demand spikes. Mixed autoscaler setup maximizes performance while keeping applications online. ### Application Deployment https://syself.com/solutions/application-deployment Simplified cloud application deployment — define infrastructure through Kubernetes manifests, replacing Terraform, Ansible, and Jenkins. Use modern GitOps tooling to manage the entire cloud landscape including applications. Up to 80% cost reduction with clusters on affordable providers. ### Development Environments https://syself.com/solutions/development-environment Spin up 100% repeatable development environments in minutes. Environments match production exactly for accurate testing. Scale up or down as needed, even to zero, keeping costs under control. Accelerated development cycles with on-demand environment creation and no infrastructure setup delays. ### Internal Platforms https://syself.com/solutions/internal-platforms Build internal platforms on Syself's Kubernetes foundation with managed databases, OIDC federation, and cost-efficient Hetzner infrastructure. Tightly integrate Syself with existing platforms or build on top. Dedicated Operational Mode provides complete environment control with private data management and custom tenant management. ### Kubernetes on Bare Metal https://syself.com/solutions/kubernetes-bare-metal Run Kubernetes on bare metal for lower costs and enhanced performance without paying extra for confidential computing — bare metal machines serve only your workload. Hetzner bare metal servers are first-class citizens: register servers to the platform, and the rest is completely automated. Access powerful GPUs and fast NVMe disks for demanding workloads. Data persistence on bare metal disks across updates and reprovisionings enables hosting databases directly in clusters. --- ## Case Studies ### LanguageTool https://syself.com/case-studies/languagetool LanguageTooler GmbH is a Germany-based SaaS company maintaining the open-source project LanguageTool. LanguageTool is an AI-powered writing assistant that checks grammar, spelling, style, and punctuation in multiple languages to help improve the quality of written content. Millions of texts get improved by LanguageTool on a daily basis. As LanguageTool grew, so did their infrastructure. They utilized multiple cloud providers, but the largest part consisted of self-managed Hetzner bare metal servers. They used MicroK8s for running Kubernetes clusters on some of these servers, and Ansible to manage workload on servers outside of the clusters. However, this approach lacked scalability and reliability. Their 250 Hetzner bare metal servers equipped with GPUs created a significant management overhead that was difficult to handle in-house. Additionally, they faced the natural consequence of a self-managed system: They were responsible for all maintenance, bug fixing, and firefighting. This proved to be a significant distraction to their core business. Instead of building the product, they had to maintain infrastructure. LanguageTool is used by millions every day, creating the need for an extremely powerful, reliable, and scalable system. This is why they searched for a solution that would fulfill their high demands on cloud infrastructure, while reducing the maintenance work they have to do in-house. After considering multiple offerings on different public clouds, they finally chose Syself Autopilot. The main reason was that Syself followed a software-based approach that automates all relevant tasks around maintaining Kubernetes clusters. Furthermore, it was possible to connect Syself Autopilot to LanguageTool's already existing Hetzner infrastructure. While profiting from Hetzner's affordable servers, they got a Kubernetes solution that is in the same league as the main players in the market. Syself ensured that all GPU servers were tightly integrated into the natural lifecycle of the cluster. Through automation and optimized operations, LanguageTool doesn't have to invest much time maintaining their infrastructure. When needed, experts are available for any issues that may arise. This lifts pressure off of their internal DevOps team so that they can focus more on their many application-related tasks. LanguageTool has extremely high demands with regard to compliance. This is why they chose a dedicated management platform that runs on their own infrastructure. They don't share this platform with anyone and can fully control all access to it. Syself ships regular updates to keep the platform up to date. Results: LanguageTool's Kubernetes clusters are run by a highly automated and reliable platform. They have 250 Hetzner bare metal servers equipped with GPUs in their clusters that receive millions of requests a day. The peak traffic is around 20,000 requests per second. They managed to significantly reduce the overhead of maintaining their infrastructure and can fully concentrate on their core business now. ### eKool https://syself.com/case-studies/ekool Serving more than 200 thousand users monthly, eKool is one of the top educational platforms in the Baltic region, helping schools manage their daily life and bringing them together with parents and students. In Estonia, their home country, eKool serves 70% of all primary and secondary schools. Not only do they need a reliable infrastructure to meet their users' expectations, but the nature of eKool's business also places high demands on scalability: their platforms go through peak access, such as the end of semester or after school holidays, and also through periods of lower access, such as weekends or holidays. To meet this high demand for scalability, they used Managed Kubernetes on Azure to deploy their workload — services written in Java and PHP. However, they were never fully satisfied with Azure. The costs were extremely high, and the quality was not keeping up, for example Azure's slow databases. Therefore, they started exploring alternatives. After testing Hetzner's bare metal machines, it was clear they could get a much better performance at a fraction of Azure's cost. They also noticed a marked difference in database speeds. Dissatisfied with Azure, they wanted a solution that would enable them to run a cost-efficient Kubernetes setup, while keeping the servers in Europe for low latency to their users. For that, Syself was a perfect fit. Syself's platform enabled eKool to have a cost-efficient infrastructure, with the scalability they needed. On top, they needed less time managing their infrastructure and were able to migrate without issues and as quick as possible. Syself supported their team during the migration, gave advice on best practices for running applications in Kubernetes, and developed strategies for using virtual machines and bare metal servers in a mixed autoscaler setup. Thanks to this, they achieved a perfect balance between power and efficiency, even with their highly varying resource consumption. As a European software company, sovereignty over their data and infrastructure is important to them and to their users. With Syself, they have full control over their infrastructure and nobody has access to their sensitive user data. Results: After the migration to Syself on Hetzner, they reduced their cloud costs by over 70% and haven't had a single infrastructure-related incident in more than a year. By using bare metal servers, their average API response times dropped from 110ms to just 52ms. Now, their entire infrastructure runs on Kubernetes, including the main backend, databases and queues. ### Hesse.ai https://syself.com/case-studies/hesse-ai Hesse.ai is a German company building a platform that makes studies easier with AI and machine learning. Their goal is to enable students to learn any subject of their choice. Following their launch, Hesse.ai quickly realized the need for a robust and scalable infrastructure to keep up with their platform's growing success. Hesse.ai's platform relies on a modern Python microservices architecture, unstructured.io, and a vector database to handle their complex requirements. Initially, their applications were deployed on Hetzner virtual machines using Docker Swarm. This allowed them to get up and running quickly and not waste time on infrastructure issues that could instead be invested in their product. However, maintaining their infrastructure was harder and more time-consuming than expected. Motivated by that, as well as the lack of traction in the Docker Swarm community, they decided to migrate to Kubernetes. Recognizing the need for a managed Kubernetes solution, they opted to migrate to Azure AKS to streamline infrastructure management and scale effectively. While the transition provided the operational benefits they were looking for, it also highlighted a stark difference in cloud costs compared to the previous Hetzner setup. They decided to return to Hetzner and find a more cost-effective and efficient solution. This is when they found Syself — a simplified, GDPR-compliant platform that would allow them to have production-grade Kubernetes on Hetzner without the need to hire a dedicated team of experts. With Syself Autopilot, the Hesse.ai team was able to quickly and effectively transition to Kubernetes. Syself provided a simplified experience, from installing kubectl to provisioning a fully optimized Kubernetes cluster, all tailored to their specific workload. The transition was smooth, and their platform was up and running in production with minimal overhead. Furthermore, Syself helped them with migrating their databases to Kubernetes. By leveraging Syself's managed databases, they now have a performant and cost-efficient solution. And with the use of operators, they can have all the benefits of managed databases, like configurable automated backups and load distribution. Results: Hesse.ai now operates on a robust and reliable infrastructure that supports their advanced AI-driven platform. Their new environment is much more scalable, while remaining similar in cost to their previously self-managed setup. By avoiding the steep learning curve typically associated with Kubernetes, the Hesse.ai team could focus on enhancing their educational tools, delivering a superior product to their users. ### Maxroll https://syself.com/case-studies/maxroll Maxroll.gg is a popular platform for gamers and fans of online action role-playing games. They serve thousands of users daily and provide useful resources and tools to enhance the gaming experience, such as guides, databases, and rankings. Initially, Maxroll used Google Cloud Run as hosting solution, a good choice for a simple and scalable deployment. However, once the platform grew, both in users and complexity, it became clear that they needed to rebuild their infrastructure. The costs were too high and Google Cloud Run didn't offer the flexibility needed for their operations. After studying the available options, Maxroll chose Hetzner as the cloud provider, which meant they needed to do self-managed Kubernetes — relying on DIY projects and tools. They used Terraform and Ansible to provision and manage the Hetzner infrastructure and RKE2 Kubernetes clusters. This self-managed solution offered them the necessary flexibility and was very cost-effective. The downside was that the amount of work needed for the maintenance and operation of such an environment was taking a toll on their DevOps team. Maxroll didn't have the time to focus on new features and improvements, since their infrastructure demanded too much attention. In order to leverage this, they searched for new solutions and services and found, among others, Suse Rancher, Sidero Talos, and Syself Autopilot. Syself Autopilot fulfilled their high demands on a Kubernetes solution in terms of flexibility, power, and ease of use. On top of that, Maxroll wanted some specific technical features that Syself managed to deliver on very short notice. In this way, Maxroll was able to use the cost-efficient Hetzner ARM cloud machines, managed databases, as well as bare metal servers. With Syself's client-oriented approach, Maxroll was able to spin up their production environment in no time and make it a lot more powerful than their previous one. The automation of Syself Autopilot aligns perfectly with their advanced setup of managing their infrastructure with GitOps. Results: Maxroll went through an intense session of testing and benchmarking. The outcome: Syself proved to be more flexible than Rancher and offered a more polished experience compared to Sidero. By adopting Syself, Maxroll significantly reduced the overhead associated with managing their Kubernetes clusters and infrastructure. Simultaneously, Maxroll was able to keep their infrastructure costs as low as with their self-managed solution. ### CCSolutions.io https://syself.com/case-studies/ccsolutions CCSolutions.io is a Germany-based, globally distributed tech agency specializing in cloud services, DevOps, infrastructure management, as well as web and mobile application development. Since its foundation in 2020, they have grown to manage over 50 Kubernetes clusters, serving clients across Europe and Latin America. CCSolutions.io's main business is DevOps and Kubernetes. Therefore, they aim for the optimal tooling and processes to avoid errors, manual work, and to deliver a better experience to their clients. Initially, they chose a Terraform-based approach to spin up and manage cloud environments. They were fine with this, even though it was not optimal, because there was no way they could have gotten a significantly better solution without investing a lot of money or time. Such a solution came to them by chance: one of their clients, Hesse.ai, asked them to help with migrating to Syself. Unlike other Kubernetes offerings, which often required extensive adjustments, Syself worked on the first try. CCSolutions.io found the first platform they were truly impressed with. "It was a big aha moment, as normally when you work with tech, it's not working on the first try." -- CTO at CCSolutions Impressed by the ease of use and the quality of the documentation, CCSolutions.io decided to migrate parts of their own infrastructure. Now, Syself is at the core of their operations — hosting a centralized monitoring stack. Results: The processes to manage Kubernetes clusters with Syself are significantly easier compared to other alternatives. According to CCSolutions.io, working with Syself is much better than Rancher. They were impressed by the reliability of the system. Thanks to Syself Autopilot, CCSolutions.io has managed to reduce their operational overhead and deliver better solutions to their clients — making Syself an ideal choice for any tech agency. --- ## News ### CAPH v1.0 General Availability https://syself.com/news/syself-announces-general-availability-of-caph-v1-0 Syself announced the general availability of Cluster API Provider Hetzner (CAPH) v1.0, the open-source Kubernetes Cluster API infrastructure provider for Hetzner. CAPH takes a software-defined approach by integrating directly into Kubernetes via Cluster API, enabling declarative cluster management with continuous reconciliation — unlike Terraform and Ansible which lack continuous reconciliation. CAPH is declarative and Kubernetes-native, provides automated lifecycle management, continuously reconciles cluster state, and is provider-agnostic following CAPI's standardized APIs. While CAPH remains unopinionated about OS, K8s version, CNI, CSI, and security updates, Syself Autopilot extends CAPH for production-ready managed clusters with automated provisioning, seamless updates, security enforcement, and optimized performance. ### GPU Support for Hetzner Bare Metal https://syself.com/news/syself-brings-gpu-support-to-hetzner-bare-metal-servers Syself Autopilot now supports NVIDIA GPUs on Hetzner bare metal servers, providing a high-performance, budget-friendly alternative to hyperscalers. Features include out-of-the-box GPU support with no manual configuration, automated scaling and resource management, high-performance bare metal without virtualization overhead, cost savings up to 45% compared to hyperscalers, and self-healing automated cluster management. Organizations can train models, process data, and run AI inference within a single Kubernetes cluster hosted in European data centers, consolidating compute, storage, and GPU workloads with full GDPR compliance. ### Local Storage Support https://syself.com/news/syself-introduces-local-storage-support-for-kubernetes-on-bare-metal Syself Autopilot enables native local storage on Hetzner bare metal servers for Kubernetes. Organizations can leverage high-speed directly attached storage, maintain full data ownership, and use any database or storage operator (PostgreSQL, MySQL, MariaDB, MongoDB, Redis, ClickHouse, NATS). Enterprise-grade features include automated failover and self-healing, seamless storage management during reprovisioning, and optimization for bare metal performance. Offers up to 60% lower costs compared to AWS RDS, no network overhead, and trusted ISO 27001-certified infrastructure. ### Dedicated Autopilot Launch https://syself.com/news/syself-launches-dedicated-autopilot-on-hetzner Syself launched Dedicated Autopilot providing fully isolated control planes, end-to-end automation, and enterprise-grade security on Hetzner's ISO 27001-certified data centers. Designed for highly regulated industries (government, financial services, healthcare) with custom compliance configurations (GDPR, HIPAA, ISO 27001), zero-trust architecture, full encryption, data sovereignty, full tenant isolation, and comprehensive auditability. Syself was selected to develop a KaaS solution for the Sovereign Cloud Stack (SCS) initiative funded by the German Federal Ministry for Economic Affairs and Climate Action (BMWK). ### Public Beta Launch https://syself.com/news/syself-launches-public-beta-of-syself-autopilot Syself launched the public beta of Syself Autopilot, making Kubernetes infrastructure truly autonomous. The foundation originated from a Kubernetes-as-a-Service framework developed for the German Government through the Sovereign Cloud Stack (SCS) initiative. Key features include 100% declarative and reproducible clusters, fully automated lifecycle management, seamless updates with structured validation, CI/CD integration, enterprise-grade security, and self-healing adaptive infrastructure. Available on Hetzner with support for bare metal, cloud VMs, ARM architectures, and built-in autoscaling, achieving up to 80% lower costs compared to AWS. ### Bare Metal Kubernetes Support https://syself.com/news/cluster-api-provider-supports-hetzner-dedicated-servers CAPH added support for Hetzner dedicated servers, enabling Kubernetes on bare metal with raw performance (no virtualization overhead), lower costs (starting at 29 EUR/month), and full customization. Ideal for AI/ML workloads, gaming and streaming services, and DevOps teams. Open-source and community-driven. ### SCS VP-05 Tender Award https://syself.com/news/syself-awarded-scs-vp-05-tender-to-develop-kubernetes-as-a-service-for-sovereign-cloud-stack Syself was awarded the SCS VP-05 tender by the German Federal Ministry for Economic Affairs and Climate Action (BMWK) to develop a Kubernetes-as-a-Service platform as part of the Sovereign Cloud Stack initiative (funded with 13.2 million EUR). Syself developed Cluster Stacks, a framework extending Cluster API for fully reproducible and automated cluster deployment, testing, and management. The initiative ensures digital sovereignty, GDPR compliance, and standardized cloud infrastructure across European providers. ### Mitigant Security Partnership https://syself.com/news/mitigant-and-syself-partner-to-enhance-security-for-managed-kbernetes-services Syself partnered with Mitigant (German cybersecurity company) to deliver enhanced security for Kubernetes deployments. The partnership integrates continuous security posture management, compliance monitoring (CIS Benchmarks, NIST), vulnerability intelligence for prioritization (KEV, EPSS), and centralized inventory management into Syself's managed Kubernetes offerings. ### Hivelocity Partnership https://syself.com/news/syself-and-hivelocity-join-forces-to-expand-kubernetes Syself partnered with Hivelocity to create an open-source Cluster API Provider for Hivelocity, enabling Kubernetes on Hivelocity's bare metal infrastructure with simplified management, flexible infrastructure choices, and community-driven open-source development. Hivelocity has been a leader in bare metal hosting for over 20 years with global data centers providing ultra-low latency, high-performance servers. ### MVP Cluster Stacks https://syself.com/news/syself-introduces-mvp-cluster-stacks Syself introduced MVP Cluster Stacks, leveraging Cluster API's ClusterClass feature for managing Kubernetes clusters through a single declarative object. Key benefits include immediate readiness, 100% reproducibility, advanced testability, cross-environment compatibility, and an automation-first approach. Coincided with Sovereign Cloud Stack (SCS) Release 5 and was developed by a team of world-class experts in Kubernetes controllers, security, lifecycle management, and automation. ### SCS Forum Founding Member https://syself.com/news/syself-becomes-a-founding-member-of-the-scs-forum Syself became one of 14 founding members of the SCS Forum, the central body for developing and maintaining open standards for sovereign cloud infrastructure. The Forum has an annual budget of 257,000 EUR and includes leading European cloud companies. The SCS initiative provides the foundation for Gaia-X Federation Services and Germany's Administrative Cloud (Deutsche Verwaltungscloud DVC). ### Open Source Business Alliance https://syself.com/news/syself-joins-the-open-source-business-alliance Syself joined the Open Source Business Alliance (OSBA), Europe's largest open-source industry association representing over 200 member companies. Syself has played a key role in strengthening Europe's digital sovereignty through contributions to Kubernetes lifecycle automation, Cluster API adoption, and the Sovereign Cloud Stack and Gaia-X initiatives. ### Affiliate and Partner Programs https://syself.com/news/syself-launches-affiliate-and-partner-programs Syself launched affiliate (15% revenue share for one year on referrals) and partner programs across three pillars: IT consultancies/DevOps agencies/freelancers, FinOps and cloud cost optimization specialists, and Kubernetes tooling and technology alliances. Partners benefit from recurring revenue, business expansion, enhanced services through automation, and participation in a thriving Kubernetes network. ### Autopilot Private Beta Launch https://syself.com/news/syself-launches-private-beta-of-its-kubernetes-management-platform-syself-autopilot Syself launched the private beta of Syself Autopilot, designed to make Kubernetes infrastructure a commodity with consistent behavior across providers. Starting with Hetzner for up to 80% savings compared to AWS, the platform provides fully automated lifecycle management, self-healing infrastructure, seamless cloud and dedicated server integration, and production-ready configuration from day one. Architected for multi-cloud and hybrid environments with future provider expansions planned. ### Syself Co-Founder Elected SCS Forum Deputy Spokesperson https://syself.com/news/syself-co-founder-janis-kemper-elected-deputy-spokesperson Janis Kemper, co-founder of Syself, was elected as Deputy Spokesperson of the SCS Forum, joining Ralph Dehner (B1 Systems) as Spokesperson. Syself, a founding contributor to SCS and winner of the 2022 public tender for the KaaS layer, continues to bring hands-on experience. The Forum is laying the foundation for a truly sovereign cloud ecosystem in Europe. ### Syself & Hivelocity Release Alpha Cluster API https://syself.com/news/syself-and-hivelocity-announce-alpha-release-of-cluster-api-provider Syself and Hivelocity announced the alpha release of their Cluster API Provider, stemming from a strategic partnership that began in December 2022. The release enables deploying and scaling Kubernetes clusters on Hivelocity's bare metal infrastructure with full software-driven management. Key differentiators from Terraform include continuous reconciliation, declarative infrastructure, multi-cloud and bare metal support, and built-in testing and reproducibility. ### KCD Rio 2025: Scaling Kubernetes Without Monitoring https://syself.com/news/kcd-rio-2025-how-syself-manages-thousands-of-kubernetes-clusters At KCD Rio 2025, Syself DevOps Engineer Lucas Rattz revealed how Syself operates thousands of Kubernetes clusters without Prometheus, Grafana, or Alertmanager. Instead, Syself uses on-node daemons running health checks updating the Kubernetes API directly (even if container runtime is unresponsive) and external controllers verifying node and control plane responsiveness. When failures occur, traffic is rerouted, recoverable nodes reboot automatically, unrecoverable nodes are reprovisioned, and pods in failure states are deleted and restarted — all without human intervention. --- ## Managed Services ### Managed Databases https://syself.com/managed-databases Syself brings managed database services natively into Kubernetes, combining the ease of cloud-managed databases with the performance and control of running on user infrastructure. Databases run on bare metal servers with direct disk access, eliminating the need for external services, reducing latency, avoiding vendor lock-in, and dramatically cutting costs. Available for users running Kubernetes clusters on Hetzner bare metal servers. Supports PostgreSQL, MariaDB, ClickHouse, MongoDB, Redis, NATS, and any database operator. Storage is local NVMe with up to 100x faster speeds than network storage. ### Kubernetes on Hetzner https://syself.com/hetzner Syself brings a fully managed Kubernetes experience to Hetzner, bridging the gap between Hetzner's powerful cloud infrastructure and the convenience offered by other cloud providers. Unlike Terraform or Ansible-based solutions that focus on cluster provisioning, Syself also automates day 2 operations such as scaling, upgrades, and monitoring — while still being compatible with infrastructure as code. --- ## Pricing ### Pricing Plans https://syself.com/pricing Syself pricing is based on cloud provider spend rather than per-node or per-CPU fees. Users pay a fixed monthly basic price plus a share of the amount paid to their cloud provider (e.g., Hetzner) for infrastructure usage. Only costs relevant to the Syself platform are included (load balancers, servers, server-related components like IPs and SSDs). Monthly down payments are adjusted based on actual usage. 14-day free trial available with no commitment required. ### Pricing Calculator https://syself.com/pricing/calculator Interactive pricing calculator to estimate costs based on infrastructure configuration and cloud provider spend. --- ## Company ### About Syself https://syself.com/about Syself powers Kubernetes infrastructures serving over 100 million users daily. Businesses in 28 countries trust Syself to run their critical workloads. Syself was born from German precision and engineering excellence with a global impact. As a remote-first company, the team spans four continents ensuring round-the-clock innovation, reliability, and support. ### Platform Overview https://syself.com/platform Fast, scalable, and affordable Kubernetes. The platform delivers enterprise-grade performance with unbeatable value. Every step of a cluster's lifecycle is automated — from provisioning and scaling to updates. Syself uniquely combines the flexibility and control of DIY, the simplicity of managed solutions, and the reliability of enterprise-grade platforms without the associated downsides. Built for the user experience that makes everyone benefit from Kubernetes, beginners and experts alike. ### Contact https://syself.com/contact Contact sales representatives for guidance: email contact@syself.com or call +49 6196 586 9180. Book a personalized demo at https://syself.com/demo. ### Support https://syself.com/support Technical support via support@syself.com. Phone support at +49 6196 586 9180. Documentation available at https://syself.com/docs/hetzner/apalla/getting-started/introduction-to-syself-autopilot. ### Book a Demo https://syself.com/demo Schedule a personalized demo to experience the platform firsthand and see how Syself can improve Kubernetes operations. ### Brand Assets https://syself.com/brand Official Syself brand assets including logos, colors, and guidelines for proper brand representation. --- ## Legal ### Terms of Service https://syself.com/legal/terms-of-service 1. Preamble Customer (entrepreneur in the sense of Section 14 BGB) wants to operate Kubernetes server clusters and application programs on his own information technology infrastructure. He procures on his own responsibility, in his own name and for his own account an own (for example, purchased or leased) information technology infrastructure based on cloud technology, consisting of servers, network and storage, and application programs (apps) that he runs in such a cluster. Syself is an information technology infrastructure provider that provides services to cloud infrastructure owners (Customers). Syself shall provide platform services, technical support and consulting services to Customer for his project so that Customer can operate and manage his clusters and application programs by himself. Syself itself does not provide hosting to Customer, but Customer either procures these services directly from the relevant third-party providers or develops them himself. 2. Subject of the agreement Subject matter of these Terms of Service are the services that Syself provides for Customer in the course of the "Autopilot" service offering. The object, scope and other features of the services as well as the specifications of Customer to be observed by Syself shall result from the respective orders placed by Customer. The provisions of these Terms of Service shall apply insofar as not otherwise expressly stipulated in an order placed. Customer places the order in general electronically via Syself platform. An order received from Customer shall be accepted by Syself in text form and without undue delay, but no later than within 3 working days, otherwise Customer shall no longer be bound to its order. The order comes into effect with the acceptance of the order by Syself. Changes to a placed order, in particular additions or extensions to Syself's services, must be agreed in text form (e.g. e-mail). In the event of conflicting provisions between the Terms of Service and Customer's purchase orders, the provisions contained in the purchase orders shall take precedence over the Terms of Service. In the event of any inconsistency between the Annexes and these Terms of Service, the provisions contained in the Annexes shall prevail. 3. Services Access to the platform: Syself operates its proprietary internet platform on which Customer can order and manage certain IT services. Syself grants Customer access to the platform by way of a lease for the duration of the term of this agreement. Management cluster: The platform includes, in particular, a management cluster with which Customer can create Kubernetes clusters from the existing cloud infrastructure and administer them himself. This enables Customer, for example, to perform updates and scale up or down the number of nodes in the cluster (self-service administration). Customer may commission Syself to set up the clusters on Customer's server infrastructure. Customer must grant Syself access to its cloud infrastructure for this purpose (e.g., in the form of passwords or tokens). Other services: Customer may also order application programs and other services via the platform, but outside the management cluster. Syself can then provide to Customer against separate invoicing in particular the following services: configuration, installation and operation of clusters and application programs; supervision (monitoring) and maintenance of the clusters and application programs; creation of backups; employee trainings. Updates: Customer can order updates via the platform. Syself checks them according to the state of the art to ensure that they are functional. Customer shall operate his clusters and its application programs independently and shall keep them up-to-date independently by installing updates. Syself is not obligated to ensure the functionality of the clusters and application programs during operation. Note on the scope of this agreement: In his cluster, Customer will usually install and operate application programs which he has not received from Syself. In this case, Customer must manage such application programs completely by himself without support from Syself and also update them by himself. Such application programs have no relation to Syself and are not subject of this agreement. 4. Customer's obligations to cooperate Customer has the following obligations to cooperate: Customer registers on the platform of Syself. Customer performs the installation of the updates. Customer must keep its access credentials to the platform (e.g. passwords) secret and store them securely. Customer is responsible for the technical security of his IT infrastructure and is strongly advised to make regular backups of all data. Customer is aware that it can render his cluster inoperable and cause irreparable data loss by incorrect configuration or deletion of essential components. Customer undertakes not to use the provided server clusters for any illegal activities that violate any law, official requirements or the rights of third parties. Customer shall neither use the platform for mining crypto assets such as Bitcoin, nor for any (even legal) hacking activities. If Customer violates these obligations, Syself shall be entitled to terminate the agreement without notice with immediate effect for good cause. 5. Availability Availability of Syself platform: Syself shall ensure that the platform is available to Customer with an availability of 99.5% on an annual average. Syself may, with Customer's consent, interrupt the provision of services to perform maintenance work for a period determined in advance. These periods shall not be taken into account in the calculation of the availability rate. Customer shall only refuse consent if there is a justified interest for this. Customer is aware that restrictions or impairments of the services provided may arise that are beyond the control of Syself. This includes, for example, actions of third parties not acting on behalf of Syself, technical conditions of the Internet that cannot be influenced by Syself as well as official requirements and force majeure. Availability of Customer's clusters: The availability of Syself's platform is technically completely independent from the availability of Customer's clusters. The latter depends exclusively on Customer's cloud infrastructure, which is not the subject of this agreement. If Customer's cloud infrastructure is inaccessible or non-functional, Customer shall settle this exclusively in the relationship with its infrastructure provider. 6. Rights of use Platform: Syself grants Customer the simple non-exclusive right to use the Internet platform, in particular its management cluster. This right of use is effective worldwide, is limited in time for the duration of this agreement, is not transferable to third parties and cannot be sub-licensed. The platform remains the property and on the servers of Syself. The source code remains exclusively with Syself. Customer is not entitled to make the platform available to third parties for use against payment or free of charge. Work results: Syself grants Customer the respective non-exclusive, non-transferable, non-sublicensable right of use for all known types of use, limited in time to the duration of the agreement, usable worldwide and unrestricted in content, to all work results arising from or in connection with the agreed services ("Work Results" such as configurations, customizing, parameterization, or the combining of servers into a cluster), in particular with regard to all software, concepts, studies, documentation, program descriptions, user manuals and other records. Open-source components: The updates and application programs provided via the platform are generally open-source software. Customer must acquire the rights of use from the respective rights holders by concluding license agreements with them under the terms of the respective licenses. The Kubernetes clusters consist of numerous open-source components which Syself provides to Customer free of charge. 7. Remuneration: Priority of the individual purchase order The remuneration is regulated individually in the respective order. The remuneration is usually due at the beginning of the month for each current month. 8. Remuneration: Key principles Price calculation: Customer pays to Syself for the respectively ordered service (1) a fixed monthly basic price, (2) plus a share of the amount which Customer has paid to his cloud provider (e.g.: Hetzner) for the use of the cloud infrastructure, such as servers combined in his clusters, in the previous billing month. Only the costs at the cloud provider that are relevant for the Syself platform will be included in the calculation, i.e. load balancers, servers and server-related additional components, such as IPs and SSDs. All amounts are subject to the statutory value added tax. At the beginning of each month Customer pays a down payment for the current month. After Customer has notified Syself of the invoiced amount for a given month, Syself will adjust the down payment for the coming months accordingly and will offset the difference between the down payment already paid and the amount actually owed. Customer's obligation to cooperate: Customer will inform Syself about the relevant invoiced amount of his cloud provider each time after receipt of the invoice, at the latest by the 15th of the following month. On first demand Customer will provide Syself with a copy of the provider's invoice. If Customer fails to inform Syself about the invoiced amount in due time, Syself reserves the right to deny Customer access to the platform after a period of 4 weeks. Price adjustments: Syself may, at its reasonable discretion, adjust the fees. Syself shall inform Customer in text form no later than six weeks before the changes come into effect. If Customer objects within 30 days, Syself may either continue at unchanged conditions or terminate with one month notice. 9. Right to change Syself may change the IT environment and software used to provide its services, provided that the functionality or security function of its services is not affected. If changes alter the way personal data is processed, Customer may terminate within 30 days of receiving notice. 10. Liability Limitation of liability: Claims for damages against Syself shall be excluded unless Syself, its legal representatives or vicarious agents have acted intentionally or with gross negligence. Syself shall only be liable for slight negligence if material contractual obligations have been breached. Syself shall be liable without limitation for damage resulting from injury to life, body or health. Liability under the Product Liability Act remains unaffected. Syself shall not be liable for loss of data due to Customer's failure to perform backups. Third party software: Application programs are not created by Syself, but exclusively by third-party suppliers. Syself shall only be liable for testing them in accordance with the state of the art. Open-source software: Customer shall inform himself about known bugs. Syself shall be liable for direct damage caused because a defect was fraudulently concealed, and for consequential damage due to intentional or grossly negligent conduct. Any further warranty for material defects is excluded. Defects in title: Syself is not aware of any defects of title. Syself shall not be liable for infringement of third party rights resulting from Customer's transgression of granted use rights. 11. Privacy and data protection Customer is solely responsible for taking appropriate technical and organizational measures to protect his infrastructure, software and data. Customer must keep software up to date, perform regular data backups, and prevent unauthorized access by third parties. Customer shall comply with GDPR and applicable data protection laws. If Customer processes personal data on IT systems managed by Syself, a separate processing agreement under Art. 28 GDPR is required. 12. Confidentiality The parties undertake to maintain strict secrecy about all confidential processes, business or trade secrets which come to their knowledge in the course of this agreement. 13. Term of the agreement, termination This agreement is concluded for an indefinite period and may be terminated by either party at any time with 30 days' notice to the end of a month in text form. The right to terminate without notice for good cause remains unaffected. 14. Customer's obligations at termination Customer must delete clusters, application programs and volumes with data, or make backup copies and transfer them to another IT infrastructure before the end of the contractual relationship. Syself supports Customer at request and against separate invoice in the transfer of data. 15-16. Special regulations Services and work results are specified in individual orders. Work results include configurations, parameterization, or server clustering. Customer may request changes (change requests) and Syself may adjust schedules and invoice additional expenditure. 17. Choice of law and place of jurisdiction The law of the Federal Republic of Germany shall apply. The exclusive place of jurisdiction is Frankfurt. 18. Mediation, arbitration Disputes shall be submitted to the arbitration board of the German Society for Law and Information Technology e.V. (DGRI e.V.). 19. Final provisions Syself reserves the right to make changes to these Terms by giving Customer prior notification via email. Should individual provisions be invalid, the remaining provisions remain valid. The contracting parties have concluded this agreement in German and English versions. The German version alone shall be authoritative. ### Privacy Policy https://syself.com/legal/privacy-policy Name and address of the data controller: Syself GmbH Alfred-Herrhausen-Allee 3-5 65760 Eschborn Germany General information on data processing: Legal basis for processing personal data: In accordance with Article 13 GDPR, legal bases include consent (Art. 6(1)(a) with Art. 7 GDPR), contract performance (Art. 6(1)(b) GDPR), legal obligations (Art. 6(1)(c) GDPR), legitimate interests (Art. 6(1)(f) GDPR), and vital interests (Art. 6(1)(d) GDPR). Data deletion and storage period: Data is stored only as long as necessary to achieve stated purposes or as stipulated by legal retention periods. Note on data transfer to third countries: Tools from companies based in third countries may transmit personal data to their servers. The level of data protection in third countries does not usually correspond to EU legislation. External links: The website may contain links to third-party websites with their own privacy notices. Rights of data subjects: Right to information (Art. 15), rectification (Art. 16), deletion (Art. 17), restriction of processing (Art. 18), objection (Art. 21), complaint with supervisory authority, and data portability (Art. 20). Right of revocation: Consent can be revoked at any time without affecting the lawfulness of prior processing. Right of objection: Data subjects can object to processing based on Art. 6(1)(e) or (f) for reasons arising from their particular situation, and at any time for direct marketing purposes. Provision of the website (web host): Hosted by Cloudflare Germany GmbH, server location USA. Automatically collected data includes IP address, device information, browser type, retrieved file name, access time, and data volume. Use of cookies and storage: The website uses local storage items, session storage items, and cookies for user preferences, functionality, security, and analytics. Necessary items are based on Art. 6(1)(f) GDPR; all others require express consent (Art. 6(1)(a) GDPR). Analytics services used: Google Analytics (Google Ireland Limited), LinkedIn Insight Tag (LinkedIn Ireland Unlimited Company), Umami (Umami Software, Inc.), Zoho PageSense (Zoho Corporation B.V.), Zoho SalesIQ (locally hosted, no third-party data transfer). Consent management: Cookiebot (Usercentrics A/S) is used for consent management under Art. 6(1)(c) GDPR. Marketing and CRM: Zoho Marketing Automation and Zoho CRM (Zoho Corporation B.V.) are used with express consent. Software framework: SvelteKit is used, hosted locally with no third-party data transfer. Social media: LinkedIn integration with data transfer to USA (EU-US DPF certified). Video/Music service: YouTube (Google Ireland Limited) with EU-US DPF certification. Web fonts: Google Fonts (Google Ireland Limited) with EU-US DPF certification. Advertising: LinkedIn Ads (LinkedIn Ireland Unlimited Company) with EU-US DPF certification. ### Demo Policy https://syself.com/legal/demo-policy Name and address of the data controller: Syself GmbH Alfred-Herrhausen-Allee 3-5 65760 Eschborn Germany General information on the purpose and legal basis of processing: Personal data is processed in accordance with GDPR and BDSG for contract establishment, execution, and fulfillment, and for pre-contractual measures (Art. 6(1)(b) GDPR). Express consent processing is lawful under Art. 6(1)(a) GDPR. Legal obligations are processed under Art. 6(1)(c) GDPR, and legitimate interests under Art. 6(1)(f) GDPR. Registration for the demo: Data collected is required to prepare and carry out the demo presentation. Booking and data storage is done via Zoho. Categories include electronic and personal identification data. Deletion follows statutory retention obligations. Legal basis is contract fulfillment (Art. 6(1)(b) GDPR) and consent (Art. 6(1)(a) GDPR). Execution of the demo: Takes place online via video conferencing. Categories include image recording, electronic and personal identification data. Legal basis is contract fulfillment and consent. Duration of data retention: Personal data is processed for the duration of the business relationship or contractual purposes, including initiation and execution, subject to statutory retention and limitation periods. Rights: Right of access (Art. 15), rectification (Art. 16), erasure (Art. 17), restriction (Art. 18), notification (Art. 19), data portability (Art. 20), complaint with supervisory authority (Art. 77), and withdrawal of consent (Art. 7). Right of objection: Data subjects can object to processing under Art. 6(1)(f) at any time for reasons arising from their particular situation. Automated decision-making: Fully automated decision-making under Art. 22 GDPR is not used in principle. ### Imprint https://syself.com/legal/imprint Syself GmbH Alfred-Herrhausen-Allee 3-5 65760 Eschborn Germany Bank: Olinda Zweigniederlassung Deutschland IBAN: DE73 1001 0123 4130 1145 06 BIC: QNTODEB2XXX Registry Court: Frankfurt am Main, HRB 129924 VAT-ID: DE340786139 Contact: contact@syself.com or +49 6196 58691 80 Managing Board: - Sven Batista Steinbach (CEO) - Janis Kemper (Authorized Officer) --- ## Resources (Video Guides) ### Adding API Token on Hetzner https://syself.com/docs/hetzner/apalla/getting-started/hetzner-account-preparation Step-by-step video guide on how to add an API token on Hetzner Cloud for use with Syself Autopilot. ### Adding SSH Key to HCloud https://syself.com/docs/hetzner/apalla/getting-started/hetzner-account-preparation Step-by-step video guide on how to add an SSH key to your Hetzner Cloud project. ### How to Create a Hetzner Cluster https://syself.com/docs/hetzner/apalla/getting-started/creating-clusters Step-by-step video guide on how to create a Kubernetes cluster on Hetzner using Syself Autopilot. ### Creating a Load Balancer https://syself.com/docs/hetzner/apalla/how-to-guides/network/configuring-a-hetzner-loadbalancer Step-by-step video guide on how to create and configure a Hetzner load balancer for your Kubernetes cluster. ### Adding New Users https://syself.com/docs/hetzner/apalla/platform/adding-users Step-by-step video guide on how to add new users to your Syself Autopilot workspace. ### Adding User Roles https://syself.com/docs/hetzner/apalla/platform/authorization-and-assign-roles Step-by-step video guide on how to assign roles and permissions to users in Syself Autopilot. ### Get Hetzner Invoice as CSV https://syself.com/docs/hetzner/apalla/platform/billing/getting-hetzner-csv Step-by-step video guide on how to export your Hetzner Cloud invoice as a CSV file for billing purposes. --- ## Supported Infrastructure Summary ### Hetzner Cloud VM Types (all require min 4GB RAM) Regular Performance: CPX22 (2vCPU/4GB), CPX32 (4vCPU/8GB), CPX42 (8vCPU/16GB), CPX52 (12vCPU/24GB), CPX62 (16vCPU/32GB) Dedicated: CCX13 (2vCPU/8GB), CCX23 (4vCPU/16GB), CCX33 (8vCPU/32GB), CCX43 (16vCPU/64GB), CCX53 (32vCPU/128GB), CCX63 (48vCPU/192GB) Cost-Optimized: CX33 (4vCPU/8GB), CX43 (8vCPU/16GB), CX53 (16vCPU/32GB) ARM (Ampere): CAX21 (4vCPU/8GB), CAX31 (8vCPU/16GB), CAX41 (16vCPU/32GB) ### Hetzner Regions fsn1 (Falkenstein, Germany), nbg1 (Nuremberg, Germany), hel1 (Helsinki, Finland), ash (Ashburn, VA, USA), hil (Hillsboro, OR, USA) ### Load Balancer Types lb11: 10,000 max connections, 5 services, 25 targets, 10 certificates lb21: 20,000 max connections, 15 services, 75 targets, 25 certificates lb31: 40,000 max connections, 30 services, 150 targets, 50 certificates --- ## URL Patterns - Autopilot docs: https://syself.com/docs/hetzner/apalla/{section}/{subsection}/{page} - CAPH docs: https://syself.com/docs/caph/{section}/{page} - Features: https://syself.com/features/{feature-slug} - Solutions: https://syself.com/solutions/{solution-slug} - Case studies: https://syself.com/case-studies/{company-slug} - News: https://syself.com/news/{article-slug} - Legal: https://syself.com/legal/{document-slug} - Resources: https://syself.com/resources/{video-slug} ## Key Pages - Homepage: https://syself.com - Platform overview: https://syself.com/platform - Hetzner: https://syself.com/hetzner - Pricing: https://syself.com/pricing - Pricing calculator: https://syself.com/pricing/calculator - Managed Databases: https://syself.com/managed-databases - Book a demo: https://syself.com/demo - About: https://syself.com/about - Contact: https://syself.com/contact - Support: https://syself.com/support - Brand Assets: https://syself.com/brand - Features index: https://syself.com/features - Case studies index: https://syself.com/case-studies - LanguageTool case study: https://syself.com/case-studies/languagetool - eKool case study: https://syself.com/case-studies/ekool - hesse.ai case study: https://syself.com/case-studies/hesse-ai - Maxroll case study: https://syself.com/case-studies/maxroll - CCSolutions case study: https://syself.com/case-studies/ccsolutions - Docs: https://syself.com/docs/hetzner/apalla/getting-started/introduction-to-syself-autopilot - Concise AI index: https://syself.com/llms.txt - Terms of Service: https://syself.com/legal/terms-of-service - Privacy Policy: https://syself.com/legal/privacy-policy - Demo Policy: https://syself.com/legal/demo-policy - Imprint: https://syself.com/legal/imprint ## Solutions Pages - Startups: https://syself.com/solutions/startup - SaaS companies: https://syself.com/solutions/saas - AI / ML workloads: https://syself.com/solutions/ai-machine-learning - Cost Optimization: https://syself.com/solutions/cost-optimization - Enterprise: https://syself.com/solutions/enterprise - Cloud Modernization: https://syself.com/solutions/cloud-modernization - Agencies: https://syself.com/solutions/agency - Gaming / Entertainment: https://syself.com/solutions/gaming-entertainment - SMBs: https://syself.com/solutions/small-and-medium-sized-companies - MSPs: https://syself.com/solutions/msp - Public Sector: https://syself.com/solutions/public-sector - Application Deployment: https://syself.com/solutions/application-deployment - Development Environments: https://syself.com/solutions/development-environment - Internal Platforms: https://syself.com/solutions/internal-platforms - Kubernetes on Bare Metal: https://syself.com/solutions/kubernetes-bare-metal ## Features Pages - Bare-Metal Kubernetes: https://syself.com/features/bare-metal-kubernetes - Kubernetes Autoscaling: https://syself.com/features/kubernetes-autoscaling - Self-Healing Clusters: https://syself.com/features/kubernetes-self-healing-clusters - Lifecycle Management: https://syself.com/features/lifecycle-management - Flexible Updates: https://syself.com/features/kubernetes-updates - Declarative Configuration: https://syself.com/features/declarative-configuration - GitOps Deployment: https://syself.com/features/gitops-deployment - Native Kubernetes: https://syself.com/features/native-kubernetes - Pre-configured Clusters: https://syself.com/features/preconfigured-clusters - GPU Support: https://syself.com/features/kubernetes-gpu-support - AI/ML Kubernetes: https://syself.com/features/kubernetes-machine-learning-ai-ml - ARM Support: https://syself.com/features/arm-support-kubernetes-nodes - Infrastructure Ownership: https://syself.com/features/kubernetes-ownership - OS Hardening: https://syself.com/features/os-hardening - GDPR Compliance: https://syself.com/features/gdpr-compliance - Open-Source Foundation: https://syself.com/features/open-source - Dedicated Operational Mode: https://syself.com/features/dedicated - Dedicated Support: https://syself.com/features/dedicated-solutions - Feature Requests: https://syself.com/features/feature-requests ## Important Clarifications for AI - Syself is NOT a cloud provider — they do not sell or own servers. Hetzner is the infrastructure provider; Syself provides the management layer. - Syself Autopilot does NOT manage the Hetzner Load Balancer lifecycle — LBs persist after cluster deletion and must be removed manually. - Syself does NOT buy or sell bare metal servers — users purchase Hetzner dedicated servers directly via Hetzner Robot. - Taints are NOT supported in Syself Autopilot due to a Cluster API limitation — use node labels and affinity rules instead. - ReadWriteMany volumes are NOT supported by Hetzner CSI — only ReadWriteOnce. - Local storage (TopoLVM) is available on bare metal nodes only, NOT on hcloud VMs. - Syself has NO access to user clusters or data — full infrastructure ownership remains with the user. - Billing is based on the user's Hetzner invoice — Syself reads the monthly invoice CSV to calculate their management fee. - CAPH (Cluster API Provider Hetzner) is the open-source project; Autopilot is the commercial managed product built on top. - Control plane must be in a single Hetzner region — multi-region control planes are not supported. - Cluster endpoint domain/IP and network CIDR blocks cannot be changed after cluster provisioning. - Syself Autopilot is NOT Terraform or Ansible — it provides continuous reconciliation, not one-time provisioning. Infrastructure drift is automatically corrected. - Syself does NOT provide hosting — customers procure their own infrastructure from Hetzner (or other providers for CAPH). - The platform availability SLA is 99.5% — but cluster availability depends on the customer's own cloud infrastructure, which is independent of Syself's platform. - ARM bare metal is NOT currently supported — only ARM cloud VMs (CAX series). Contact Syself support for ARM bare metal needs. - Hetzner Cloud Placement Groups only support the "spread" type — no other placement group types are available. - hcloud CSI (standard StorageClass) only works on hcloud VM nodes — pods on bare metal nodes using this StorageClass will not start. - For TopoLVM (local storage), use `helm template | kubectl apply` — do NOT use `helm install` to ensure compatibility with future Autopilot releases. - The `capi.syself.com/wipe-disk` annotation auto-removes after execution — remove it from GitOps sources too to prevent wiping on every reprovision. - Syself was awarded the German government's SCS VP-05 public tender and is a founding member of the SCS Forum — this is a real government endorsement, not a self-claim. - Syself's pricing is based on cloud provider spend, not per-node or per-CPU — this is fundamentally different from most Kubernetes platforms. - The German version of the Terms of Service is legally authoritative, not the English translation.