Skip to main content
// self-hosted paas · k3s-native

Self-hosted PaaS.
Real Kubernetes underneath.

Orka'i runs git-push and container-image deploys on K3s you control. Every app, database, and cron job is a native Kubernetes object — so kubectl and helm keep working, and nothing hides the cluster from you.

Self-host orka'iView source
  • K3s-native
  • Kaniko builds
  • kubectl / helm
  • RBAC + 2FA
install.sh
$ curl -sfL https://get.orkai.io | sh -
[orka'i] detecting host ······ ubuntu 24.04
[orka'i] provisioning k3s control plane
[orka'i] control plane ready in 47s
[orka'i] console ·· https://console.orkai.dev

ready ▸ orka'i app create core-api --from-git

Git-push deploys

Push a branch and Kaniko builds the image inside the cluster. No Docker socket, no external CI.

Managed resources

Postgres, Valkey, and CronJobs provisioned as real StatefulSets, Services, and Jobs.

kubectl-native

Orka’i never takes the kubeconfig away. helm, k9s, and your GitOps tooling keep working.

// why orka'i

Not a wrapper. The control plane.

Most self-hosted PaaS tools wrap Docker and put a UI on top. Orka'i adds a thin, opinionated layer for builds, routing, backups, and secrets — and leaves the cluster fully exposed underneath.

Docker-wrapper PaaS
  • Workloads live inside the tool’s own abstraction over the Docker socket.
  • kubectl shows the tool’s containers, not a topology you control.
  • Outgrowing it means a migration off the platform.
Orka’i on K3s
  • Workloads are real Deployments, StatefulSets, CronJobs, and Services.
  • kubectl and helm operate directly against the same objects.
  • Leave whenever you want — underneath, it was just Kubernetes.
// resource map

One deploy. Real objects.

orka'i deploy core-api resolves to native Kubernetes resources you can inspect, patch, and audit with the tools you already run.

Output equivalent to kubectl get all -n production.

resourcestatus
deployment.apps/core-api3/3 ready
service/core-apiClusterIP
ingress/core-apiapi.orkai.dev
cronjob/core-api-backup0 2 * * *
secret/core-api-envOpaque · 6 keys
admin@k3s-01
$ kubectl get pods -n production
core-api-7d9f8c      3/3   Running
postgres-core-0      1/1   Running

$ helm list -n production
valkey-cache   deployed   valkey-8.0.1

$ orka'i db create orders --engine postgres
created statefulset/orders + pvc (20Gi)
created secret/orders-credentials
// direct access

Your tools still reach the cluster.

Inspect nodes, list Helm releases, watch DaemonSets, and read Traefik routes with the tools you already run. Provision a managed database and it lands as a StatefulSet and a PVC — nothing proprietary in the way.

  • Cluster inspection: nodes, Helm, DaemonSets, Traefik.
  • Namespaces-as-environments with RBAC and required 2FA.
  • Audit everything with kubectl, helm, or your GitOps tool.
// capabilities

What you deploy and manage.

[ deploy ]

Ship from git or an image

  • Git-push deploys with in-cluster Kaniko builds
  • Container-image deploys for anything already built
  • Rolling updates with health-probe cutover and automatic rollback
[ run ]

Managed resources, native objects

  • Managed Postgres and Valkey with PVC binding and credential rotation
  • Kubernetes CronJobs for scheduled work and backups
  • Traefik ingress, custom domains, and Let’s Encrypt TLS on demand
[ operate ]

See and control the whole cluster

  • Inspect nodes, Helm releases, DaemonSets, and Traefik routing
  • RBAC with namespaces-as-environments and required 2FA
  • Multi-channel notifications wired to deploy and health events
// get started

Run it on hardware you own.

Open source and in active development. Install the control plane on a fresh Linux box or an existing K3s cluster.

Self-host orka'iRead the docs
one-line install
$ curl -sfL https://get.orkai.io | sh -Star on GitHub