Self-hosted Kubernetes

Self-Hosted Kubernetes with K3s

Connect a dedicated server, bare-metal machine, or VM to Wodby as a budget single-server self-hosted Kubernetes environment. Wodby uses K3s as the lightweight open-source Kubernetes distribution underneath, so you keep the same Wodby stack, environment, and deployment workflow when one server is enough.

Comparing all infrastructure paths? See managed Kubernetes, self-hosted Kubernetes, and Wodby Cloud.

Setup flow

From server to Wodby-ready Kubernetes

  1. 1

    Prepare a server

    Use a dedicated server, bare-metal machine, or VM that meets the minimum requirements.

  2. 2

    Create self-hosted Kubernetes in Wodby

    Open Kubernetes > Connect server, choose the owner, and name the self-hosted environment.

  3. 3

    Run the setup command

    Run the one-time command on the target server as root or with sudo. Wodby prepares the server and connects it back to the platform.

  4. 4

    Deploy apps with Wodby

    After initialization, Wodby deploys the required infrastructure components and the cluster becomes available for app deployments.

Choosing infrastructure

Use one server when you need budget hosting, not Kubernetes scaling

This Wodby setup is intentionally single-server. K3s is a lightweight open-source Kubernetes distribution that fits that model well, while Wodby provides the platform workflow around it. For larger production systems, keep managed Kubernetes in the plan.

Good fit for budget self-hosted Kubernetes

  • Budget hosting for smaller apps where one server is enough
  • Agencies hosting multiple smaller client apps on one server
  • Development, QA, staging, and internal environments
  • Lower-traffic production apps that do not need Kubernetes scaling
  • Teams that prefer dedicated servers or VMs for cost control

Better fit for managed Kubernetes

  • Mission-critical production workloads that need stronger resilience
  • Applications that need multi-node capacity and Kubernetes scaling
  • Teams that want provider-managed control plane operations
  • Infrastructure that must grow beyond a single server cleanly
What Wodby prepares

Wodby prepares the server for app deployments

After you create the self-hosted Kubernetes environment in Wodby, the dashboard shows a generated setup command for the target server. The setup prepares a clean server as a Wodby-ready Kubernetes environment and connects it to the platform.

New self-hosted Kubernetes environments start in the Awaiting state until that command runs successfully. When initialization finishes, the environment becomes available when you create app instances.

Prepared environment

  • A lightweight Kubernetes foundation based on K3s
  • Platform components Wodby needs to run application stacks
  • A connected cluster available from Wodby when creating app instances
  • Support for repeatable stacks, environments, and deployments
  • Monitoring baseline when monitoring stays enabled

This is a one-server setup in Wodby. It is intended for workloads that fit on one server and does not provide cluster scaling from Wodby.

Server options

Run on a dedicated server, bare metal, or a VM

Self-hosted Kubernetes with K3s works well when you already have a server provider, want to standardize on lower-cost dedicated hardware, and do not need a scalable Kubernetes cluster. Hetzner is the common starting point, but the Wodby flow can work with other providers when the server meets the requirements.

Minimum requirements

  • At least 2 GB RAM and 2 CPUs
  • Dedicated, non-shared CPU
  • At least 20 GB disk space
  • Ubuntu/Debian, Fedora/CentOS, or OpenSUSE
  • amd64 machine architecture
  • Outbound internet access to reach Wodby and installation endpoints

Common server starting points

Use these as starting points for server selection. Provider pages with managed Kubernetes details remain under the broader Kubernetes section.

Start with budget single-server Kubernetes

Connect your own server with K3s, then deploy Wodby stacks through the same workflow you use elsewhere in Wodby when you do not need managed Kubernetes scaling.