Pular para o conteúdo
Começar

Control plane multicloud e open source

Orquestre todas as nuvens de um só palco.

Descreva o ambiente uma vez: serviços, Postgres, cache, fila, storage, ingress e DNS. Associe cada recurso à conta e à região que fazem sentido para ele. Revise o plano, o resultado das políticas e uma estimativa do custo mensal. Depois o OrkStage aplica tudo com OpenTofu e continua de olho.

Alpha. A plataforma inteira está em fase de testes e validação. Funcionalidades e integrações com provedores são liberadas aos poucos, e as APIs ainda podem mudar. No roadmap: mini agentes de IA vinculados aos templates (segurança, FinOps, insights) que analisam planos e deploys apenas em modo leitura, usando a sua própria API key da Anthropic, OpenAI ou Gemini.

ComeçarVer o código no GitHub
Licença
AGPL-3.0
Hospedagem
Sua infraestrutura
Engine
OpenTofu
~/shop · orkCLI preview
$ ork scanScanned 38 of 214 files (91.2 KiB): walk 4 ms, scan 12 ms · terraform 6 · compose 1 · dockerfile 2Resources (7)  ID        TYPE                        PROVIDER  IMPLEMENTATION      CONFIDENCE  network   network                     aws       vpc                 high  api       compute.container-service   aws       ecs-fargate         high  worker    compute.container-service   aws       ecs-fargate         medium  database  database.postgresql         aws       rds-postgres        high  cache     cache.redis                 aws       elasticache-valkey  high  ingress   ingress                     aws       alb                 medium  dns       dns                         aws       route53             medium $ ork template pushCreated template shop 0.1.0 (DRAFT). Publish it in the console when reviewed. $ ork deploy --instance shop-staging --waitDeployment 3c1e9a52 queued for shop-staging.14:02:11 INFO  [phase:validate] Template shop@0.1.0 valid; 8 policies passed, 0 warning(s).14:02:12 INFO  [phase:plan] Plan: 7 to create, 0 to update, 0 to delete, 0 unchanged (risk low).14:02:13 INFO  [network] Provisioning Amazon VPC "ork-acme-shop-staging-network" in aws/us-east-1…14:06:40 INFO  [database] Provisioning Amazon RDS for PostgreSQL "ork-acme-shop-staging-database" in aws/us-east-1…14:14:02 INFO  [phase:verify] All health and connectivity checks passed.Deployment 3c1e9a52 succeeded.

Saída resumida. Hoje você compila o CLI ork a partir do código; ainda não há binários assinados.

Como funciona

Template, plano, deploy e observação. Cada etapa deixa um artefato que você consegue ler.

Nada chega à nuvem antes de alguém revisar o plano. O worker aplica exatamente o plano que você aprovou, recurso por recurso.

  1. 01

    Template

    Um arquivo YAML descreve a intenção sem citar provedor: uma API com duas réplicas, um Postgres replicado entre zonas, um storage versionado. Os placement slots dizem quais nuvens cada parte pode usar. Você escreve uma vez e faz deploy quantas vezes quiser.

    templates/multicloud-reference.yamlplatform/v1
    placements:  - name: primary    providers: [aws, mock]  - name: data       providers: [aws, azure, mock]  - name: storage    providers: [aws, oci, mock]resources:  - id: api    type: compute.container-service    image: catalog://sample-api    replicas: 2   cpu: 0.5   memoryMiB: 1024  - id: database    type: database.postgresql    placement: data          # bound per instance    highAvailability: zone-redundant    backup: { enabled: true, retentionDays: 7 }connectivity:  - { from: api, to: database, protocol: postgres, mode: private-preferred }

  2. 02

    Plano

    O compilador resolve cada recurso para um serviço concreto da nuvem, define nome e tags, ordena o grafo de dependências e escolhe uma estratégia de conectividade para cada ligação. O plano sai agrupado por provedor, target e região.

    Deployment planrisk: low
    Deployment Plan Instance: Acme Production AWS / aws-prod / us-east-1  CREATE Amazon VPC network  CREATE Amazon ECR (private) registry  CREATE Amazon ECS on Fargate api  CREATE Amazon ECS on EC2 capacity worker  CREATE Application Load Balancer ingress  CREATE Amazon Route 53 + ACM certificates dns AZURE / azure-data / eastus  CREATE Azure Database for PostgreSQL Flexible Server database OCI / oci-storage / us-ashburn-1  CREATE OCI Object Storage storage Cross-cloud  CONFIGURE api → database (public-tls-allowlist)  CONFIGURE worker → database (public-tls-allowlist)  CONFIGURE api → storage (public-tls) Risk: low

  3. 03

    Deploy

    O OpenTofu executa o grafo de dependências de forma assíncrona, com um state separado para cada recurso. Ramos independentes rodam em paralelo e falhas transitórias são repetidas. Quando um recurso falha, só os recursos que dependem dele ficam de fora. Antes de alterar recursos que já existem, o worker roda um tofu plan de verdade, e um delete ou replace em produção espera aprovação.

    deployment 9b07c4e1 · eventsAWAITING_APPROVAL
    14:21:03 INFO  [phase:targets] aws-prod / us-east-1: 4 checks passed.14:21:05 INFO  [phase:plan] api: 0 to add, 1 to change, 0 to destroy14:21:05 WARN  [phase:plan] ingress: 1 to add, 0 to change, 1 to destroy — replace aws_lb_target_group.route[0]14:21:05 WARN  [phase:plan] The provider plan deletes or replaces existing resources: production approval required.14:21:06 WARN  [phase:approval] High-risk production change: waiting for approval.

  4. 04

    Observação

    Os health checks são consolidados na instância e em uma página de status. Quando um componente crítico falha, o OrkStage abre um incidente, avisa os responsáveis no console e por email e resolve o incidente quando o componente volta a ficar saudável.

    Status · Acme Corp (private)updated 14:52

    Degraded performance

    • APIOPERATIONAL
    • WorkersOPERATIONAL
    • DatabaseDEGRADED
    • StorageOPERATIONAL

    Incident opened · database unhealthy

    Critical resource unhealthy. Owners notified in the console and by email. Resolves automatically when health returns.

Placement multicloud

Coloque cada recurso onde ele faz mais sentido.

O placement é definido por recurso, e não por ambiente. Associe o slot data a uma subscription do Azure e o mesmo template vira multicloud. Associe todos os slots a uma conta AWS e ele volta a rodar em uma nuvem só. O template não muda.

Acme Production · multicloud-reference@1.0.03 placement slots · 8 resources
Topologia de uma instância distribuída entre AWS, Azure e OCIO slot primary, na AWS, contém dns, ingress, api, worker, registry e network. O slot data, no Azure, contém o banco PostgreSQL. O slot storage, na OCI, contém o object storage. A api e o worker acessam o banco por TLS com allowlist de origem; a api acessa o storage por TLS.AWSslot primary · us-east-1AZUREslot data · eastusOCIslot storageTLS + allowlistTLSdnsRoute 53 + ACMingressALBapiECS Fargate ×2workerECS on EC2registryECRnetworkVPC, 2 AZsdatabasePostgreSQL Flexible ServerstorageObject Storage

Como dois recursos se conectam

O compilador escolhe a estratégia e mostra no plano. Nada é provisionado sem você ver.

private-network
Mesma conta e mesma região.
private-peering
Mesmo provedor, conta ou região diferente. Há custo de peering.
public-tls-allowlist
Entre nuvens, no modo private-preferred: TLS em um endpoint público, com a origem liberada em allowlist.
unsatisfiable
Entre nuvens, no modo private-required. O plano falha até você mudar o modo ou o placement.

Status O provisionamento na AWS é real (OpenTofu, validado com MiniStack). Os adapters de Azure, Google Cloud, OCI e outros provedores estão em preview, atrás de feature flags, até serem validados em contas reais. Um simulador determinístico permite testar qualquer topologia sem conta, sempre sinalizado como simulado.

Governança

Planos que você confere antes de qualquer recurso existir.

Políticas, custo e aprovações fazem parte do plano, e não de uma reunião depois do fato. Templates customizados passam pelas mesmas verificações e não podem pular nenhuma.

Políticas, com todos os resultados à vista

  • passno-public-database No database is publicly accessible.
  • passno-public-storage Object storage blocks public access.
  • passproduction-backups Production databases have backups.
  • passencryption-required All resources support encryption.
  • passallowed-regions All regions are approved.
  • passmulti-cloud-entitlement Placement fits the plan.
  • warncross-cloud-connectivity api → database crosses clouds via public-tls-allowlist.

Também entram na verificação: templates marcados como fora de produção, limite de réplicas e orçamento mensal.

Estimativa de custo aproximado

Preços de lista de um catálogo estático, sob demanda, por mês. É uma estimativa, nunca uma fatura.

Custo mensal aproximado por recurso na instância multicloud de referência
recursoonde rodaUSD/mês
databaseAzure Flexible Server, HA55.39
apiAWS ECS Fargate ×236.03
ingressAWS ALB22.27
workerAWS ECS on EC213.75
registry, dnsAWS ECR, Route 531.50
storageOCI Object Storage0.26
total aproximado≈ 129.20

Aprovação onde ela importa

Mudanças em produção que apagam, substituem ou mexem em um banco de dados param em AWAITING_APPROVAL. O worker também lê o plano real do provedor, então uma substituição que o diff da plataforma não enxerga também pede aprovação. O resto segue, e o registro explica por que a aprovação não foi necessária.

Um audit log que ninguém edita

Cada mudança vira um evento de auditoria com autor, correlation id e diff. Ações feitas com uma API key identificam a chave. Um trigger no Postgres rejeita updates e deletes na tabela, então o histórico fica exatamente como aconteceu.

Operação

Feito para quem fica de plantão.

Do health check que falha até o email na caixa de entrada do responsável, cada elo da cadeia é automático e visível.

  1. 01

    Saúde

    A cada ciclo, o estado real é lido de novo no provedor e a saúde dos componentes se consolida na instância. Um componente crítico derruba a instância; os outros só a degradam.

    HEALTHY · DEGRADED · UNHEALTHY

  2. 02

    Incidentes

    As regras de alerta são configuráveis, por health check ou por métrica. Elas abrem um incidente por recurso, com deduplicação e cooldown, e o resolvem quando o problema passa.

    INVESTIGATING · RESOLVED

  3. 03

    Página de status

    Cada tenant tem uma página de status (privada, para membros ou pública) que traduz os recursos nos componentes que seus clientes enxergam: API, workers, banco de dados.

    OPERATIONAL · PARTIAL_OUTAGE

  4. 04

    Notificações

    Owners e admins do tenant e a equipe da plataforma recebem avisos no console e por email. Webhooks assinados levam os mesmos eventos para os seus sistemas.

    console · email · webhooks

Se alguém apagar um recurso direto no console do provedor, um probe ao vivo percebe que ele sumiu, a verificação falha na hora em vez de esperar, e o próximo deploy cria o recurso de novo.

Do seu repositório

Comece pela infraestrutura que você já tem.

O scan engine lê Terraform e OpenTofu, CloudFormation e SAM, Kubernetes e Helm, Docker Compose, Dockerfiles e manifestos de pacotes. Ele propõe um template OrkStage e mostra a evidência de cada recurso. Importe o relatório pela API ou pelo console e revise o rascunho antes de publicar.

~/shop · ork importCLI preview
$ ork import --tenant acmeScanned 38 files: 7 resources, 1 unmapped.Import: 5d2f7c0e-8a41-4c6b-9e2d-1f0b7a3c6d58Template: validConsole: https://orkstage.example.com/templates/import?importId=5d2f7c0e-8a41-4c6b-9e2d-1f0b7a3c6d58

Seu código não sai da sua máquina: o CLI faz o scan localmente e envia só o relatório.

  • Importação de IaC disponível

    POST /imports recebe um ScanReport ou arquivos que o servidor analisa com o mesmo engine, compilado para WebAssembly. Recursos sem mapeamento e avisos aparecem na lista, nunca escondidos.

  • API keys, webhooks, intake de CI disponível

    Chaves com escopo que nunca passam do papel de quem as criou, webhooks assinados com HMAC e protegidos contra replay, e versões imutáveis de imagem publicadas pelo CI por digest.

  • O CLI ork Preview

    init, scan, template validate, push e diff, import, deploy --wait, status, logs e destroy. Saída em JSON e exit codes estáveis para CI. Compile a partir do código até os binários assinados saírem.

Open core

Open source no núcleo. Enterprise onde a organização precisa.

O Community é o control plane completo sob AGPL-3.0 e basta para rodar produção na AWS. O Enterprise adiciona recursos para organizações grandes e para compliance sob licença comercial, ativados por uma chave de licença que funciona offline. Mesmo código, mesmas imagens.

Comparação entre as edições Community e Enterprise
ÁreaCommunity AGPL-3.0, gratuitoEnterprise comercial, chave de licença
Control planeTemplates, builder visual, placement, planos e políticas, estimativa de custo, deploys, saúde, incidentes, status pages, notificações
  • Pacotes de políticas e criação de políticas próprias planejado
ProvisionamentoAWS via OpenTofu, demais provedores em preview, simulador, grafo de dependências, retentativas, detecção de drift
  • Provisionamento de conectividade privada (VPN, interconnect) planejado
IdentidadeDev login, OIDC (Microsoft Entra; Google e GitLab por configuração)
  • SSO com SAML 2.0 e provisionamento SCIM planejado
GovernançaSete papéis nativos, aprovação para mudanças de alto risco em produção, audit log que só aceita inserções
  • Exportação do audit log (NDJSON, CSV) disponível
  • Papéis customizados, aprovações em várias etapas, políticas de retenção planejado
OrganizaçõesUma organização, vários tenants
  • Várias organizações, status pages com a sua marca planejado
IntegraçõesAPI keys, webhooks, intake de CI, importação de IaC, CLI ork (preview)
  • Gestão de mudanças com ServiceNow ou Jira, alertas no PagerDuty ou Opsgenie planejado
SuporteGitHub Discussions e Slack
  • Suporte prioritário com SLA planejado

Ver a comparação completa entre as ediçõesFale com a gente sobre o Enterprise

Na sua infraestrutura

A plataforma inteira com um comando do Compose.

Você só precisa de Docker. O arquivo do Compose sobe a API, o worker, o console, Postgres, Redis, Mailpit, a imagem do runner OpenTofu e o MiniStack para simular a AWS localmente.

shellavaliação local
$ git clone https://github.com/orkstage/orkstage && cd orkstage$ docker compose -f infra/local/docker-compose.yml \    --profile platform --profile aws-emulator up -d --build --wait

Esta stack roda em modo de desenvolvimento, com o dev login e o socket do Docker montado. Ela serve para avaliar o OrkStage na sua máquina, não para produção.

console
localhost:3000
api + OpenAPI
localhost:4000/api/docs
MiniStack (AWS)
localhost:4566
Mailpit
localhost:8025
Ler o quickstart