Planos e limites da Vertra Cloud

A Vertra Cloud é uma plataforma brasileira de hospedagem de aplicações (PaaS): deploy a partir do GitHub ou de um arquivo zip, containers isolados, bancos de dados gerenciados, armazenamento de arquivos, snapshots, uma CLI e uma extensão do VS Code. Esta página reúne, em um só lugar, todos os números públicos da plataforma — preço, memória, vCPU, projetos e limite de API por plano. Os valores abaixo são os mesmos usados pela plataforma em produção. Os preços estão em reais brasileiros. Você pode comprar 1, 3 ou 12 meses por vez: 3 meses têm 5% de desconto e 12 meses têm 15% de desconto (o Economy é somente mensal). Pague com PIX ou cartão de crédito (Visa e Mastercard; o Economy é somente PIX). Um plano pago no cartão renova automaticamente no seu cartão padrão, 3 dias antes de vencer; use Cancelar renovação em Faturamento para interromper. Pagamentos por PIX nunca renovam sozinhos. Os preços abaixo são o preço mensal.

​

Quanto custa cada plano da Vertra Cloud?

Os planos vão de R$ 1,99/mês (Economy) a R$ 191,99/mês (Enterprise-32, 32 GB de RAM). A memória é a única coisa que aplicações e bancos de dados consomem — não há cobrança por hora nem por requisição. Nenhum plano tem um limite de quantidade de projetos — o limite real é a RAM do plano: a criação é recusada com MEMORY_LIMIT_EXCEEDED quando a RAM do plano acaba, então um app de 100 MB cabe 10 vezes em um plano Pro. Todos os planos incluem o Vertra Shield, a proteção de tráfego da plataforma. Quando uma aplicação está pausada, o dashboard mostra o motivo e o tempo restante. Os limites de banda por memória, os certificados TLS automáticos e o SLA de 99,99% também valem para todos os planos. A coluna “Requisições de API/dia” acima só vale para chamadas autenticadas com uma chave de API (o uso pelo dashboard não conta) e é zerada à meia-noite no fuso horário de Brasília. O mesmo limite também tem uma janela por minuto. Uma conta sem plano ativo tem 30 requisições/min e 1.000 requisições/dia. Os detalhes das duas janelas, dos headers de resposta e dos códigos de erro estão em Limites da API.

​

Quanta vCPU uma aplicação realmente recebe?

A coluna de vCPU acima é o teto por aplicação no plano, não um total dividido entre os projetos da conta. Dentro desse teto, a vCPU de um projeto cresce com a RAM do projeto:

• Crescimento: em planos com até 2 vCPU, +1 vCPU a cada 512 MB de RAM; em planos com mais de 2 vCPU, +1 vCPU a cada 1 GB (1.024 MB).
• Piso: um projeto com 512 MB ou mais recebe pelo menos 2 vCPU; abaixo de 512 MB, pelo menos 1 vCPU.
• Teto: nunca mais do que a vCPU do plano. O Economy (0,3) e o Pro (0,5) sempre dão ao projeto a vCPU inteira do plano.

A mesma regra vale para os bancos de dados. Mais RAM nunca resulta em menos vCPU. Uma alteração entra em vigor na próxima vez que o projeto for reiniciado ou receber um deploy.

​

O que acontece com uma conta sem plano ativo?

Uma conta sem plano ativo não pode criar aplicações nem bancos de dados, nem publicar um site: essas requisições são recusadas com PLAN_REQUIRED (403). Assine um plano, a partir do Economy, para continuar. Projetos que ficam offline por mais de 30 dias em uma conta sem plano ativo são apagados automaticamente, com um snapshot feito antes e avisos por e-mail nos dias 7, 23 e 27.

​

Quais recursos cada plano libera?

Todo recurso tem um plano mínimo, e ele vale para o dono do recurso — convidar alguém com um plano superior para um workspace não libera o recurso. No Pro o subdomínio é atribuído aleatoriamente pela plataforma; escolher o nome exige o Scale ou superior. Publicar uma aplicação na web exige pelo menos 512 MB de RAM alocados a ela.

​

Quantos domínios personalizados e portas cada plano permite?

Os domínios personalizados começam no plano Intermediary. O limite é por aplicação e vale para o plano do dono da aplicação. O www (ou raiz) automático que acompanha um domínio não conta. Além dos domínios do plano, toda aplicação com domínios pode atendê-los em até 5 portas diferentes além da porta 80; cada domínio também aceita um prefixo de caminho opcional e um redirecionamento opcional para outro domínio da mesma aplicação. Ao atingir o limite de domínios, a resposta é DOMAIN_LIMIT_REACHED, e para o limite de portas, DOMAIN_PORT_LIMIT_REACHED. Um domínio que fica pending, moved ou deleted por 14 dias é removido automaticamente; depois de qualquer remoção, apague os registros CNAME e TXT dele no seu provedor de DNS. Veja Conecte domínios personalizados.

​

Como conecto ferramentas de IA à Vertra Cloud?

Conecte seu agente compatível pelo servidor MCP para operar os recursos da sua conta.

​

Quais linguagens e versões a Vertra Cloud suporta?

A plataforma constrói e executa aplicações em 13 runtimes. Cada um tem uma versão recommended, uma versão latest (muitas vezes a mesma) e versões mais antigas que você pode fixar pelo número — no assistente, em Config → Geral, em VERSION ou pela API. As versões mais antigas são removidas quando chegam ao fim do suporte; uma aplicação salva em uma versão removida roda na versão mais recente da mesma linha, ou na recommended se a linha inteira foi removida.

​

Quais bancos de dados são gerenciados?

Há quatro engines gerenciadas, todas com TLS obrigatório e certificados (CA, servidor e cliente) gerados automaticamente pela plataforma. Você escolhe a versão ao criar um banco de dados (o seletor no dashboard, ou version na API); a recomendada é a padrão. Os bancos existentes mantêm a versão major, e as atualizações de segurança (patch releases) são aplicadas automaticamente sempre que o banco é reiniciado (parar e depois iniciar, no dashboard). Se você usa índices btree_gist em colunas float ou índices ltree no PostgreSQL, execute REINDEX neles após a reinicialização. Os bancos MySQL 8.0 existentes continuam na 8.0, que não está disponível para novos bancos. Os bancos Redis 7.4 existentes continuam na 7.4. Um banco criado a partir de um snapshot nasce na versão major do snapshot (um snapshot de MySQL 8.0 cria um banco MySQL 8.4, e um snapshot de Redis 7.4 cria um Redis 8.2); version pode ser a mesma ou uma mais nova, nunca mais antiga (SNAPSHOT_VERSION_NEWER). Restaurar um snapshot feito em uma versão mais nova em um banco mais antigo é recusado com o mesmo código e nada é alterado. vertracloud é o usuário dos bancos criados a partir da v26.4.8, e não é superusuário. Os bancos mais antigos mantêm o usuário da engine: postgres (banco postgres), default no MongoDB (banco de autenticação admin) e no Redis, e root (banco default) no MySQL. O campo username do banco na API indica qual usar. A porta é única por banco de dados — não a padrão da engine — e aparece na página do banco. Veja como conectar.

​

Quais são os limites da aba Dados?

A aba Dados navega e edita o conteúdo do banco de dados pelo dashboard ou pela API, sem expor a senha nem a string de conexão, e exige o plano Intermediary ou superior. Abaixo desse plano, a API responde com PLAN_RESTRICTED_FEATURE (403). A leitura vale para qualquer membro do workspace; a escrita e o console SQL são somente para dono ou admin. Comandos administrativos e execução arbitrária de código são recusados no console do Redis e do MongoDB.

​

Quanto Blob Storage cada plano inclui?

O Blob Storage está disponível a partir do Economy. A cota conta todos os arquivos armazenados do dono do workspace. As regras de pasta, os domínios personalizados e as transformações de imagem também dependem do plano. As regras completas estão na seção de Blob Storage da base de conhecimento. Acima da cota, os uploads são bloqueados. O uso acima da cota só pode vir de um downgrade, e é cobrado a R$ 0,20 por GB iniciado na renovação. Quando um plano expira, há 72 horas de carência antes de os arquivos serem apagados.

​

Quais são os limites de deploy e de recursos?

A banda de rede é proporcional à RAM alocada: 50 Mbit com 100 MB, 100 Mbit com 256 MB, 200 Mbit com 512 MB, 400 Mbit com 1.024 MB, 800 Mbit com 2.048 MB e 1.600 Mbit com 4.096 MB.

​

Limite de deploys por hora

Conta como deploy: criar uma aplicação, enviar um zip, fazer deploy pelo GitHub (manual ou por push), reinstalar dependências e alterar o comando de build. Reiniciar e parar não contam. Um push do GitHub que chega depois do limite é ignorado e registrado no histórico de atividades.

​

Limites do histórico de deploys e do rollback

Cada aplicação guarda o código das versões anteriores por um tempo limitado, para que você possa fazer rollback para uma delas. A versão que está em execução agora nunca expira. A validade de uma versão anterior conta a partir do momento em que ela deixa de ser a versão em execução. O Economy mostra o histórico de deploys, somente leitura, e não guarda versões anteriores para fazer rollback.

​

Rollback automático e deploys sem downtime

Rollback automático (Intermediary e Enterprise): se a nova versão de uma aplicação parar em até 60 segundos após um deploy, a plataforma volta uma vez para a versão anterior e avisa você. Vem desativado por padrão; ative nas configurações da aplicação. Deploys sem downtime (Enterprise): a nova versão inicia ao lado da que está em execução e assume quando estiver saudável. Vem desativado por padrão (off); auto aplica o recurso às aplicações que recebem tráfego web e on a todas as aplicações. Veja Atualizar a configuração da aplicação para a configuração.

​

Próximos passos