Hosting Django i Python, bez stawiania serwera.

1. O Django é um framework para quem quer controlar o servidor

O Django foi concebido desde o início para oferecer controlo total sobre a camada de dados, a autorização e a estrutura do projeto, atraindo naturalmente programadores que querem ter um controlo semelhante sobre o ambiente em que a aplicação funciona, e não apenas sobre o código Python.

Na Saplo, podes criar uma aplicação Django 5.x com a versão de Python que preferires (3.11 ou 3.12, 3.12 por predefinição). O virtual host nginx e o gunicorn, como servidor WSGI, são configurados automaticamente, sem teres de escrever manualmente um ficheiro de configuração systemd ou nginx desde zero.

O manifesto declara um mínimo de 256 MB de RAM. É um limiar de entrada baixo, mas as aplicações Django reais com ORM, sessões e middleware raramente funcionam bem com menos de 2 GB de RAM, sobretudo com vários utilizadores em simultâneo. Por isso, o Box M é o mínimo prático para tudo o que seja mais do que um protótipo.

2. SSH, migrações e gestão da aplicação a partir do terminal

A partir do Box M, o acesso SSH completo com sudo permite executar as operações Django habituais diretamente no terminal: manage.py migrate, collectstatic, createsuperuser, sem passares por um painel de administração do hosting separado que não compreende os comandos do Django.

A implantação com Git atualiza o código da aplicação a cada push para o branch definido, mas as migrações da base de dados e os passos seguintes da implantação, como reiniciar o processo gunicorn e recolher os ficheiros estáticos, continuam a exigir um comando manual via SSH. Para um programador que conhece o Django, é um passo padrão e familiar.

O Celery e as tarefas em segundo plano, como lembretes, envio de e-mails e processamento de filas, podem ser executados por um processo separado no mesmo contentor, com a configuração de systemd adequada. Em aplicações Django com tarefas assíncronas, isto é muitas vezes uma parte padrão da arquitetura. Vale a pena monitorizar separadamente o consumo de memória do processo web e do processo worker do Celery, porque ambos competem pelo mesmo limite de RAM atribuído ao contentor da aplicação no Box, sobretudo quando executas mais tarefas Celery em paralelo em segundo plano.

3. Base de dados para Django

O Django utiliza por predefinição uma base de dados relacional. Na Saplo, Postgres e MySQL estão disponíveis como módulos de base de dados separados, instalados como contentores no teu próprio compose, e não como extras pagos cobrados à parte do alojamento da aplicação.

Para projetos que precisem de Redis, por exemplo como broker do Celery ou cache de sessões, está disponível um módulo Redis separado que podes instalar no mesmo Box do que a aplicação Django, sem necessidade de te ligares a um serviço Redis externo fora da infraestrutura da Saplo.

4. Django face às PaaS para Python

As plataformas PaaS especializadas em Python cobram muitas vezes por instância ou pelas horas de recursos consumidos, com preços indicados em dólares. Com tráfego real em produção na Polónia, isto complica o planeamento do orçamento em zlotys e faz com que a fatura sofra o impacto das oscilações cambiais.

Na Saplo, o preço é fixo e anual, em zlotys, independentemente de quantos pedidos por segundo a aplicação trate num dado momento. Para um projeto com tráfego irregular, como uma aplicação interna da empresa utilizada apenas durante o horário de expediente, é mais fácil de estimar do que a cobrança horária de recursos utilizados.

5. Para quem é indicado

Para um programador que esteja a desenvolver uma aplicação web ou um sistema interno da empresa em Django, o Box M com SSH completo oferece um ambiente de produção pronto para executar migrações e configurações, sem teres de montar um servidor de raiz.

Para uma equipa que esteja a desenvolver uma aplicação maior com Celery, Redis e uma base de dados separada, o Box L tem RAM suficiente para vários processos a correr em paralelo no mesmo contentor ou em módulos de base de dados separados instalados lado a lado.

Para uma agência que desenvolva sistemas B2B em Django para clientes, um Box pode alojar várias instalações Django independentes em simultâneo, cada uma no seu próprio contentor e com a sua própria base de dados.

6. Primeira implantação de uma aplicação Django na Saplo

Depois de criar a aplicação Django com a versão de Python escolhida, associa um repositório Git para que o código seja atualizado automaticamente a cada push. Depois, executa via SSH o primeiro manage.py migrate e createsuperuser para teres acesso ao painel de administração do Django.

Defines as variáveis de ambiente, como SECRET_KEY, cadeias de ligação à base de dados e chaves de APIs externas, no painel da aplicação ou num ficheiro.env dentro do contentor, de acordo com a prática padrão de configurar o Django fora do repositório de código.

Se a tua aplicação utilizar Celery para tarefas em segundo plano, configura um processo systemd adicional no contentor, com o worker e, opcionalmente, o beat para agendamentos, a utilizar o Redis como broker instalado como módulo separado no mesmo Box.

Convém configurar os ficheiros estáticos (collectstatic) no virtual host nginx do Box, para que o processo do gunicorn não tenha de servir ficheiros que o servidor web trata mais depressa e com menos uso de RAM.

Após a primeira implementação, monitoriza através de SSH os registos do gunicorn e do Django, para detetar erros de configuração, como esquecer de desativar DEBUG=True em produção, antes de a aplicação receber tráfego real de utilizadores.

7. Django REST Framework e aplicações API no Saplo

As aplicações Django construídas como API (Django REST Framework) funcionam no mesmo Box tal como as aplicações clássicas com templates, pois a diferença está no código do Django, não na forma de alojamento do Saplo.

Para uma API que utilize autenticação por token, convém guardar os segredos, como chaves JWT e chaves de API de serviços externos, nas variáveis de ambiente do contentor, e não no código do repositório, de acordo com as boas práticas de segurança.

O CORS e outros cabeçalhos de segurança são configurados ao nível da própria aplicação Django (middleware), e o proxy inverso do Saplo passa-os sem modificações. Por isso, a configuração padrão do Django funciona sem passos adicionais.

Quando uma API suporta um frontend embebido noutro domínio, como uma aplicação Next.js num Box separado ou num alojamento externo, convém verificar a configuração de ALLOWED_HOSTS e CORS_ALLOWED_ORIGINS nas definições do Django.

8. Segurança da configuração do Django em produção

O erro mais comum ao implementar o Django em produção é esquecer de desativar DEBUG=True. Em caso de erro da aplicação, esta configuração mostra ao utilizador o rastreio completo da pilha, incluindo variáveis de ambiente e fragmentos de código, o que representa uma grave divulgação de informação sobre a estrutura interna da aplicação.

O SECRET_KEY usado pelo Django para assinar sessões e tokens deve ser único para cada implantação e não deve constar no repositório de código, mas sim ser definido como uma variável de ambiente na configuração da aplicação na Saplo, à parte do próprio código-fonte.

O ALLOWED_HOSTS deve conter exatamente os domínios nos quais a aplicação está acessível, e não um asterisco que represente todos os hosts. Esta é uma proteção básica contra ataques de injeção no cabeçalho Host, especialmente importante em aplicações que recebem dados dos utilizadores da Internet.

Vale a pena separar logicamente os ficheiros estáticos dos ficheiros de media enviados pelos utilizadores (uploads), servindo os ficheiros estáticos da aplicação através do nginx e os ficheiros carregados pelos utilizadores através de um mecanismo separado com as permissões adequadas. Assim, evita-se que um utilizador carregue e execute um script malicioso no servidor.

As atualizações do próprio Django e dos pacotes Python utilizados (requirements.txt) devem fazer parte da manutenção regular, porque, tal como no ecossistema Node.js, as dependências desatualizadas são um vetor frequente de vulnerabilidades de segurança conhecidas e já corrigidas, exploradas por scanners automatizados de vulnerabilidades.

Em aplicações que armazenam dados pessoais dos utilizadores, vale a pena configurar deliberadamente as definições de sessão, como o tempo de expiração e as flags Secure e HttpOnly dos cookies. O Django suporta esta configuração nativamente, mas exige uma configuração explícita nas definições do projeto, e a configuração não é adequada com os valores predefinidos em todos os cenários. Convém rever esta configuração, juntamente com a lista completa das definições de segurança do Django, antes da primeira implantação em produção, em vez de descobrir uma definição em falta só depois de um incidente real de segurança.

9. Ecosistema Python e pacotes que apoiam as aplicações Django

O Python e o Django dispõem de um ecossistema rico de pacotes (PyPI) que respondem às necessidades habituais das aplicações web: autenticação, integrações com APIs externas, geração de relatórios PDF e processamento de pagamentos. Assim, podes construir funcionalidades com soluções prontas e testadas, em vez de escrever tudo de raiz.

No Saplo, o acesso SSH completo com sudo, disponível a partir do Box M, permite instalar quaisquer pacotes Python através do gestor pip padrão, sem as restrições impostas pela plataforma de alojamento. Esta abordagem diferencia-se da de alguns ambientes PaaS fechados, que suportam apenas uma lista limitada de bibliotecas.

A escolha entre as populares extensões do Django, como Django REST Framework para APIs, Django Channels para WebSockets e Django CMS para gestão de conteúdo, fica inteiramente ao critério do programador que constrói a aplicação, sem restrições de arquitetura impostas de antemão pelo alojamento.

A mudança da versão do Python, de 3.11 para 3.12, está disponível como opção de configuração da aplicação. Assim, podes utilizar funcionalidades mais recentes e obter melhorias de desempenho sem mudares de fornecedor apenas para alterar a versão do ambiente de execução.

Para as equipas que constroem aplicações Django mais complexas, com Celery, Redis e várias integrações externas, o controlo total do ambiente por SSH, aliado aos módulos base prontos da Saplo, oferece uma flexibilidade semelhante à de um VPS clássico, mas com um tempo de implantação do próprio ambiente base mais curto.

10. Testar as migrações da base de dados antes da implementação em produção

As migrações do Django que alteram a estrutura da base de dados, como adicionar uma coluna ou mudar o tipo de um campo, devem ser testadas primeiro numa cópia da base de dados, e não diretamente na base de produção. Um erro numa migração pode provocar perda de dados ou deixar a aplicação indisponível durante a sua execução.

Uma cópia de segurança do Box (a partir do Box L) antes de uma migração significativa é uma proteção adicional, permitindo regressar ao estado anterior à migração caso algo corra mal. Ainda assim, como boa prática, também vale criar manualmente uma cópia de segurança separada da base de dados imediatamente antes da própria migração.

As migrações irreversíveis, como remover uma coluna com dados, exigem especial cautela, porque, em caso de erro, só é possível restaurar os dados removidos a partir de um backup feito antes da migração, e não simplesmente revertendo a migração no Django.

Para equipas que trabalham na mesma base de dados, convém definir um procedimento claro para executar migrações em produção, indicando quem faz, quando e depois de que teste, a fim de evitar que duas pessoas tentem executar migrações conflitantes em simultâneo na mesma base de dados.

O acesso SSH completo com sudo no Saplo, disponível a partir do Box M, fornece todas as ferramentas necessárias para executar migrações com segurança. No entanto, a disciplina do processo, ou seja, teste, backup e só depois a migração em produção, continua a ser da responsabilidade integral da equipa de programadores que conduz o projeto.

11. Django no Saplo para programadores que procuram controlo

O acesso SSH completo com sudo, a escolha da versão do Python e a configuração pronta do gunicorn e do nginx dão ao programador Django exatamente a combinação de controlo e comodidade que procura ao implementar uma aplicação em produção: os comandos habituais do manage.py funcionam como devem e toda a infraestrutura do servidor em torno deles já está preparada, sem ser preciso montá-la de raiz em cada novo projeto Django. Para equipas que gerem vários projetos Django ao mesmo tempo, esta repetibilidade da configuração significa que o projeto seguinte arranca tão depressa como o primeiro, sem percorrer novamente os mesmos passos de configuração do servidor, já bem conhecidos. Na prática, deixa também menos espaço para pequenas diferenças de configuração entre projetos, difíceis de detetar, que em servidores montados de raiz são frequentemente uma fonte de erros de produção pouco óbvios.