Melhor forma de hospedar uma aplicação Python

Python roda quase tudo: bot do Discord, API em FastAPI, site em Django, script que coleta dados de hora em hora, modelo de IA. Por isso a pergunta "onde hospedar Python?" não tem uma resposta só. Um bot precisa ficar ligado 24 horas, uma tarefa agendada roda dois minutos por dia e um modelo com torch precisa de muita RAM.

O ponto de partida é o tipo de aplicação. Dele saem os critérios que mudam a escolha, a recomendação por cenário e o que preparar antes do deploy.

Que tipo de aplicação Python você vai hospedar?#

Quase todo projeto cai em um destes quatro grupos:

• Processo de longa duração: bots do Discord e do Telegram, workers de fila, scrapers contínuos. Ficam ligados o tempo todo e mantêm conexões abertas.
• Aplicação web: APIs e sites. Podem ser WSGI (Flask, Django no modo clássico), servidos por Gunicorn ou Waitress, ou ASGI (FastAPI, Starlette, Django assíncrono), servidos por Uvicorn. Recebem requisições HTTP e precisam escutar numa porta.
• Tarefa agendada: um script que roda de tempos em tempos, como um relatório diário ou uma limpeza no banco. Passa a maior parte do tempo parado.
• IA e dados: aplicações que carregam modelos com torch, transformers ou pandas. O que pesa aqui é RAM e o tamanho das dependências.

O tipo define a primeira escolha: se o processo precisa ficar ligado sempre ou pode acordar sob demanda.

Quais critérios importam na escolha?#

1. Sempre ligado ou sob demanda. Bots e conexões WebSocket exigem processo contínuo. Tarefas curtas podem rodar sob demanda.
2. Limite de tempo por execução. Funções serverless têm teto: no AWS Lambda, uma invocação dura no máximo 15 minutos.
3. RAM. Cada worker web é um processo Python separado e soma memória. Modelos de IA podem passar de vários GB. Veja como dimensionar RAM e CPU.
4. Dependências nativas. Bibliotecas como numpy, psycopg e torch trazem código compilado. Se o ambiente não tiver o pacote pronto (wheel) para a sua versão do Python e o seu sistema, a instalação tenta compilar e pode falhar.
5. Versão do Python. Use uma versão ainda com suporte. O calendário oficial mostra quais versões estão nessa fase e quando cada uma deixa de receber correções.
6. Quanto você quer administrar. Sistema operacional, atualizações de segurança, firewall, proxy reverso e reinício automático: alguém precisa cuidar disso. Ou é você, ou é a plataforma onde você hospeda.

Quais são as opções e os prós e contras de cada uma?#

Dois pontos costumam decidir. Primeiro, serverless não serve para bots: o Lambda limita a execução a 15 minutos e também o tamanho do pacote .zip, o que deixa de fora bibliotecas grandes como torch, a não ser por imagem de container (os tamanhos atuais estão na página de limites do Lambda). Segundo, a VPS dá liberdade, mas cada hora gasta configurando servidor é uma hora fora do seu código. Os artigos VPS ou plataforma de nuvem e serverless ou containers aprofundam essas duas comparações.

Qual é a melhor opção para cada cenário?#

• Bot do Discord, Telegram ou WhatsApp: processo sempre ligado, numa plataforma de containers ou numa VPS. O bot reconecta sozinho se o processo reiniciar, desde que algo o reinicie.
• API em FastAPI ou Flask com tráfego constante: container sempre ligado, com servidor de produção. Sem cold start, a primeira requisição do dia responde tão rápido quanto as outras. Veja como hospedar FastAPI, Flask e Django.
• Site em Django com banco de dados: container ou VPS, mais um banco hospedado separado. Veja o melhor banco para Python.
• Script que roda uma vez por dia: serverless com agendamento, ou um processo sempre ligado com um agendador interno se você já tem uma aplicação rodando.
• Aplicação com torch ou transformers: container ou VPS com RAM de sobra. Confira se o ambiente tem os pacotes prontos para não compilar nada no deploy.
• Aprender e testar: seu próprio computador. Quando o projeto precisar ficar no ar, migre.

Como preparar a aplicação Python para produção?#

Qualquer que seja a opção, quatro cuidados evitam a maioria dos problemas.

1. Fixe as dependências. Liste tudo no requirements.txt com versão, ou use um lockfile (uv, Poetry). Assim o servidor instala exatamente o que você testou:

# versões de exemplo: fixe as que você testou (veja com pip freeze)
fastapi==0.143.0
uvicorn==0.54.0

2. Use um servidor de produção. A documentação do Flask é direta: não use o servidor de desenvolvimento em produção, porque ele não foi feito para ser seguro, estável nem eficiente. O Django diz o mesmo do runserver. Para FastAPI, rode o Uvicorn escutando em todas as interfaces (0.0.0.0), não só em 127.0.0.1. Um main.py mínimo:

import os

from fastapi import FastAPI

app = FastAPI()


@app.get("/health")
def health():
    return {"status": "ok"}


if __name__ == "__main__":
    import uvicorn

    port = int(os.environ.get("PORT", "8000"))
    uvicorn.run(app, host="0.0.0.0", port=port)

Para vários processos, a documentação do FastAPI usa a opção --workers:

uvicorn main:app --host 0.0.0.0 --port 8000 --workers 2

Em Flask ou Django, o equivalente é o Gunicorn. A documentação do Gunicorn sugere começar com (2 × núcleos de CPU) + 1 workers e ajustar sob carga. Lembre que cada worker consome RAM própria.

3. Leia configuração do ambiente. Tokens, senhas e URLs de banco ficam em variáveis de ambiente, nunca no código. A porta também: cada hospedagem informa a sua.

4. Escreva logs na saída padrão. Use print ou o módulo logging apontando para stdout. Quase toda hospedagem mostra essa saída no painel, e é por ela que você vai diagnosticar erros.

Quais erros aparecem ao hospedar Python?#

• ModuleNotFoundError: pacote fora do requirements.txt ou nome de instalação diferente do nome do import. Veja Cannot find module e ModuleNotFoundError.
• App sobe mas ninguém acessa: o servidor escuta em 127.0.0.1 ou numa porta diferente da esperada pela hospedagem.
• Processo morto sem erro claro: falta de memória, comum com vários workers ou modelos grandes. Reduza workers ou aumente a RAM.
• Dados que somem: SQLite ou arquivos salvos no disco de um ambiente que é recriado a cada deploy. Use um banco ou um storage externo.
• Compilação falhando no deploy: a versão do Python do servidor não tem wheel para alguma dependência. Alinhe a versão local com a do servidor.

Como fazer isso na Square Cloud#

Entre os diversos runtimes da Square Cloud, como Node.js, Python e Go, o de Python vem com wheels prontas de torch e transformers, para que essas bibliotecas não sejam compiladas no deploy. Você faz o deploy por upload de ZIP no painel, pela CLI, pelo GitHub (o push faz o deploy, via GitHub Action oficial ou webhook) ou pela extensão do VS Code. O arquivo de configuração squarecloud.app é opcional: o painel o gera no deploy (runtime, memória, arquivo principal), ou você o escreve na raiz do projeto.

As aplicações rodam em containers sempre ligados, sem cold start nem modo de suspensão, o que atende bots e APIs. O reinício automático vem ligado no deploy pelo painel e religa a aplicação quando o processo encerra com erro. No start, a plataforma roda pip install -r requirements.txt, com as variáveis de ambiente já definidas, e o disco da aplicação persiste entre restarts e deploys.

A RAM do plano é um pool compartilhado: no mínimo 256 MB por aplicação de fundo, como um bot, e 512 MB por aplicação web. O Hobby custa a partir de R$ 12,49 por mês, com 1 GB. As variáveis de ambiente ficam por aplicação no painel, na API, na CLI ou no VS Code, e a mudança vale no próximo restart, sem rebuild.

Uma aplicação web escuta em 0.0.0.0, na porta da variável PORT. Snapshots manuais estão disponíveis em todo plano. Veja os detalhes do ambiente Python na página de runtimes.