Pequenas atualizações.
Grandes reviravoltas.

• ✳Corrige a publicação quando o controlador do Orbit e o Space ficam em servidores diferentes.
• ✳A verificação passa pelo roteador compartilhado do cluster, então um controlador que não recebe tráfego HTTP público também consegue confirmar o deploy. O domínio público e o checksum da versão continuam sendo conferidos.
• ✳O acesso ao Space escolhido acompanha os controladores atuais sem abrir as redes de outras aplicações. Sites, arquivos e configurações existentes são preservados.

Notas completas da versão no GitHub ↗

• ✳Configurações de projetos e aplicações ganham navegação por seções e controles adequados ao modo de publicação.
• ✳Sites já publicados como arquivos deixam de mostrar a aba Kubernetes e controles exclusivos de containers. Projetos estáticos que ainda usam containers mantêm esses controles.
• ✳A atualização preserva as configurações e o modo de publicação atual. Ela não move o site para um Space nem inicia um deploy.

Notas completas da versão no GitHub ↗

• ✳Publique sites estáticos em um Space, usando servidores de arquivos compartilhados em vez de uma imagem e um pod por site.
• ✳Arquivos de cada versão ficam separados por site, ambiente e deploy em um prefixo reservado. Uploads existentes ficam intactos, e o tráfego só muda após a verificação dos novos arquivos.
• ✳Guarde dez versões publicadas com rollback. Renderização no servidor e funções de servidor ainda precisam de container; caches locais não substituem os backups do Space.

Notas completas da versão no GitHub ↗

• ✳Corrige builds Git e a distribuição das aplicações quando uma cópia de espera do Orbit assume como servidor ativo.

Notas completas da versão no GitHub ↗

• ✳Conecte servidores de provedores diferentes e atrás de NAT por uma rede WireGuard gerenciada, inclusive em instalações existentes.

Notas completas da versão no GitHub ↗

• ✳Spaces, backups, atividade e operações ganham o visual ilustrado do Orbit; o uso de armazenamento dos bancos fica mais claro.

Notas completas da versão no GitHub ↗

• ✳Bancos de dados ganham cards ilustrados, navegação mais clara e espaços próprios para os cuidados do dia a dia.

Notas completas da versão no GitHub ↗

• ✳Configurações ganham categorias, busca, prévias de tema e o Ted acompanhando os ajustes.

Notas completas da versão no GitHub ↗

• ✳A configuração de três servidores reconhece quais conseguem se comunicar; a frota ganha o visual ilustrado do Orbit.

Notas completas da versão no GitHub ↗

• ✳Criar um projeto ganha mais vida, e o catálogo de aplicações passa a ter um lugar próprio na navegação.

Notas completas da versão no GitHub ↗

• ✳Se um servidor não conseguir entrar no control plane, ele volta a funcionar como agente em vez de ficar quebrado.

Notas completas da versão no GitHub ↗

• ✳Terminal no navegador, catálogo de aplicações prontas e importação de Coolify, Dokploy, Heroku e Render. A validação de alta disponibilidade em servidores reais pode ser executada com um comando.

Notas completas da versão no GitHub ↗

• ✳Configure o DNS de um domínio existente diretamente no Orbit, começando pelo Cloudflare.

Notas completas da versão no GitHub ↗

• ✳A visão geral do projeto vira uma central de missão, com o Ted reagindo ao estado da aplicação e uma escolha de branch mais clara por ambiente.

Notas completas da versão no GitHub ↗

• ✳A migração da DigitalOcean ganha um fluxo guiado, da descoberta dos recursos à troca de DNS verificada.

Notas completas da versão no GitHub ↗

• ✳A retenção pode manter um número de cópias válidas; o backup espera o banco terminar de reiniciar antes de começar.

Notas completas da versão no GitHub ↗

• ✳Entre ou aceite convites com GitHub e Google, usando o email verificado pelo provedor para encontrar sua conta.

Notas completas da versão no GitHub ↗

• ✳O armazenamento S3 vira Spaces, com lista própria, botão de criação e uma página dedicada aos arquivos.

Notas completas da versão no GitHub ↗

• ✳Escolha um domínio para o console durante a instalação ou nas configurações, com verificações para preservar seu acesso.

Notas completas da versão no GitHub ↗

• ✳A página do banco detalha o que ocupa o armazenamento e por que ele cresce; o uso passa a mostrar uma casa decimal.

Notas completas da versão no GitHub ↗

• ✳Ajuste memória e armazenamento planejado pelo console. Falta de memória abre um incidente, e os backups passam a usar memória separada da do banco.

Notas completas da versão no GitHub ↗

• ✳Proteja a entrada com códigos de um aplicativo autenticador; o administrador pode exigir essa proteção de todos.

Notas completas da versão no GitHub ↗

• ✳Receba alertas de disco, memória e CPU, armazenamento do banco, certificados próximos de vencer e backups agendados que não rodaram.

Notas completas da versão no GitHub ↗

• ✳Aplicações ganham um bucket S3 para arquivos, com referências e backups como os outros serviços de dados.

Notas completas da versão no GitHub ↗

• ✳O Orbit verifica se cada aplicação web responde, abre incidentes quando ela para e pode publicar uma página pública de status.

Notas completas da versão no GitHub ↗

• ✳Testes de restauração ganham agendamento próprio, execução manual e limite de tempo.

Notas completas da versão no GitHub ↗

• ✳O console e os ambientes de preview também podem ser publicados pelo Cloudflare Tunnel.

Notas completas da versão no GitHub ↗

• ✳Servidores que não recebem tráfego nas portas 80 e 443 podem servir aplicações pelo Cloudflare Tunnel.

Notas completas da versão no GitHub ↗

• ✳Scripts e pipelines usam a API com tokens do workspace; o comando orbit deploy publica aplicações a partir do pipeline.

Notas completas da versão no GitHub ↗

• ✳Novos servidores recebem um token que só permite adicionar agentes; os tokens de entrada do cluster podem ser renovados pelo console.

Notas completas da versão no GitHub ↗

• ✳A página do PostgreSQL informa quando o cluster está mudando ou não consegue se recuperar.

Notas completas da versão no GitHub ↗

• ✳Cada servidor mantém atualizados no firewall os endereços dos demais servidores.

Notas completas da versão no GitHub ↗

• ✳Backups maiores voltam a passar no teste de restauração, e a restauração transfere o arquivo completo.

Notas completas da versão no GitHub ↗

• ✳Aplicações em servidores de outra rede passam a alcançar o cluster; toda nova entrada verifica esse acesso.

Notas completas da versão no GitHub ↗

• ✳Servidores em redes separadas com a mesma faixa privada passam a entrar corretamente pelos endereços públicos.

Notas completas da versão no GitHub ↗

• ✳Servidores de redes separadas, como duas redes privadas da Oracle Cloud, podem compartilhar o cluster pelos endereços públicos.

Notas completas da versão no GitHub ↗

• ✳O Orbit explica quando o servidor está em outra rede com a mesma faixa privada e permite descartar uma instalação que falhou.

Notas completas da versão no GitHub ↗

• ✳É possível descartar um servidor em qualquer etapa anterior à instalação; redes privadas inacessíveis passam a ser explicadas.

Notas completas da versão no GitHub ↗

• ✳Informe os preços dos servidores e acompanhe quanto cada projeto custa por mês.

Notas completas da versão no GitHub ↗

• ✳Tentar de novo uma instalação parada em Instalar o agente volta a funcionar após o Orbit reiniciar.

Notas completas da versão no GitHub ↗

• ✳Uma falha de conexão na Oracle Cloud indica a regra exata e onde adicioná-la; o Orbit também ajusta o firewall das imagens do provedor.

Notas completas da versão no GitHub ↗

• ✳Operações que deixaram de executar podem ser canceladas novamente e não bloqueiam mais as atualizações.

Notas completas da versão no GitHub ↗

• ✳Adicionar um servidor em uma rede privada, como a da Oracle Cloud, deixa de travar em Iniciando serviços.

Notas completas da versão no GitHub ↗

• ✳Previews de pull requests podem usar seu domínio com um único certificado curinga.

Notas completas da versão no GitHub ↗

• ✳Clientes podem salvar o túnel para o banco; o Lily DB abre a conexão com um clique.

Notas completas da versão no GitHub ↗

• ✳O Orbit passa a criar no Cloudflare os registros DNS dos seus domínios personalizados.

Notas completas da versão no GitHub ↗

• ✳Adicionar um servidor deixa de falhar na etapa de instalação do runtime.

Notas completas da versão no GitHub ↗

• ✳O Orbit passa a enviar notificações para uma lista de emails e convites para os workspaces.

Notas completas da versão no GitHub ↗

• ✳Um projeto pode ter mais de uma aplicação usando o mesmo banco de dados.

Notas completas da versão no GitHub ↗

• ✳Perder o servidor principal deixa de derrubar o DNS do cluster quando outro servidor já havia reiniciado.

Notas completas da versão no GitHub ↗

• ✳Workspaces ganham membros com funções de proprietário, administrador, desenvolvedor e visualizador.

Notas completas da versão no GitHub ↗

• ✳Envie notificações do Orbit para canais do Discord.

Notas completas da versão no GitHub ↗

• ✳O Orbit avisa um canal do Slack quando algo precisa da sua atenção.

Notas completas da versão no GitHub ↗

• ✳O Orbit passa a construir e publicar aplicações a partir do Bitbucket Cloud.

Notas completas da versão no GitHub ↗

• ✳Conecte o GitLab.com ou seu próprio GitLab para construir e publicar aplicações.

Notas completas da versão no GitHub ↗

• ✳O Orbit passa a rodar MongoDB junto de PostgreSQL, MySQL e Redis.

Notas completas da versão no GitHub ↗

• ✳Um teste de aceitação cobre a perda de qualquer servidor; esta versão corrige os problemas encontrados nesses cenários.

Notas completas da versão no GitHub ↗

• ✳O Orbit pode manter cópias de si no control plane e voltar em outro servidor quando o principal é perdido.

Notas completas da versão no GitHub ↗

• ✳O Orbit passa a funcionar em provedores que atribuem só um endereço interno à placa de rede, como Oracle Cloud, AWS, Google Cloud e Azure.

Notas completas da versão no GitHub ↗

• ✳O control plane do Kubernetes pode rodar em três servidores, mantendo o cluster funcionando quando o principal é perdido.

Notas completas da versão no GitHub ↗

• ✳Receber tráfego, no card de um servidor, também passa a rodar o roteador nele. O Orbit espera por ele, confere se o servidor responde na porta 80 e desfaz a mudança se não responder, indicando a regra de firewall que falta adicionar.
• ✳Com mais de um servidor recebendo tráfego, cada domínio personalizado lista um registro A por servidor, subdomínios incluídos. Um domínio que já estava verificado volta a mostrar os registros e continua sendo verificado até que todos resolvam.
• ✳A página Servidores marca os servidores que recebem tráfego, e a atividade informa por quais endereços o tráfego entra.
• ✳Limite — Os endereços sslip.io gerados ainda apontam só para o servidor principal.
• ✳Limite — Quando um servidor que recebe tráfego é perdido, os visitantes cujo DNS escolheu esse servidor ficam sem resposta até que o resolver deles pare de retorná-lo. Nos testes, as requisições pelo servidor principal continuaram funcionando, exceto as enviadas à instância do servidor perdido: 8 de 71 falharam nos primeiros 52 segundos.
• ✳Limite — Se o servidor principal for perdido, os outros continuam respondendo, mas as requisições enviadas às instâncias que rodavam nele falham, porque o control plane que as tiraria das listas dos roteadores roda lá.

Notas completas da versão no GitHub ↗

• ✳A prévia de Servidores simula a perda de cada servidor escolhido. Se os outros não tiverem espaço para as instâncias que iriam para eles, somadas a tudo o que já está lá, ela recusa e aponta o servidor e a memória que falta. Quando cabe, informa quanto espaço sobraria.
• ✳Todo servidor mantém esse espaço. Uma mudança posterior nele, como outra aplicação, um banco de dados ou um redimensionamento, é recusada se for ocupar esse espaço.
• ✳Redimensionar uma aplicação distribuída passa pela mesma verificação.
• ✳A página Servidores mostra quanta memória cada servidor reserva para as instâncias que iriam para ele, e qual perda exige essa reserva.

Notas completas da versão no GitHub ↗

• ✳Servidores, nas configurações de uma aplicação, a move para outro servidor ou distribui suas instâncias entre vários. Uma prévia mostra quantas instâncias cada servidor teria e o que fica livre, e recusa um servidor que não está pronto, não tem espaço ou tem uma arquitetura de CPU diferente da de uma imagem já construída.
• ✳Quando um servidor é perdido, as instâncias que ele rodava sobem de novo nos outros servidores. Nos testes, isso levou cerca de um minuto e meio, e as outras instâncias continuaram atendendo nesse meio-tempo.
• ✳As imagens construídas são copiadas para cada servidor escolhido antes que uma instância suba nele.
• ✳Limite — Com uma instância só, a aplicação ainda fica parada até essa instância subir em outro servidor. Use duas ou mais.
• ✳Limite — O tráfego ainda entra pelo servidor principal, e mover instâncias depende do control plane que roda lá. Perder o servidor principal interrompe as duas coisas. É por isso que o Orbit ainda não chama isso de alta disponibilidade.

Notas completas da versão no GitHub ↗

• ✳A documentação do Orbit está pública em orbit.getcortexlabs.com, em inglês e português.
• ✳A documentação cobre instalação, projetos, aplicações, GitHub e previews, importação de Compose, bancos de dados, réplicas e failover, backups e recuperação, mais servidores, operação e atualização do Orbit, segurança e o que o Orbit não promete.
• ✳Os avisos do console que indicam um limite agora levam à página que o explica, no seu idioma. Isso abrange o control plane único, a perda de dados com replicação assíncrona, a replicação síncrona com duas instâncias e várias instâncias num mesmo servidor.
• ✳O guia de recuperação exibido quando uma atualização é interrompida e a linha Documentation= das units do systemd apontam para o novo site, e não mais para um repositório privado.

Notas completas da versão no GitHub ↗

• ✳Reconstruir a partir do arquivo. Quando todas as instâncias de um banco PostgreSQL somem, a página dele oferece reconstruí-lo a partir do último base backup e do WAL arquivado. O Orbit recria as instâncias nos mesmos servidores e informa até qual commit os dados voltaram.
• ✳Failovers medidos. Cada failover e switchover registra quanto tempo o banco ficou sem primário. Também registra o que foi preservado: todas as escritas commitadas, com replicação síncrona, ou o horário da escrita mais recente que o novo primário tem, com replicação assíncrona. A atividade, a linha do tempo e a página do banco mostram as duas informações.
• ✳O painel do banco agora se chama Instâncias e replicação. O Orbit não chama isso de alta disponibilidade enquanto o control plane dele roda em um único servidor.
• ✳Com replicação assíncrona, um primário isolado da rede agora para de aceitar escritas cerca de meio minuto após o corte, bem antes de uma réplica assumir. Antes, as sessões que ele já tinha podiam continuar escrevendo por até três minutos, então dois primários podiam aceitar escritas ao mesmo tempo.
• ✳A replicação síncrona só promove uma réplica que tenha todas as escritas commitadas.
• ✳A prévia recusa replicação síncrona com duas instâncias, já que perder qualquer um dos servidores interromperia todas as escritas.
• ✳Um arquivo WAL que não está cheio é arquivado após um minuto em vez de cinco, então perder todas as instâncias perde no máximo cerca de um minuto de escritas.
• ✳Um servidor parado significou cerca de 64 segundos sem primário, e nenhuma escrita confirmada foi perdida.
• ✳Um servidor isolado da rede significou 96 segundos sem primário, e nunca houve dois primários aceitando escritas.
• ✳Restaurar para o segundo anterior a uma mudança destrutiva levou cerca de um minuto.
• ✳Reconstruir a partir do arquivo trouxe as escritas de volta 51 segundos depois de todas as instâncias serem perdidas.

Notas completas da versão no GitHub ↗

• ✳Um banco de dados PostgreSQL no CloudNativePG roda de uma a três instâncias, cada uma em um servidor diferente. A prévia escolhe os servidores e recusa quando não há servidores suficientes com espaço para o banco.
• ✳A replicação é assíncrona por padrão. A replicação síncrona faz cada commit esperar por uma réplica.
• ✳Quando o servidor do primário é perdido, uma réplica é promovida e o endereço do banco a acompanha, então as aplicações mantêm suas variáveis.
• ✳Tornar primária promove uma réplica de propósito. Nos testes, isso levou cerca de 10 segundos.
• ✳A página do banco lista cada instância com seu servidor, seu papel e o quanto está atrasada. Failovers e switchovers aparecem na atividade e na linha do tempo.

Notas completas da versão no GitHub ↗

• ✳Um banco de dados no CloudNativePG cujos backups vão para um armazenamento externo também arquiva o WAL dele lá, continuamente.
• ✳A página do banco mostra a janela para a qual você pode restaurar, do base backup mais antigo mantido até o último WAL arquivado. Ela avisa quando o arquivamento fica para trás ou falha, e o banco aparece como degradado.
• ✳Restaurar para um ponto no tempo aceita qualquer segundo dessa janela. O Orbit primeiro guarda uma cópia dos dados atuais, recupera o arquivo num cluster temporário naquele momento, copia os dados de volta numa única transação e reinicia as aplicações que usam o banco.

Notas completas da versão no GitHub ↗

• ✳O Orbit instala o operador CloudNativePG e o plugin Barman Cloud dele quando o primeiro banco PostgreSQL é criado.
• ✳Os bancos PostgreSQL existentes mostram Migrar para o CloudNativePG. Uma prévia informa por quanto tempo as escritas ficam pausadas, para onde vai o backup e se o servidor tem disco para uma segunda cópia. O Orbit faz o backup, copia os dados enquanto as leituras continuam funcionando, troca o endereço do banco e reinicia as aplicações que o usam.
• ✳Se uma etapa da migração falhar, o banco antigo é restabelecido e volta a aceitar escritas. O volume dele fica no servidor, somente leitura, até você removê-lo.

Notas completas da versão no GitHub ↗

• ✳Escalar automaticamente, nas configurações de uma aplicação, adiciona instâncias enquanto a CPU fica acima de uma meta e as remove após 5 minutos abaixo dela.
• ✳A prévia de recursos reserva espaço para o número máximo de instâncias, então escalar nunca esbarra na falta de espaço no servidor.
• ✳Deploys e mudanças de recursos mantêm o número de instâncias escolhido pelo autoscaler.
• ✳Um gráfico de Instâncias mostra o escalonamento, e a linha do tempo lista cada mudança com a CPU que a causou.

Notas completas da versão no GitHub ↗

• ✳Configurações > Atualizações do Orbit mostra a versão em execução e qualquer release mais nova, com suas notas.
• ✳Antes de uma atualização começar, uma verificação prévia confere a assinatura da release, o disco livre, as operações em andamento e o agente do servidor.
• ✳Uma atualização faz backup dos dados do Orbit, baixa e verifica a release, reinicia na nova versão e aplica as migrações dela.
• ✳Se a nova versão nunca subir, uma proteção restaura a anterior após três minutos. Se o console estiver inacessível, orbit update rollback faz o mesmo a partir do servidor.
• ✳As releases agora são assinadas com Ed25519. O Orbit se recusa a atualizar a partir de uma release cuja assinatura não corresponda à chave que vem com ele.

Notas completas da versão no GitHub ↗

• ✳Quando uma aplicação é encerrada por falta de memória duas vezes em 30 minutos, o Orbit abre um incidente.
• ✳O incidente mostra os reinícios, a memória em relação ao limite, o tráfego de entrada e o último deploy, cada um com sua origem, e separa as possíveis causas dos fatos.
• ✳Aumentar o limite a partir do incidente passa pela prévia de recursos. O incidente se resolve após 10 minutos sem reinício.

Notas completas da versão no GitHub ↗

• ✳Memória, CPU e número de instâncias de uma aplicação podem ser alterados nas configurações dela, num servidor real.
• ✳Uma prévia mostra o que a mudança reserva no servidor e como ela é aplicada. Ela avisa quando os builds perdem a folga ou quando o novo limite fica abaixo do uso recente, e bloqueia uma mudança que não cabe.
• ✳Se as novas instâncias não ficarem prontas, os valores anteriores são restaurados.

Notas completas da versão no GitHub ↗

• ✳Métricas. A cada 30 segundos, o Orbit coleta CPU, memória, rede e reinícios de cada aplicação, armazenamento e conexões de cada banco de dados, e o uso de cada servidor. Guarda oito dias. Os gráficos mostram lacunas onde a coleta parou, e uma linha do tempo lista deploys, rollbacks, reinícios e mudanças.
• ✳Explorar dados. As tabelas de um banco, as linhas delas e as chaves do Redis podem ser exploradas pelo console. A aba Consulta executa uma única instrução SQL somente leitura, limitada a 15 segundos e 500 linhas, e cada consulta fica registrada na atividade.

Notas completas da versão no GitHub ↗

• ✳Importar dados traz um banco de dados de outro servidor, usando a URL de conexão dele, ou de um arquivo de dump de até 64 GiB. A importação vira um backup marcado como importado e passa pelo mesmo teste de restauração isolado antes de você restaurá-lo. A URL nunca é gravada em logs.
• ✳Corrigido — Uma aplicação que para logo depois de iniciar agora falha com seu código de saída e suas últimas linhas, em vez de parecer um health check que nunca respondeu.

Notas completas da versão no GitHub ↗

• ✳Mostrar credenciais, na página de um banco de dados, fornece o usuário, a senha e o comando para um túnel SSH pelo servidor principal. Assim você conecta o psql, o DBeaver ou o TablePlus do seu computador sem tornar o banco público. Cada exibição fica registrada na atividade.

Notas completas da versão no GitHub ↗

• ✳Os backups podem rodar a cada hora ou a cada tantas horas num minuto escolhido, todo dia num horário escolhido, em dias da semana escolhidos ou num cron personalizado. Eles seguem qualquer fuso horário, incluindo as mudanças de horário de verão.
• ✳A política mostra os próximos três backups antes de você salvá-la. Um banco de dados novo pede o horário e o fuso do backup diário.
• ✳Corrigido — Criar um banco de dados pela janela de novo banco ou por uma importação de Compose não falha mais num servidor real por falta de agendamento de backup.
• ✳Corrigido — O console não mostra mais textos de exemplo da demo numa instalação real.

Notas completas da versão no GitHub ↗

• ✳Projetos podem ser renomeados e mudar de cor. Ambientes de staging e desenvolvimento podem ser removidos, assim como projetos inteiros, aplicações e bancos de dados. Cada remoção pede que você digite o nome. Os arquivos de backup são mantidos.
• ✳Corrigido — Registrar um agente de novo revoga os certificados que o servidor dele tinha antes.
• ✳Corrigido — O Orbit recusa comandos de um agente registrado para um servidor que ele não conhece, e o log nomeia esse servidor.

Notas completas da versão no GitHub ↗

• ✳Corrigido — Atualizar com o comando de instalação agora reinicia o agente quando o binário dele mudou. Antes, ele continuava rodando a versão antiga até o servidor reiniciar.

Notas completas da versão no GitHub ↗

• ✳Previews de pull request. Cada pull request de uma branch do repositório ganha a própria cópia dos serviços construídos a partir dele, com bancos de dados vazios, num endereço próprio. A preview é removida quando o pull request é fechado. Pull requests de forks nunca ganham preview.
• ✳Importação de Docker Compose. Um arquivo Compose de um repositório, ou colado diretamente, vira um plano para revisar. Bancos de dados viram bancos gerenciados, serviços viram aplicações ou workers, e variáveis viram variáveis, segredos ou referências.
• ✳Bancos de dados MySQL 8.4, com backups verificados e restaurações que nunca deixam um banco carregado pela metade.
• ✳Visão Kubernetes. Com o modo avançado ativado nas configurações da sua conta, aplicações e bancos de dados mostram seus recursos, manifestos e eventos do Kubernetes, somente leitura e sem segredos.

Notas completas da versão no GitHub ↗

• ✳Mais servidores. Adicionar servidor conecta via SSH, verifica a máquina e a junta ao cluster, com o tráfego entre servidores criptografado pelo WireGuard. Novos serviços podem ser alocados nele. Mais servidores somam espaço, não alta disponibilidade.
• ✳Corrigido — Um console real não mostra mais o usuário de exemplo da demo nem o aviso de “dados simulados”.

Notas completas da versão no GitHub ↗

• ✳Workers e jobs. Uma aplicação pode ter workers, que rodam sem endereço, e jobs agendados, que rodam num agendamento cron em UTC ou sob demanda com Executar agora. O Orbit guarda as últimas cinco execuções bem-sucedidas e as cinco com falha de cada job, com a saída delas.

Notas completas da versão no GitHub ↗

• ✳Deploy no push. Um push na branch de uma aplicação faz deploy daquele commit quando “Deploy automático” está ativado. As entregas do GitHub são assinadas, e a mesma entrega nunca faz deploy duas vezes.

Notas completas da versão no GitHub ↗

• ✳Workspaces. Projetos, a conexão com o GitHub, credenciais de registry, armazenamentos de backup e atividade pertencem a um workspace, e o console permite alternar, criar e renomear workspaces. Os servidores são compartilhados. Tudo o que existia antes está num workspace chamado “Default”.

Notas completas da versão no GitHub ↗

• ✳O GitHub App agora pode ser instalado na sua conta ou em qualquer uma das suas organizações.
• ✳O App leva o nome do servidor (“Orbit” mais o nome do servidor), e Configurações > Integrações oferece o logo do Orbit para você enviar ao GitHub.

Notas completas da versão no GitHub ↗

• ✳O Orbit pode ser instalado no Ubuntu 26.04 LTS.

Notas completas da versão no GitHub ↗

• ✳Instalação. O comando de instalação verifica a máquina e instala K3s, Traefik, cert-manager, BuildKit e o agente do Orbit. Se ele parar no meio, rodá-lo de novo retoma de onde parou.
• ✳Console. O console é publicado num endereço HTTPS próprio no servidor, com um certificado Let's Encrypt.
• ✳Aplicações. Faça deploy a partir de uma imagem de contêiner ou de um repositório do GitHub que o Orbit constrói no servidor. Cada uma ganha um endereço HTTPS, domínios personalizados, variáveis e segredos, health checks, rollbacks e logs sem os segredos.
• ✳Bancos de dados. Bancos PostgreSQL e Redis podem ser conectados a aplicações por meio de referências. As credenciais podem ser rotacionadas, o acesso pode ser tornado público e as versões podem ser atualizadas.
• ✳Backups. Os backups vão para um armazenamento compatível com S3 conforme um agendamento. Cada um é restaurado de forma isolada antes de contar como verificado, e uma restauração pode tirar antes uma cópia dos dados atuais.
• ✳Seus dados. orbit backup e orbit restore salvam e recuperam os próprios dados do Orbit a partir do servidor.

Notas completas da versão no GitHub ↗