Managed Kubernetes on servers you control

RunOS sets up standard Kubernetes on servers you own or rent. Deploy apps and add services through the Console or CLI. Keep the cluster credentials so you can use kubectl when you need direct access.

Move one app first

Start with an HTTP app that keeps its data outside the container. Put its build and startup steps in a Dockerfile. Record which environment variables, database connections, background jobs, and domains it needs.

Deploy it to a RunOS cluster on your servers. Test it on the cluster’s HTTPS URL before you switch DNS. If the app uses a platform-specific runtime or service, decide how to replace that dependency before you move traffic.

Use runos.yaml to record the app’s ports and resources. Keep the Dockerfile and application code in your repo. If you move again, you can reuse the container image on another Kubernetes cluster and recreate the deployment there.

What you keep if you leave

Your existing workloads keep running on the cluster if you disconnect RunOS. You can inspect and manage them with your Kubernetes credentials. Plan to replace RunOS workflows you depend on, such as builds, deploys, and managed service operations.

Moving to a different cluster still takes work. Export and restore stateful data, recreate secrets, and plan the DNS switch. RunOS keeps the application runtime portable, but it can’t move application data just by copying an image.

Choose a cluster shape

One node can run a test or a small app that can tolerate downtime. For control-plane high availability, start with three control-plane nodes. Plan app replicas and data redundancy separately: a healthy Kubernetes API does not make a single database replica redundant.

Use the clusters and nodes guide to check requirements and decide where to put your workloads.