← Voltar ao blog

Como configurar uma VPS Ubuntu do zero: roteiro prático para produção

Um roteiro para sair de uma VPS nova e chegar a uma aplicação publicada com SSH, firewall, Docker, domínio e backup.

·
  • #vps
  • #ubuntu
  • #docker
  • #deploy
  • #infraestrutura

Contratar uma VPS leva poucos minutos. Transformá-la em um ambiente seguro e recuperável para uma aplicação leva um pouco mais de cuidado. O erro comum é instalar Docker, abrir uma porta e chamar isso de produção. O resultado costuma aparecer depois: acesso root exposto, banco sem backup, certificado vencido ou um deploy que ninguém consegue repetir.

Este roteiro organiza a ordem das decisões para uma VPS nova com Ubuntu Server. Ele não depende de um provedor específico: DigitalOcean, Hetzner, Contabo, AWS e outros mudam o painel, mas a máquina que você recebe segue os mesmos fundamentos.

1. Escolha o tamanho e a região antes de instalar qualquer coisa

Para um site pequeno ou uma API simples, 1 GB de RAM pode funcionar, mas 2 GB oferecem mais margem para Docker, atualizações e picos. Se a aplicação inclui banco de dados, mais de um container ou WordPress com tráfego, trate 2 GB como ponto de partida mais confortável.

Escolha também uma região próxima do público. Latência não é o único critério, mas é difícil corrigir depois sem migrar o servidor. Antes de provisionar, verifique o custo de snapshots e de saída de dados: backup que não cabe no orçamento deixa de ser backup.

2. Atualize e pare de trabalhar como root

No primeiro acesso, atualize os pacotes e crie um usuário normal com permissão administrativa. A ideia não é impedir root para sempre; é tornar o caminho rotineiro menos perigoso.

sudo apt update && sudo apt upgrade -y
sudo adduser deploy
sudo usermod -aG sudo deploy

Depois, configure a chave SSH para esse usuário e confirme que consegue abrir uma segunda sessão antes de encerrar a primeira. Só então desabilite login remoto direto como root e autenticação por senha, se essa for a política escolhida.

3. Exponha somente o necessário

Uma aplicação web precisa normalmente de HTTP e HTTPS; SSH fica restrito à administração. Com UFW, comece pela regra de segurança que mantém a sessão remota disponível e libere somente o tráfego web:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Não publique a porta de banco de dados ou a porta interna de um container sem um motivo concreto. Um proxy reverso pode receber o tráfego externo e encaminhar para a aplicação localmente.

4. Decida como a aplicação será executada

Docker é uma escolha prática para grande parte dos projetos porque deixa dependências e comandos de inicialização explícitos. Ele não resolve segurança e backup automaticamente: volumes, variáveis de ambiente, portas e atualização das imagens continuam sendo responsabilidade de quem opera a VPS.

Em uma stack comum, Nginx recebe conexões nas portas 80 e 443, termina HTTPS e encaminha o tráfego para uma aplicação Node.js, Python, PHP ou outro serviço que escuta apenas em 127.0.0.1 ou em uma rede Docker interna.

5. Configure domínio e HTTPS antes de divulgar a URL

Crie o registro DNS para o IP público, espere a propagação e emita um certificado. Certificados e redirecionamento de HTTP para HTTPS devem entrar antes do lançamento, não depois de o site aparecer em buscadores ou ser compartilhado.

Teste ao menos estes cenários:

  • domínio principal abre em HTTPS;
  • HTTP redireciona para HTTPS;
  • subdomínios apontam para a aplicação certa;
  • portas de banco e serviços internos não respondem pela internet.

6. Planeje backup e restauração, não apenas cópia

Uma cópia local no mesmo disco não protege contra perda da VPS. Faça backup de configurações, volumes, uploads e dumps consistentes de banco em outro provedor ou bucket. Mais importante: teste a restauração em um diretório ou servidor separado.

O artigo Backups de servidores com Restic e S3 explica uma abordagem com snapshots criptografados e retenção. Se você consegue executar o backup, mas nunca restaurou, ainda não sabe se ele atende ao objetivo.

7. Documente o caminho de deploy

Anote o repositório, as variáveis necessárias, o comando de atualização e como voltar para uma versão anterior. Um deploy manual pode ser suficiente no início, desde que seja repetível. A primeira automação útil costuma ser uma pipeline que executa testes, entrega uma versão identificável e deixa logs para investigação.

Próximo passo

Este artigo resume a sequência. Para um passo a passo completo, com decisões entre Docker e instalação manual, proxy reverso, WordPress, deploy, troubleshooting, scripts e templates, conheça o Guia de Configuração de VPS.