Do Visual Studio Code ao servidor: como publicar um sistema Angular + .NET Core + MongoDB na Hostinger

Por que a Hostinger é boa opção para devs brasileiros?

Se você está buscando um servidor para publicar seu sistema, a Hostinger tem três coisas que fazem a diferença no dia a dia: preço acessível, suporte em português e painel de controle (hPanel) simples de usar. Para um VPS com Ubuntu 22.04, você consegue planos a partir de R$ 25 por mês - o suficiente para rodar uma API .NET Core, um banco MongoDB e servir o frontend Angular sem sufocar.

Outra vantagem é que a Hostinger usa servidores com boa latência para o Brasil, então seu sistema vai responder rápido para usuários aqui. Se você ainda não tem conta, acesse pelo nosso link e garanta o desconto: Hostinger com desconto via CuritibaBlog.

O que você vai precisar antes de começar

Antes de abrir o terminal, certifique-se de ter tudo instalado na sua máquina local. Você vai precisar do Visual Studio Code com as extensões Remote SSH (para editar arquivos diretamente no servidor), Angular Language Service e C# Dev Kit. No Node.js, Angular CLI e .NET SDK precisam estar instalados. Para o banco, o MongoDB Compass ajuda a visualizar os dados durante o desenvolvimento.

No servidor você também vai precisar de um domínio. Pode ser um domínio comprado na própria Hostinger ou em qualquer outro registrador - o processo de apontar o DNS é o mesmo.

Passo 1 - Contratando e configurando seu VPS

Acesse a Hostinger pelo link hostinger.com/br e escolha um plano KVM. O KVM 2 (2 vCPUs, 8 GB RAM) é o mínimo para essa stack. Selecione Ubuntu 22.04 LTS como sistema operacional e escolha uma localização de servidor próxima ao Brasil.

Após contratar, o hPanel vai mostrar o IP do servidor. O primeiro acesso é sempre como root via SSH. Mas a primeira coisa que você deve fazer é criar um usuário dedicado e desabilitar o login root direto:

# Conecte como root pela primeira vez
ssh root@SEU_IP

# Crie um usuario dedicado
adduser deploy

# Adicione ao grupo sudo
usermod -aG sudo deploy

# Copie a chave SSH para o novo usuario
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

# Atualize os pacotes
apt update && apt upgrade -y

A partir daqui, acesse sempre como deploy, não como root. Isso é uma boa prática de segurança: se algum processo comprometido tentar escalar privilégios, ele vai encontrar uma barreira.

Passo 2 - Instalando as dependências no servidor

Com o servidor atualizado, instale tudo que o sistema precisa. O NGINX vai servir o Angular e fazer proxy reverso para a API. O .NET Runtime executa o backend. O MongoDB guarda os dados. O Certbot cuida do SSL.

# NGINX
sudo apt install nginx -y

# .NET Runtime (verifique a versão atual em learn.microsoft.com)
wget https://packages.microsoft.com/config/ubuntu/22.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
sudo apt update
sudo apt install dotnet-runtime-8.0 -y

# MongoDB 7.x
curl -fsSL https://www.mongodb.org/static/pgp/server-7.0.asc | sudo gpg -o /usr/share/keyrings/mongodb-server-7.0.gpg --dearmor
echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-7.0.gpg ] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/7.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list
sudo apt update && sudo apt install mongodb-org -y
sudo systemctl start mongod && sudo systemctl enable mongod

# Certbot
sudo apt install certbot python3-certbot-nginx -y

# Firewall basico
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

Repare que o UFW está configurado para permitir apenas SSH e as portas 80/443 do NGINX. Tudo mais fica bloqueado - incluindo a porta 27017 do MongoDB, que nunca deve ficar exposta para a internet.

Passo 3 - Preparando o banco de dados MongoDB

O MongoDB, por padrão, já escuta apenas em 127.0.0.1. Verifique isso antes de continuar:

sudo grep -E "bindIp|bindIpAll" /etc/mongod.conf

Você deve ver bindIp: 127.0.0.1. Se aparecer 0.0.0.0, corrija imediatamente - isso significaria que o MongoDB está acessível pela internet. Agora crie o banco e o usuário da sua aplicação:

mongosh

use meu_banco

db.createUser({
  user: "meu_usuario",
  pwd: "SUA_SENHA_FORTE_AQUI",
  roles: [{ role: "readWrite", db: "meu_banco" }]
})

exit

A connection string que você vai usar no backend será: mongodb://meu_usuario:[email protected]:27017/meu_banco?authSource=meu_banco. Note que o host é sempre 127.0.0.1, nunca o IP público do servidor.

Passo 4 - Build e deploy do backend .NET Core

Na sua máquina local, dentro do projeto .NET, faça o build de publicação:

# Na maquina local
dotnet publish --configuration Release --output ./publish

Comprime e envia para o servidor:

# Na maquina local
tar -czf api.tar.gz -C ./publish .
scp api.tar.gz deploy@SEU_IP:/tmp/

# No servidor
sudo mkdir -p /opt/meu-projeto-api
sudo tar -xzf /tmp/api.tar.gz -C /opt/meu-projeto-api/

O appsettings.Production.json com as credenciais do banco deve ser enviado separadamente via SCP, nunca commitado no Git. Adicione ao .gitignore antes do primeiro commit:

# .gitignore  -  adicione isso
appsettings.json
appsettings.*.json
**/bin/
**/obj/
**/publish/

Envie o arquivo de configuração de produção separadamente:

scp appsettings.Production.json deploy@SEU_IP:/opt/meu-projeto-api/

Agora configure o systemd para manter a API rodando automaticamente:

# No servidor: crie o arquivo de servico
sudo nano /etc/systemd/system/meu-projeto.service

[Unit]
Description=Meu Projeto API .NET Core
After=network.target

[Service]
WorkingDirectory=/opt/meu-projeto-api
ExecStart=/usr/bin/dotnet /opt/meu-projeto-api/MeuProjeto.dll
Restart=always
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=meu-projeto
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=ASPNETCORE_URLS=http://127.0.0.1:5000

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable meu-projeto
sudo systemctl start meu-projeto
sudo systemctl status meu-projeto

Teste que a API está respondendo localmente:

curl http://127.0.0.1:5000/health

Passo 5 - Build e deploy do frontend Angular

Na máquina local, faça o build de produção do Angular:

# Na maquina local
ng build --configuration production

O Angular 17 em diante gera os arquivos em dist/nome-do-projeto/browser/. Comprime e envia:

# Na maquina local
tar -czf frontend.tar.gz -C dist/nome-do-projeto/browser .
scp frontend.tar.gz deploy@SEU_IP:/tmp/

# No servidor
sudo mkdir -p /var/www/meu-projeto
sudo find /var/www/meu-projeto -mindepth 1 -delete
sudo tar -xzf /tmp/frontend.tar.gz -C /var/www/meu-projeto/
sudo chown -R www-data:www-data /var/www/meu-projeto

Verifique que o index.html está no lugar:

ls /var/www/meu-projeto/index.html

Passo 6 - Configurando o NGINX

Crie os virtual hosts para o frontend e para a API. O NGINX vai servir os arquivos estáticos do Angular e fazer proxy reverso para a API .NET Core:

sudo nano /etc/nginx/sites-available/SEU_DOMINIO

server {
    listen 80;
    server_name SEU_DOMINIO.com.br www.SEU_DOMINIO.com.br;

    root /var/www/meu-projeto;
    index index.html;

    # SPA fallback  -  redireciona tudo para o index.html do Angular
    location / {
        try_files $uri $uri/ /index.html;
    }

    # Cache para assets estaticos
    location ~* .(js|css|png|jpg|ico|woff2)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}

server {
    listen 80;
    server_name api.SEU_DOMINIO.com.br;

    location / {
        proxy_pass http://127.0.0.1:5000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection keep-alive;
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

sudo ln -s /etc/nginx/sites-available/SEU_DOMINIO /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

O try_files $uri $uri/ /index.html é essencial para SPAs Angular. Sem essa linha, qualquer rota como /dashboard que o usuário acessar diretamente vai retornar 404 do NGINX.

Passo 7 - SSL com Let's Encrypt (HTTPS gratuito)

Com os domínios apontando para o IP do servidor (aguarde a propagação do DNS, pode levar até 24 horas), instale os certificados:

sudo certbot --nginx -d SEU_DOMINIO.com.br -d www.SEU_DOMINIO.com.br -d api.SEU_DOMINIO.com.br

O Certbot vai detectar automaticamente os virtual hosts do NGINX, instalar os certificados e configurar o redirect HTTP para HTTPS. A renovação automática já fica configurada via systemd timer - você não precisa fazer nada. Para verificar:

sudo certbot renew --dry-run

Testando o sistema completo

Com tudo configurado, faça os testes finais:

# Verificar HTTPS do frontend
curl -s -o /dev/null -w "%{http_code}" https://SEU_DOMINIO.com.br/
# Esperado: 200

# Verificar HTTPS da API
curl -s -o /dev/null -w "%{http_code}" https://api.SEU_DOMINIO.com.br/health
# Esperado: 200

# Ver logs da API em tempo real
sudo journalctl -fu meu-projeto

Se algo não estiver funcionando, os logs do NGINX e do systemd são seus melhores amigos:

# Logs do NGINX
sudo tail -f /var/log/nginx/error.log

# Logs da API
sudo journalctl -fu meu-projeto --since "5 minutes ago"

# Status dos servicos
sudo systemctl status nginx
sudo systemctl status mongod
sudo systemctl status meu-projeto

Parabéns - se chegou até aqui com todos os 200, seu sistema está no ar com HTTPS, banco de dados seguro e API rodando como serviço gerenciado pelo Linux. Agora você tem um ambiente de produção de verdade, com as mesmas práticas que empresas usam em sistemas reais.

Se ainda não tem um servidor, aproveita o link com desconto para contratar o VPS na Hostinger: Acesse a Hostinger com desconto especial pelo CuritibaBlog.