Features/Multi-Workload Support

Multi-Workload Support

Run PHP, Python, WordPress, and more on the same Kubernetes cluster — each in its own isolated container. Unlike traditional LAMP hosting, KubePanel isn't constrained by the OS: any runtime that ships as a container image can be added as a first-class workload type.

Supported Workload Types

Admin-configurable runtimes — each domain gets its own dedicated container

PHP

FastCGI (PHP-FPM) • Port 9001

The most popular web runtime. PHP-FPM with FastCGI proxy to nginx. Configurable memory limits, execution time, upload size, and FPM pool settings.

8.0 8.1 8.2 8.3

Python

HTTP Proxy (Gunicorn) • Port 8000

Run Flask, FastAPI, or any WSGI/ASGI application. Nginx reverse proxies to Gunicorn with configurable workers and settings.

3.10 3.11 3.12
Coming Soon

Node.js

HTTP Proxy • Port 3000

Deploy Express, Next.js, Nuxt, or any Node.js application. Nginx reverse proxies to your app with WebSocket support and caching.

18 LTS 20 LTS 22

WordPress

FastCGI (PHP-FPM) • One-click preinstall

Full WordPress stack with automatic preinstall. KubePanel provisions the container, database, and runs the WordPress installer — ready to use immediately after domain creation.

PHP 8.1 PHP 8.2 PHP 8.3
Container-First Architecture

Any Workload. Zero OS Constraints.

Traditional hosting panels are built on the LAMP stack — their runtimes are tied to the operating system. Every supported language is a system package. KubePanel runs each workload in its own container: isolated, versioned, and completely independent from every other domain on the server.

Traditional LAMP Hosting (cPanel)

OS-level PHP shared across all sites — upgrading breaks others
Single Apache / mod_php process serves every domain
Adding Python or Node.js requires system package installs
One site's resource use affects all other sites on the server
Runtime options limited to what the OS distro ships
New runtimes require full panel vendor support cycle

KubePanel Container-Based

Each domain runs in its own container — PHP 8.0 and 8.3 coexist without conflict
Per-domain resource limits: CPU, memory, and storage fully isolated
Add any runtime by registering a container image — no OS changes
Containers are hermetic: one domain can't crash or starve another
Run Ruby, Go, Java, Rust, .NET — if it has a Docker image, it works
Add custom workloads yourself through the admin UI

Beyond PHP and Python — a non-exhaustive list of what you can run:

PHP 8.x (FastCGI) Python / Gunicorn WordPress Node.js / Next.js Ruby on Rails Go / Gin Java Spring Boot .NET / ASP.NET Core Rust / Actix Any container image…

How It Works

Every domain gets a purpose-built container deployment

1

Choose Workload

When creating a domain, select the workload type and version from admin-configured options. The UI dynamically loads available versions.

2

Domain CR Created

Django creates a Kubernetes Domain Custom Resource with the workload spec: type, version, container image, port, and proxy mode.

3

Operator Deploys

The Kopf operator watches for the CR and creates the deployment: app container, nginx sidecar, SFTP container, and optional Redis cache.

4

Smart Proxy

Nginx is auto-configured with the right proxy mode: FastCGI for PHP-FPM, HTTP proxy for Python/Node.js, or uWSGI for WSGI apps.

Proxy Mode Configuration

Nginx is automatically configured based on the workload type

Proxy Mode Use Case Nginx Directive Default Port
FastCGI PHP-FPM fastcgi_pass 127.0.0.1:9001 9001
HTTP Python (Gunicorn), Node.js, Django proxy_pass http://127.0.0.1:8000 8000 / 3000
uWSGI Python WSGI applications uwsgi_pass 127.0.0.1:8000 8000

Admin-Configurable Runtimes

Add custom workload types and versions through the Django admin

WorkloadType Model

Define runtime types with name, slug, default port, proxy mode, default resource limits, and display order. Activate or deactivate types without code changes.

  • Custom name and icon
  • Configurable proxy mode
  • Default CPU and memory limits
  • Active/inactive toggle

WorkloadVersion Model

Define specific versions per workload type with custom container images. Override default resource limits per version. Set defaults and control availability.

  • Custom container image URL
  • Version-specific resource overrides
  • Default version per type
  • Dynamic version loading API

Host Any Web Application

From WordPress to Python APIs, Rails to Java — one cluster, any workload, zero OS conflicts.

Get Started All Features