Run Your Own Services

Syself gives you a Kubernetes cluster and the layer underneath it. It does not offer managed databases or caches to rent. You run those services yourself on the cluster.

On a managed cloud you rent those services one by one: a managed database, a managed cache, a managed queue. Each is a separate bill. Your data is stored in the vendor's systems, and you reach it only through their endpoint.

What Syself manages#

The whole layer under your workloads is Syself's product. Syself builds and tests it together and ships it with each release. It includes:

• The immutable node operating system.
• The provisioning that verifies the image and boots every machine from it.
• The controllers that replace a failed node.
• A pinned set of cluster components: Cilium for networking, the Hetzner cloud-controller-manager for load balancers, and the Hetzner CSI driver for block volumes.

Syself is accountable for that whole layer. Syself integrates the pieces, fixes them when they stop working together, and keeps them working through every upgrade. Your team does not do this work.

Everything above that layer is yours: your own workloads, which you install and operate.

flowchart BT
    subgraph yours["Yours to install, run, and upgrade"]
        direction LR
        apps["Your apps, workers, queues, caches"]
        pg["CloudNativePG: PostgreSQL"]
        jfs["JuiceFS: shared files on your bucket"]
        velero["Velero: backups to your bucket"]
    end
    subgraph syself["Syself's product: one tested unit per release"]
        direction LR
        mgmt["Management cluster: real machines matched to the objects you declared"]
        lifecycle["Node lifecycle: provision, make immutable, health-check, replace, upgrade"]
        addons["Pinned cluster components: Cilium, Hetzner CCM, Hetzner CSI"]
    end
    syself -- "healthy nodes, networking, and volumes" --> yours

The full split, item by item, and how it maps onto compliance frameworks, is in What you own, what Syself manages, and compliance .

Services you run instead of renting#

Each service you used to rent has a standard open-source replacement that runs as an operator.

An operator is software in your cluster. It installs the service and keeps it healthy.

You apply one YAML manifest that describes what you want.

From there the operator does the day-to-day work. It provisions the service, restarts it when it crashes, promotes a replica on failure, and archives backups on a schedule.

The service runs on your own cluster, and you reach it through the standard Kubernetes API.

CloudNativePG, JuiceFS, TopoLVM, and Velero are upstream projects, not Syself forks. A queue or a cache runs the same way, from its own operator or Helm chart. Each service has a how-to guide and a storage backend it fits; the storage model covers which backend suits which workload.

Running a service you own#

When you own a service, you control its whole lifecycle. Nobody deprecates your database, moves it to a new pricing tier, or schedules a maintenance window you did not choose.

You are also the one on call. When the service breaks at 03:00, you get paged. You size the resource requests, choose the retention window, and watch the operator's status while nodes upgrade.

The cluster is standard upstream Kubernetes, so everything you build stays portable. Your manifests, Helm charts, and kubectl commands work on any conformant Kubernetes cluster. So do the skills your team builds operating them. Your backups are ordinary files in your own bucket, in open formats, restorable anywhere. Syself calls this escaping the cloud.

You do not have to run all of this alone. You choose how much you operate and how much help you take, per service, in Run it yourself, or with help . What you save by owning instead of renting is in The economics of owning vs renting . To build one for real, start with Run databases .