Run It Yourself, or With Help

Normally you choose once, for all your services. Either you run everything yourself and do all the operations work, or you buy a vendor's managed service. The managed service has a cost. Your database moves into the vendor's account. It sits behind the vendor's API. If you ever leave, you migrate it out.

Syself Autopilot lets you choose per service instead of once for everything. Every service you run on it is standard Kubernetes objects in your own cluster. Run each service yourself, hand it to Syself, or pick something in between. You can switch later without moving anything.

Taking help, or ending it, changes who does the operations work. It does not change ownership. You own your cluster in your Hetzner account and the services running in it.

Why you cannot self-run the platform#

The per-service choice covers what you run on top of the platform. The platform itself has no self-run option.

The platform is Syself's product. It is one piece: an immutable node image, a fixed topology, and the cluster component stack (Cilium, DNS, metrics, storage drivers). The node image is locked read-only, so nothing on the machine changes after it ships. You do not configure this stack part by part.

You cannot assemble it yourself. It is a multi-year build, and standing it up is the smaller half; the hard part is day two, keeping it patched and upgraded release after release with the processes that make each change safe. Syself takes on that work: it provisions each machine in an isolated rescue environment, replaces nodes that fail their health checks, and rolls upgrades one control-plane node at a time, all from a separate management cluster. Everything you run on the cluster is yours. Architecture covers the split.

From self-run to fully managed#

Take PostgreSQL as the example. CloudNativePG is not part of the platform. You install it. It creates its Cluster resources, PersistentVolumeClaims, and Services in your workload cluster, the cluster your applications run in. Those objects are yours.

The table below lists five levels for a service like this. The first is your team doing everything. The last is Syself doing everything. The service and the cluster stay the same at every level.

The levels are not fixed packages. Anything between them is whatever you agree in the engagement.

Why switching is safe#

Switching levels never moves the service. Nothing is migrated, cut over, or exported. At every level, fully managed included, the service stays the same Kubernetes objects. This holds because of how the service is built, not because of a contract clause.

For PostgreSQL, those objects are a CloudNativePG database, one storage claim per copy on local disk, the internal addresses applications connect to, the Secrets that hold the credentials, and backups written to your own S3-compatible bucket in standard PostgreSQL format.

flowchart TB
    RY["Run it yourself: your team operates"]
    WH["Run it with help: Syself builds, hands over documented"]
    FM["Fully managed: Syself operates"]
    OBJ["The same standard Kubernetes objects, in your cluster, in your Hetzner account"]
    RY --- OBJ
    WH --- OBJ
    FM --- OBJ
    RY <-. "switching moves only the on-call duty" .-> FM

Because every level is standard Kubernetes, handovers work the same way in every direction.

• Take help, then take over: the handover is kubectl get cluster pg in your own cluster, and your team picks up the on-call.
• Self-run, then hand off: Syself's team starts operating objects that already exist, and the service never restarts or changes its Kubernetes identity.
• Leave entirely: the same manifests and Helm charts run on any conformant Kubernetes, and the database restores from the barman-cloud archives in your bucket.

The platform that runs those objects is not portable. What you take with you is your workloads and how you declare them, covered in Owning your services .

Access does not change with the level#

Syself's people have no standing access to your cluster, whether or not you take help. The provisioning automation is scoped to create and manage nodes, and it does not touch your data.

When you take the with-help or fully managed level, you grant access to that one service for that engagement. It ends with the engagement.

That distinction matters for an audit. Automation replacing a node is documented platform behavior you can cite. A person operating your database is an arrangement you made and scoped, so you document it that way.

The platform-side controls and how the split maps onto compliance frameworks are in What you own, what Syself manages, and compliance .

Pick per service#

A normal cluster is mixed. Each service has its own objects and its own operator, so each one can sit at its own level. Ingress and monitoring run self-hosted, because the team knows them well. PostgreSQL is fully managed, because a replicated database with verified backups is hard to run well, and many teams give it to someone experienced. Object-storage backups get set up once and left alone.

The pieces you take help with are the same open-source pieces you would run alone, not modified forks: Cilium NetworkPolicy, Service type=LoadBalancer, the Hetzner CSI storage driver, an external OIDC provider, CloudNativePG.

How to decide#

Installing the software is easy. Operating it is the hard part. Installing CloudNativePG is one helm upgrade --install command. The work comes after: responding at 3am when the primary fails over, and making a restore work when you need it.

If your team wants to run the service and learn how to operate it, run it yourself. If your team can operate it but should not spend its first weeks learning drain safety and PodDisruptionBudgets, take the one-time setup and inherit something documented. If the service is something you need but is not part of what makes your product different, let Syself operate it.

What you own, what Syself manages sets the boundary for every level here, and the economics of owning vs renting is usually what moves a service from self-run toward managed, or back. When you want fully managed, managed services from Syself is what the team builds and operates for you, on the same objects in the same cluster.