Qual plano HTTP escolher
Cada plano HTTP define a CPU e a memória de cada instância do projeto. Escolher o plano certo evita dois problemas: pagar por capacidade que a aplicação nunca usa, ou escolher um plano pequeno demais e ver a aplicação demorar para iniciar, responder devagar ou reiniciar por falta de memória.
Esta página explica o foco de cada plano e dá exemplos de aplicações que fazem sentido em cada um. Os preços atualizados aparecem no console ao criar o projeto e no comando zenifra plans --type http.
Resumo rápido
| Plano | vCPU | RAM | Foco | Exemplos típicos |
|---|---|---|---|---|
| Free | 0,5 | 512 MB | Experimentar a Zenifra sem custo | Primeiro deploy, protótipo, projeto de estudo |
| Static | 0,1 | 64 MB | Sites estáticos com custo mínimo | Landing page, portfólio, documentação, SPA já compilada servida por NGINX |
| Basic | 0,5 | 512 MB | Primeira aplicação dinâmica em produção | API Node.js, Python ou Bun pequena, site Next.js com pouco tráfego, bot |
| Premium | 1 | 1 GB | Aplicações em crescimento, com métricas | API com banco de dados, painel interno, n8n |
| Premium Plus | 2 | 2 GB | Aplicações mais pesadas ou com controle de acesso por IP | WordPress, Metabase, Django com mais tráfego, ferramentas internas |
| Business | 8 | 8 GB | Alto tráfego e cargas intensas de CPU | E-commerce, API com muitos usuários simultâneos, processamento em lote |
| Deep Learning Basic | 4 | 4 GB + GPU de 12 GB | Inferência de IA com GPU | Modelos de visão, transcrição de áudio, LLMs pequenos |
| Deep Learning Premium | 8 | 8 GB + GPU de 24 GB | Modelos maiores com GPU | LLMs maiores, geração de imagens, inferência com mais VRAM |
Todos os planos pagos oferecem auto-scaling: quando o tráfego cresce, a Zenifra adiciona instâncias do mesmo plano. Por isso, para aguentar mais tráfego, às vezes vale manter o plano e adicionar instâncias em vez de subir de plano. Veja Escala.
Free
Foco: conhecer a plataforma e publicar o primeiro projeto sem custo.
O Free tem bastante memória para um plano gratuito (512 MB), então roda aplicações Node.js, Python ou Bun comuns. As limitações estão em outro lugar: a organização pode ter no máximo 1 instância no Free (2 em organizações criadas antes da atualização da oferta gratuita), o plano não tem auto-scaling e não é possível trocar de plano a partir dele.
- Faz sentido para: testar um repositório, apresentar um protótipo, projetos de estudo.
- Não é o ideal para: produção. Quando o projeto ganhar usuários, recrie-o em um plano pago para ter auto-scaling e troca de plano.
Static
Foco: colocar sites estáticos no ar com o menor custo possível.
O Static é o plano mais barato da Zenifra e foi desenhado para uma tarefa: entregar arquivos HTML, CSS, JavaScript e imagens que já estão prontos. Com 0,1 vCPU e 64 MB por instância, ele roda bem um servidor HTTP leve, como NGINX, Caddy ou Apache, servindo uma pasta de arquivos.
O que roda bem no Static
- landing pages e sites institucionais;
- portfólios, currículos e páginas pessoais;
- blogs e documentação gerados por ferramentas como Hugo, Jekyll, Astro (modo estático), Docusaurus, VitePress ou MkDocs, depois da build;
- SPAs feitas com React, Vue, Angular ou Svelte, já compiladas e servidas por NGINX;
- documentação de API com Swagger UI ou Redoc;
- ferramentas que rodam inteiramente no navegador, como editores, conversores e calculadoras.
Desempenho medido no plano Static
Testamos sites estáticos reais no plano Static, com 1 instância, acessados pela URL pública do projeto:
| Medida | Resultado no plano Static |
|---|---|
| Memória usada por um site servido por NGINX | cerca de 12 a 16 MB dos 64 MB |
| Início do servidor | de 2 a 7 segundos para NGINX, Caddy e Apache |
| Requisições por segundo, com 10 acessos simultâneos | de 15 a 45, conforme o servidor e o tamanho da página |
| Tempo de resposta típico (mediana), com 10 acessos simultâneos | de 200 a 300 ms para NGINX e Apache |
| Erros e reinícios durante os testes | nenhum |
Isso atende com folga um site com milhares de visitas por dia. Além disso, a CDN incluída guarda em cache arquivos como JavaScript, CSS e imagens. Assim, a maior parte desses arquivos chega ao visitante sem passar pela instância, que fica livre para responder ao HTML. Se o tráfego crescer, ative o auto-scaling antes de pensar em outro plano.
O que não roda bem no Static
Aplicações feitas com frameworks em Node.js, Python, PHP, Ruby ou Java mantêm um processo rodando o tempo todo e precisam de mais memória e CPU do que o Static oferece. Nos nossos testes, uma aplicação Express simples levou mais de um minuto para iniciar no Static e ficou perto do limite de memória.
Site estático publicado pelo runtime Node.js
Se o seu site estático é publicado a partir de um repositório Git com o runtime Node.js (por exemplo, com serve), use o plano Basic ou superior. Nos nossos testes, um site estático servido com npx serve ficou sem memória no Static e reiniciou antes de responder à primeira visita. Para usar o Static, publique uma imagem OCI com NGINX, que entrega os mesmos arquivos com uma fração da memória.
- Não é o ideal para: APIs, sites com renderização no servidor (Next.js, Nuxt, Remix), WordPress, aplicações que acessam banco de dados ou qualquer processo Node.js, Python ou PHP em execução.
Basic
Foco: a primeira aplicação dinâmica em produção.
Com 0,5 vCPU e 512 MB, o Basic roda uma aplicação Node.js, Python ou Bun típica com folga e permite auto-scaling.
- Faz sentido para: APIs REST pequenas (Express, Fastify, NestJS enxuto, FastAPI, Flask), sites Next.js com pouco tráfego, bots de Discord ou Telegram, webhooks, workers leves e sites estáticos publicados pelo runtime Node.js. Também atende Jupyter Notebook para testes e notebooks leves.
- Hora de subir: quando a aplicação usa memória perto do limite com frequência, quando o tempo de resposta cresce nos horários de pico mesmo com auto-scaling, ou quando você precisa de métricas de CPU, RAM e requisições, disponíveis a partir do Premium.
Premium
Foco: aplicações em crescimento que precisam de visibilidade.
O Premium dobra a CPU e a memória do Basic e é o primeiro plano com métricas de CPU, RAM, armazenamento e requisições HTTP, healthcheck e subdomínio personalizado.
- Faz sentido para: APIs com banco de dados e várias rotas, back-ends de aplicativos móveis, painéis administrativos, aplicações Next.js com renderização no servidor e automação com n8n.
- Hora de subir: quando a aplicação precisa de mais de 1 GB por instância (ferramentas de BI, CMS com muitos plugins) ou de controle de acesso por IP.
Premium Plus
Foco: aplicações mais pesadas e ferramentas internas que precisam de controle de acesso.
Com 2 vCPU e 2 GB, o Premium Plus roda aplicações que precisam de bastante memória já na inicialização. É também o primeiro plano com whitelist e blacklist de IP, útil para restringir ferramentas internas. Veja Rede e controle de acesso.
- Faz sentido para: WordPress, Metabase, Django ou Rails com tráfego moderado, aplicações Java ou .NET, painéis internos acessíveis só pela rede da empresa.
Business
Foco: alto tráfego e cargas intensas de CPU em uma única instância.
Com 8 vCPU e 8 GB, o Business é para aplicações que já estão em produção com muitos usuários, ou que fazem processamento pesado em cada requisição.
- Faz sentido para: e-commerces com picos de acesso, APIs com muitos usuários simultâneos, geração de relatórios e PDFs, processamento de imagens ou vídeos, aplicações que mantêm muitos dados em memória.
Deep Learning Basic e Deep Learning Premium
Foco: inferência de modelos de IA com GPU dedicada.
| Plano | GPU | Para quê |
|---|---|---|
| Deep Learning Basic | NVIDIA RTX 3060 com 12 GB de VRAM | Modelos de visão computacional, transcrição de áudio, embeddings e LLMs pequenos |
| Deep Learning Premium | NVIDIA RTX 4090 com 24 GB de VRAM | LLMs maiores, geração de imagens e modelos que precisam de mais VRAM |
Escolha pela VRAM: o modelo precisa caber inteiro na memória da GPU. Se você só precisa chamar modelos prontos, sem hospedar o seu, a Zenifra IA costuma ser mais simples.
Sinais de que o plano ficou pequeno
| Sinal | O que fazer |
|---|---|
| A aplicação demora muito para responder logo depois de iniciar | Suba de plano; a CPU disponível não dá conta da inicialização |
| A aplicação reinicia sozinha e os logs param de repente | Provável falta de memória; suba para um plano com mais RAM |
| O tempo de resposta cresce só nos horários de pico | Ative o auto-scaling antes de trocar de plano |
| Uso de memória sempre perto do limite nas métricas | Suba de plano antes que a aplicação comece a reiniciar |
A troca de plano está disponível para projetos com pagamento por hora e não é permitida de ou para o plano Free. Veja Escala.
Perguntas frequentes
Posso começar no Static e mudar depois?
Sim, em projetos com pagamento por hora você pode trocar de plano em Editar projeto. Se a aplicação deixar de ser um site estático, troque para o Basic ou superior.
Meu site é feito em Next.js. Ele roda no Static?
Só se você usar a exportação estática (output: 'export') e publicar a pasta gerada com NGINX. Next.js com renderização no servidor precisa de um processo Node.js rodando e deve usar o Basic ou superior. Veja Next.js.
Mais instâncias ou um plano maior?
Mais instâncias ajudam quando há muitos acessos simultâneos e cada requisição é leve. Um plano maior ajuda quando cada instância sozinha precisa de mais memória ou CPU, por exemplo, para iniciar a aplicação ou processar uma requisição pesada.
Próximos passos
Última atualização em
Ideal para cada plano
Descubra qual plano da Zenifra combina com a sua aplicação, Job, banco de dados, cache ou fila, com o foco de cada plano e exemplos do que roda bem.
Qual plano escolher para Jobs agendados
Para que serve cada plano de Job agendado da Zenifra (job-starter, job-basic e job-premium), com exemplos de tarefas que rodam bem em cada um.