Como reduzir os custos de hospedagem do seu app

Para reduzir os custos de hospedagem, descubra o que está realmente rodando e por quê, e depois deixe tudo entrar em modo de espera quando ninguém estiver usando. Em hosts que escalam para zero, um app ocioso e um banco de dados em espera custam muito pouco, então as maiores economias geralmente vêm de remover o que os mantém acordados — mais comumente código que consulta o banco de dados a cada poucos segundos — e depois de reduzir a banda e apagar apps que ninguém usa.

A maioria dos apps pequenos não tem um problema de tráfego. Eles têm um problema de “algo está sempre ligado”. Este guia mostra como encontrá-lo e corrigi-lo, com prompts que você pode dar a um criador de apps com IA.

O que você realmente paga

A conta de hospedagem de apps pequenos vem de poucas coisas. Saber qual delas é a mais alta mostra onde procurar.

Muitos hosts modernos, incluindo o Mythex, escalam para zero: quando ninguém está usando o app, o servidor para e não custa nada em computação, depois acorda na próxima visita. Isso muda a pergunta de “qual o tamanho do meu servidor?” para “por que meu servidor está acordado?”.

Passo 1: veja para onde vai o dinheiro

Antes de mudar qualquer coisa, abra a página de uso do seu host e encontre:

• Qual projeto custa mais. Muitas vezes um único app responde pela maior parte da conta.
• Qual categoria — computação, banco de dados, banda ou armazenamento.
• Quando ele gasta. Uma linha constante durante a noite, quando você não tem usuários, é a pista de que algo mantém o app acordado.

No Mythex, a página de detalhes de uso mostra os últimos 30 dias divididos em Build (o agente de IA) e Run (hospedagem, banda, banco de dados e armazenamento de arquivos), com um detalhamento por projeto.

Passo 2: deixe apps e bancos de dados ociosos dormirem

Esta é a alavanca real para a maioria dos apps pequenos. Um banco de dados que dorme quando ocioso e acorda na próxima requisição custa quase nada nas horas tranquilas. Um banco consultado a cada poucos segundos nunca fica ocioso, então você paga por ele o dia todo.

Os limites de hospedagem do Mythex explicam como isso funciona para apps publicados: um app em espera não gasta nada com computação, o banco de dados começa no menor tamanho, cresce enquanto está ocupado, entra em espera após 5 minutos ociosos e é cobrado pelo tamanho multiplicado pelo tempo em que ficou acordado. Assim, um app que consulta o banco de dados ao menos uma vez a cada poucos minutos, de dia e de noite, é cobrado como se estivesse sempre ocupado — enquanto o mesmo app sem essa atividade de fundo custa muito pouco.

Coisas comuns que mantêm um app acordado:

• Polling. Uma página que pergunta ao servidor “tem algo novo?” a cada 2–5 segundos. Deixe essa aba aberta em um notebook e o banco de dados nunca dorme.
• Painéis com atualização automática que recarregam os dados em um temporizador, mesmo quando ninguém está olhando.
• Monitores de disponibilidade que fazem ping no app a cada minuto.
• Loops de segundo plano no código do servidor — um setInterval que limpa ou sincroniza dados para sempre.
• Requisições “keep-alive” agendadas que alguém adicionou para evitar uma primeira visita lenta — elas funcionam impedindo a espera, exatamente o que custa dinheiro.

Peça à IA que os encontre:

Procure no código qualquer coisa que rode em um temporizador ou consulte o banco de dados repetidamente: polling, setInterval, atualização automática, loops de segundo plano. Liste cada um, com que frequência roda e se roda quando ninguém tem a página aberta. Não altere nada ainda.

Depois corrija um por um:

O painel consulta /api/orders a cada 3 segundos. Mude para atualizar apenas enquanto a aba do navegador estiver visível, e a cada 60 segundos em vez de 3. Adicione um botão manual de Atualizar.

Se o seu app realmente precisa de atualizações ao vivo (um chat, um placar ao vivo), pergunte se ele pode enviar atualizações apenas quando algo mudar, em vez de perguntar o tempo todo. Para muitos apps, “atualizar quando o usuário volta para a aba” é suficiente.

Passo 3: dimensione o servidor corretamente

Máquinas maiores custam mais por hora. Muitos apps criados com IA começam em um tamanho padrão que funciona bem; os problemas surgem quando se pede “mais potência” para corrigir uma lentidão que, na verdade, era uma consulta lenta.

• Mantenha o menor tamanho que atenda seu tráfego sem erros.
• Se você vir falhas por falta de memória, primeiro pergunte à IA se o app carrega muita coisa na memória (uma tabela inteira em vez de uma página de resultados).
• Adicione máquinas somente se tiver um tráfego medido que as exija.

No Mythex, o tamanho da máquina é escolhido na publicação com base no que o app precisa, e máquinas extras só são iniciadas quando o tráfego está intenso e voltam a dormir quando ele cai. O custo acompanha o tamanho, então peça no chat um tamanho menor se achar que está superdimensionado.

Passo 4: reduza a banda

A banda é o que os visitantes baixam. As imagens costumam ser a maior parte.

• Comprima as imagens e sirva formatos modernos como WebP ou AVIF.
• Redimensione as imagens para o tamanho em que são exibidas. Uma foto de 4.000 pixels mostrada como miniatura de 400 pixels desperdiça a maior parte do que é baixado.
• Use carregamento preguiçoso (lazy-load) para imagens abaixo da dobra.
• Armazene em cache os arquivos estáticos (scripts, estilos, imagens) para que visitantes que voltam não precisem baixá-los de novo. Veja o que é cache.
• Não deixe o app entregar arquivos grandes a cada visualização de página.

Verifique cada imagem do app. Redimensione-as para o maior tamanho em que são exibidas, converta-as para WebP e use carregamento preguiçoso em tudo que estiver abaixo da primeira tela. Me diga o tamanho total antes e depois.

Páginas mais rápidas e menor banda normalmente andam juntas — veja como deixar seu site mais rápido.

Passo 5: limpe o que ninguém usa

• Despublique apps antigos — implantações de teste, experimentos concluídos, o site de um evento do ano passado.
• Apague uploads antigos, logs e exportações que você não precisa.
• Apague links de pré-visualização compartilhados que você não usa mais. No Mythex, abrir um link de pré-visualização acorda o projeto e roda com seus créditos, então um link esquecido que alguém continua abrindo ainda custa.
• Remova serviços não usados — um servidor de API ou worker que o app não chama mais.

Passo 6: considere um site estático

Se o seu site não tem login, nenhum dado salvo de usuários e nenhuma lógica de servidor — um site institucional, um portfólio, um cardápio —, ele pode ser um site estático: arquivos simples servidos por uma CDN. Não há servidor nem banco de dados para manter em funcionamento. No Mythex, sites estáticos não usam créditos enquanto estão parados.

Este site não tem login nem dados salvos. Ele pode ser reconstruído como um site estático, sem servidor? O que perderíamos?

Passo 7: acompanhe as chamadas de API pagas

Para apps que chamam modelos de IA, mapas ou SMS, as contas de terceiros podem superar a de hospedagem.

• Exija login para qualquer coisa que custe dinheiro a cada chamada.
• Adicione um limite por usuário (veja o que é limitação de taxa).
• Guarde em cache respostas que não mudam, como a geocodificação do mesmo endereço.
• Defina limites de gasto ou alertas em cada provedor.

Erros comuns

• Adivinhar em vez de medir. Veja primeiro a divisão de uso; a parte cara muitas vezes não é a que você imagina.
• Comprar um servidor maior para resolver a lentidão. Um índice ausente no banco de dados ou carregar dados demais costuma ser a causa real.
• Fazer polling de tudo. Cada temporizador de poucos segundos é um motivo para o banco de dados continuar acordado.
• Fazer ping no app para mantê-lo “aquecido”. Isso elimina a economia que o escalar para zero oferece. Aceite um pequeno atraso na primeira visita, ou pague por um serviço sempre ativo de forma consciente.
• Esquecer implantações antigas. Apps não usados com bancos de dados e tarefas em segundo plano somam custos sem você perceber.
• Imagens sem compressão. Muitas vezes é o maior custo de banda em sites pequenos.

Checklist

• Sei qual projeto e qual categoria (computação, banco de dados, banda, armazenamento) custa mais.
• Nada faz polling no banco de dados a cada poucos segundos quando ninguém está olhando.
• Painéis são atualizados em um intervalo sensato ou apenas enquanto a aba está visível.
• Nenhum monitor de disponibilidade ou loop de segundo plano mantém o app acordado sem motivo.
• O servidor é o menor tamanho que funciona.
• Imagens estão redimensionadas, comprimidas e com carregamento preguiçoso; arquivos estáticos têm cache.
• Apps antigos foram despublicados, arquivos antigos apagados e links de pré-visualização não usados removidos.
• Sites sem dados ou logins são estáticos.
• APIs pagas têm login, limites por usuário e alertas de gasto no provedor.

Reduzindo custos no Mythex

O Mythex usa um único saldo de créditos para criar e para hospedar, então as economias de hospedagem deixam mais créditos para criar. Alguns pontos específicos do Mythex:

• Apps publicados e seus bancos de dados entram em espera quando ociosos e acordam na próxima visita. O banco de dados entra em espera após 5 minutos ociosos, então remover o polling constante costuma ser o maior ganho.
• O plano Pro paga metade da tarifa do plano Free para hospedagem, bancos de dados, banda, armazenamento de arquivos e o sandbox de pré-visualização; a IA custa o mesmo nos dois planos. Veja Créditos.
• Você recebe um e-mail antes que um saldo baixo pausaria um app publicado, e apps pausados mantêm o banco de dados e os arquivos.

Para a visão geral sobre custos de operação, veja quanto custa criar um app e o que é hospedagem web.

Perguntas