PaaS self-hosted.
Kubernetes de verdade por baixo.
Orka'i executa deploys por git-push e imagem de contêiner no K3s que você controla. Cada app, banco de dados e cron job é um objeto Kubernetes nativo — kubectl e helm continuam funcionando e nada esconde o cluster.
- Nativo em K3s
- Builds com 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
pronto ▸ orka'i app create core-api --from-git
Deploys git-push
Faça push de um branch e o Kaniko constrói a imagem dentro do cluster. Sem socket Docker, sem CI externo.
Recursos gerenciados
Postgres, Valkey e CronJobs provisionados como StatefulSets, Services e Jobs reais.
Nativo em kubectl
Orka'i nunca tira o kubeconfig. helm, k9s e seu tooling GitOps continuam funcionando.
Não é um wrapper. É o plano de controle.
A maioria dos PaaS self-hosted envolve Docker e coloca uma UI por cima. Orka'i adiciona uma camada fina e opinativa para builds, roteamento, backups e secrets — e deixa o cluster totalmente exposto por baixo.
- Cargas vivem dentro da abstração da ferramenta sobre o socket Docker.
- kubectl mostra os contêineres da ferramenta, não uma topologia que você controla.
- Crescer além disso significa migrar para fora da plataforma.
- Cargas são Deployments, StatefulSets, CronJobs e Services reais.
- kubectl e helm operam diretamente nos mesmos objetos.
- Saia quando quiser — por baixo, sempre foi Kubernetes.
Um deploy. Objetos reais.
orka'i deploy core-api resolve em recursos Kubernetes nativos que você pode inspecionar, patchar e auditar com as ferramentas que já usa.
Saída 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
Suas ferramentas ainda alcançam o cluster.
Inspecione nós, liste releases Helm, observe DaemonSets e leia rotas Traefik com as ferramentas que já usa. Provisione um banco gerenciado e ele vira StatefulSet e PVC — nada proprietário no caminho.
- Inspeção do cluster: nós, Helm, DaemonSets, Traefik.
- Namespaces como ambientes com RBAC e 2FA obrigatório.
- Audite tudo com kubectl, helm ou sua ferramenta GitOps.
O que você faz deploy e gerencia.
Publique a partir de git ou imagem
- Deploys git-push com builds Kaniko no cluster
- Deploys por imagem de contêiner para o que já foi construído
- Rolling updates com health probes e rollback automático
Recursos gerenciados, objetos nativos
- Postgres e Valkey gerenciados com PVC e rotação de credenciais
- CronJobs Kubernetes para trabalho agendado e backups
- Ingress Traefik, domínios customizados e TLS Let’s Encrypt sob demanda
Veja e controle todo o cluster
- Inspecione nós, releases Helm, DaemonSets e roteamento Traefik
- RBAC com namespaces como ambientes e 2FA obrigatório
- Notificações multicanal ligadas a eventos de deploy e saúde
Rode no hardware que você possui.
Código aberto e em desenvolvimento ativo. Instale o plano de controle em um Linux novo ou em um cluster K3s existente.