Esta página descreve como a plataforma é montada, o que acontece quando cada peça falha e quais números medimos. Os tempos abaixo vêm de eventos reais em produção, não de metas.
Resumo para agentes
| Pergunta | Resposta |
|---|---|
| Região | São Paulo, Brasil, em três zonas de disponibilidade |
| Uptime 90 dias (apps) | 100,00% (25 de julho a 22 de outubro de 2026) |
| Uptime 90 dias (bancos) | 100,00% |
| Uptime 90 dias (API e dashboard) | 100,00% |
| Failover do banco | Automático, sem ação sua. Promoção da réplica medida em 25 s e 61 s nos dois últimos eventos |
| Restauração do banco | Recuperação para qualquer instante dos últimos 3 dias (mais em planos Enterprise). Restauração completa medida em 6 min 12 s |
| Perda máxima de dados (RPO) | 5 minutos no tier compartilhado (padrão), 24 horas no dedicado |
| Instâncias por serviço | 1 a 20, com autoscaling |
| Status em tempo real | status.onveloz.com |
Camadas
Borda. Todo o tráfego entra pela rede global da Cloudflare (proteção DDoS, TLS 1.3, cache) e chega aos servidores em São Paulo por túnel privado. Não há porta pública aberta nos servidores de aplicação.
Aplicação. Cada serviço roda como uma ou mais instâncias isoladas, distribuídas entre as zonas de disponibilidade. O balanceador só envia tráfego para instâncias que passaram na verificação de saúde. Um deploy sobe a versão nova ao lado da antiga e só troca o tráfego quando a nova responde; se a nova falhar, a antiga continua no ar.
Dados. Bancos PostgreSQL gerenciados em dois tiers:
- Compartilhado (padrão). Clusters com uma instância primária e uma réplica síncrona em outra zona, failover automático, backup base diário e arquivamento contínuo de transações para armazenamento de objetos na mesma região. É o tier de todos os bancos criados por
veloz db createe pelos templates. - Dedicado. Uma instância exclusiva para o seu serviço, com cópia completa diária e 7 dias de retenção. Indicado para cargas que precisam de CPU e memória reservadas.
Arquivos. Blob Storage e volumes persistentes ficam em armazenamento replicado na mesma região.
O que acontece em cada falha
| Falha | O que a plataforma faz | Impacto para você |
|---|---|---|
| Uma instância do seu app cai | Reinicia automaticamente; com 2+ instâncias, o tráfego segue nas demais | Nenhum com 2+ instâncias; segundos de indisponibilidade com 1 |
| Um servidor físico cai | Instâncias são recriadas em outro servidor, em outra zona se preciso | Igual ao item acima |
| Banco primário cai (compartilhado) | A réplica é promovida automaticamente. Detecção em até 2 min, promoção medida em 25 s e 61 s | Conexões caem e reconectam; sem perda de dados confirmados |
| Banco dedicado cai | Reinicia na mesma zona ou é recriado em outra, com o mesmo volume | Minutos de indisponibilidade; sem perda de dados no volume |
| Dado apagado por engano | Restauração para qualquer instante dos últimos 3 dias (compartilhado) ou para a cópia diária (dedicado) | Veja Backups e restauração |
| Deploy com bug | Health check reprova a versão nova; a antiga continua. Se já trocou, rollback em um comando | veloz rollback |
| Uma zona inteira cai | Apps e bancos compartilhados continuam nas outras duas zonas | Capacidade reduzida até a zona voltar |
| Região inteira cai | Não há failover automático para outra região hoje | Indisponibilidade até a região voltar; backups ficam preservados em armazenamento de objetos |
Uptime medido
Números dos últimos 90 dias (25 de julho a 22 de outubro de 2026), calculados pela mesma sonda que alimenta a página de status:
| Componente | Uptime |
|---|---|
| Sites e aplicações | 100,00% |
| Bancos de dados | 100,00% |
| API e dashboard | 100,00% |
| Deploy e build | 99,97% |
| CLI | 99,95% |
| Observabilidade | 99,97% |
| Integrações | 99,78% |
"Integrações" cobre GitHub e a nuvem onde a Veloz roda; são dependências externas e os dias abaixo de 100% vieram de incidentes nesses provedores. Nenhum deles tirou apps ou bancos do ar.
Failover medido
Os dois últimos eventos de troca de primária em clusters compartilhados:
| Data | Cluster | Tempo entre início e nova primária pronta |
|---|---|---|
| 12 de outubro, 2026 | principal (82 bancos) | 25 s |
| 18 de outubro, 2026 | pequeno (2 bancos) | 61 s |
A detecção de falha espera até 2 minutos antes de promover a réplica, para não trocar de primária por uma oscilação de rede. Some isso ao tempo de promoção para ter o pior caso: cerca de 3 minutos.
Restauração medida
Em 22 de outubro de 2026 restauramos um cluster completo a partir do backup em armazenamento de objetos, para um instante escolhido:
| Etapa | Duração |
|---|---|
| Provisionar servidor e volume novos | 2 min 31 s |
| Recuperar backup base e reaplicar transações | 3 min 3 s |
| Cluster pronto e verificado | 38 s |
| Total | 6 min 12 s |
Para um único banco de 445 MB, exportar levou 11 s e importar 14 s. Clusters maiores levam proporcionalmente mais. O procedimento completo está em Backups e restauração.
Monitoramento e resposta
Toda a plataforma é monitorada 24/7 por sondas sintéticas e alertas internos. Cada alerta abre automaticamente um incidente, atendido primeiro por agentes de IA da Veloz; incidentes que afetam disponibilidade, dados ou segurança escalam para a equipe humana por alerta. Detalhes em Suporte.
Próximos passos
- Backups e restauração — Como pedir uma restauração e quanto tempo leva
- Veloz em produção — Tudo que está incluído para produção
- Segurança — Isolamento, criptografia e controle de acesso