Como implantar Django e PostgreSQL no Railway: guia prática

Publicado em 2026-10-26 por frfrand

Um guia humano para publicar Django com PostgreSQL no Railway, revisar falhas comuns e entender como fazer também em um VPS com ArduMaker.

Você tem um projeto Django, funciona perfeitamente no localhost e agora quer que alguém mais o use. Railway é uma das opções para publicá-lo sem ter que instalar e configurar um servidor Linux manualmente. O detalhe que costuma surpreender é que publicar o código não basta: você também precisa de PostgreSQL, variáveis, migrações e uma forma de encontrar erros.

Vamos com um caso concreto: um aplicativo de reservas feito em Django, com usuários, turnos e notificações. A ideia é entender o caminho real, não fazer uma demo que funcione cinco minutos e depois quebre.

Antes de enviar nada

Seu projeto deve executar corretamente os testes locais e ter dependências declaradas. Se você usa PostgreSQL, instale um driver compatível com a versão do Django, como psycopg. Para servir Django em produção, você pode usar Gunicorn, e para arquivos estáticos revisar uma configuração como WhiteNoise ou um servidor especializado. Não confunda arquivos estáticos do projeto com fotos enviadas por usuários: estas últimas precisam de armazenamento persistente.

Em settings.py revise três coisas: DEBUG=False em produção, ALLOWED_HOSTS com os domínios corretos e uma SECRET_KEY que venha de uma variável de ambiente, nunca do repositório. Mantenha um requirements.txt ou um arquivo de dependências equivalente.

Passo 1. Conecte o repositório GitHub ao Railway

Crie um projeto no Railway, escolha implantar a partir do GitHub e selecione o repositório do Django. O Railway também suporta CLI e modelos, mas o GitHub é prático se você quiser que fique claro qual commit corresponde a cada implantação.

Se a compilação falhar, não modifique cinco coisas de uma vez. Procure nos logs a primeira dependência que não pôde ser instalada. Confirme também a versão do Python que seu projeto precisa.

Passo 2. Adicione o PostgreSQL

A partir do mesmo projeto, adicione o serviço PostgreSQL. O Railway expõe variáveis de conexão que você pode referenciar a partir do serviço web. Dependendo de como seu Django está configurado, você usará uma DATABASE_URL interpretada pelo aplicativo ou variáveis separadas, como PGHOST, PGPORT, PGDATABASE, PGUSER e PGPASSWORD.

Um exemplo de configuração explícita é:

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": os.environ["PGDATABASE"],
        "USER": os.environ["PGUSER"],
        "PASSWORD": os.environ["PGPASSWORD"],
        "HOST": os.environ["PGHOST"],
        "PORT": os.environ.get("PGPORT", "5432"),
    }
}

É importante que a API se conecte ao serviço correto e que o PostgreSQL não fique aberto desnecessariamente ao público. Não copie credenciais reais em capturas ou tutoriais.

Passo 3. Escolha como iniciar o aplicativo

Para um projeto tradicional, um comando de inicialização pode ser:

gunicorn config.wsgi:application --bind 0.0.0.0:$PORT

Substitua config pelo nome real do seu módulo Django. O Railway atribui a porta por meio do ambiente, portanto, não é conveniente codificar uma fixa. Se você usar ASGI, WebSockets ou outra arquitetura, o processo adequado pode ser diferente.

Execute as migrações do Django por meio de um procedimento controlado, por exemplo python manage.py migrate, antes de considerar concluída uma atualização incompatível com o esquema anterior. Também revise collectstatic quando for o caso.

Passo 4. Publique o domínio e teste algo real

Na configuração de rede do serviço web, você pode gerar um domínio público ou vincular um próprio. Verifique o HTTPS, faça login com um usuário de teste e crie uma reserva. Reinicie o serviço e verifique se a reserva continua no PostgreSQL. Se desaparecer, provavelmente você estava salvando os dados em um lugar errado.

Depois, teste uma falha controlada: onde você vê o erro? Você consegue reconhecer qual versão foi publicada? Sabe como voltar para a anterior? Essas três perguntas diferenciam uma demonstração de um implantação que você pode manter.

E se o aplicativo tiver Celery, Redis e tarefas agendadas?

Então não falamos apenas do Django e de um banco de dados. Uma API da web deve responder rapidamente; e-mails, relatórios e tarefas extensas podem ir para workers do Celery, com um broker como o Redis quando sua arquitetura exigir. No Railway, você pode distribuir esses processos entre serviços independentes e configurar suas variáveis, inicialização e consumo.

Por isso não basta comparar o preço do serviço web. É preciso olhar todo o aplicativo, incluindo armazenamento, workers, bancos de dados, tráfego e backups.

Como eu faria o mesmo projeto com ArduMaker

A abordagem da ArduMaker é diferente: você cria um VPS, vincula o repositório GitHub para implantar o Django, configura o PostgreSQL e executa o aplicativo como serviço. Você pode colocar o Nginx na frente do Gunicorn, associar um domínio com HTTPS e gerenciar workers como processos separados.

Para um sistema de reservas com FastAPI ou Django, PostgreSQL, Redis e Celery, ter esses componentes dentro de um VPS pode simplificar o controle operacional: você vê o servidor, seus processos e seus recursos a partir do mesmo ambiente. Você também precisa se encarregar de dimensioná-lo, atualizá-lo e testar as cópias. Não é um atalho mágico.

Se você quiser delegar a administração e seu software se encaixar no modelo gerenciado, a Railway faz muito sentido. Se precisar configurar serviços do sistema, reunir várias peças em um servidor ou trabalhar com ferramentas MCP, vale a pena comparar a ArduMaker.

Três erros que evitaria desde o primeiro dia

Primeiro: publicar Django com DEBUG=True ou segredos no Git. Segundo: acreditar que um arquivo escrito dentro do contêiner de execução sobreviverá a qualquer recriação. Terceiro: deixar as migrações, as cópias e os workers «para depois». Em uma aplicação com dados de clientes, esse depois chega rápido.

Para seguir investigando

Leia o guia oficial do Django na Railway, nosso artigo sobre o que é Railway e a comparação detalhada da Railway com ArduMaker. Os planos e limites mudam: consulte as condições atuais antes de migrar uma aplicação.

Em uma frase: publicar Django é fácil de demonstrar; deixá-lo pronto para usuários reais implica pensar em dados, processos, segurança e recuperação. Escolha a plataforma que o ajude a sustentar essas quatro coisas.