PaaS autoalojado.
Kubernetes real debajo.
Orka'i ejecuta despliegues por git-push e imagen de contenedor en K3s que tú controlas. Cada app, base de datos y cron job es un objeto Kubernetes nativo — kubectl y helm siguen funcionando y nada oculta el clúster.
- Nativo en K3s
- Builds con Kaniko
- kubectl / helm
- RBAC + 2FA
$ 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
listo ▸ orka'i app create core-api --from-git
Despliegues git-push
Haz push de una rama y Kaniko construye la imagen dentro del clúster. Sin socket Docker ni CI externo.
Recursos gestionados
Postgres, Valkey y CronJobs aprovisionados como StatefulSets, Services y Jobs reales.
Nativo en kubectl
Orka'i nunca te quita el kubeconfig. helm, k9s y tu tooling GitOps siguen funcionando.
No es un wrapper. Es el plano de control.
La mayoría de PaaS autoalojados envuelven Docker y ponen una UI encima. Orka'i añade una capa fina y opinada para builds, enrutamiento, backups y secretos — y deja el clúster totalmente expuesto debajo.
- Las cargas viven dentro de la abstracción propia de la herramienta sobre el socket Docker.
- kubectl muestra los contenedores de la herramienta, no una topología que controles.
- Superarlo implica migrar fuera de la plataforma.
- Las cargas son Deployments, StatefulSets, CronJobs y Services reales.
- kubectl y helm operan directamente sobre los mismos objetos.
- Sal cuando quieras — debajo, siempre fue Kubernetes.
Un despliegue. Objetos reales.
orka'i deploy core-api se resuelve en recursos Kubernetes nativos que puedes inspeccionar, parchear y auditar con las herramientas que ya usas.
Salida equivalente a kubectl get all -n production.
$ 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
Tus herramientas siguen llegando al clúster.
Inspecciona nodos, lista releases de Helm, observa DaemonSets y lee rutas Traefik con las herramientas que ya usas. Aprovisiona una base de datos gestionada y aterriza como StatefulSet y PVC — nada propietario en el camino.
- Inspección del clúster: nodos, Helm, DaemonSets, Traefik.
- Namespaces como entornos con RBAC y 2FA obligatorio.
- Audita todo con kubectl, helm o tu herramienta GitOps.
Lo que despliegas y gestionas.
Publica desde git o una imagen
- Despliegues git-push con builds Kaniko en el clúster
- Despliegues por imagen de contenedor para lo ya construido
- Actualizaciones rolling con health probes y rollback automático
Recursos gestionados, objetos nativos
- Postgres y Valkey gestionados con PVC y rotación de credenciales
- CronJobs de Kubernetes para tareas programadas y backups
- Ingress Traefik, dominios personalizados y TLS Let’s Encrypt bajo demanda
Ve y controla todo el clúster
- Inspecciona nodos, releases Helm, DaemonSets y enrutamiento Traefik
- RBAC con namespaces como entornos y 2FA obligatorio
- Notificaciones multicanal conectadas a eventos de despliegue y salud
Ejecútalo en hardware que posees.
Código abierto y en desarrollo activo. Instala el plano de control en un Linux nuevo o en un clúster K3s existente.