CI/CD na sua própria VPS

Um servidor próprio para builds compensa quando os minutos da nuvem não bastam, os builds são lentos ou é preciso acessar recursos internos. Mas o runner executa qualquer código do repositório, e um erro na configuração dele abre o acesso ao servidor de produção e a todos os segredos. Veja como funcionam os runners do GitLab e do GitHub, de quantos recursos eles precisam, como fazer deploy por SSH e onde guardar as chaves.

Atualizado 07.11.2026 · Encontre um VPS sob medida →

CI/CD é o build, o teste e a publicação automáticos do código a cada alteração. A descrição do pipeline fica no repositório (.gitlab-ci.yml ou os arquivos em .github/workflows/), e quem a executa é o runner, um programa que pega os jobs do GitLab ou do GitHub e os roda. O runner pode ser o do próprio serviço ou um instalado na sua VPS.

Runners próprios: GitLab e GitHub

O GitLab Runner é instalado a partir do repositório oficial (instruções de instalação) e registrado no projeto ou no grupo com um token das configurações de CI/CD. A escolha principal no registro é o executor. O shell roda os comandos direto no sistema do servidor; o docker, num contêiner novo para cada job. Segundo a documentação do GitLab, o shell não oferece um ambiente limpo para cada build, e os jobs enxergam todo o sistema de arquivos, inclusive o token do runner e o cache de outros projetos. Para a maioria dos projetos, o executor docker é o indicado.

O runner próprio do GitHub Actions é adicionado nas configurações do repositório ou da organização (documentação do GitHub). O uso é gratuito: você paga só o servidor. O runner se conecta sozinho ao GitHub por HTTPS na porta 443, então não é preciso abrir portas de entrada no servidor. Se o runner ficar 30 dias sem atualização, o GitHub deixa de lhe enviar jobs (referência sobre runners próprios).

Uma restrição importante para projetos abertos. O GitHub diz que runners próprios quase nunca devem ser usados com repositórios públicos: qualquer pessoa pode abrir um pull request e executar o próprio código no servidor. Para código público, fique com os runners da nuvem e conecte o seu servidor a repositórios privados.

Por que o build e a produção devem ficar em servidores diferentes

  • Carga. O build do front-end ou uma compilação ocupa todos os núcleos por minutos. Se o runner está no servidor do site, o site responde mais devagar nesse tempo.
  • Segurança. O runner executa código de qualquer branch, inclusive de uma enviada por um prestador de serviço. Segundo a documentação do GitLab, o executor shell traz risco alto para o servidor e para a rede, e um contêiner em modo privileged dá ao job root completo no servidor. Se no mesmo servidor roda um site com a base de clientes, ela fica ao alcance de qualquer job.
  • Espaço em disco. Imagens Docker, cache de dependências e artefatos ocupam dezenas de gigabytes. Quando o disco enche, para não só o build, mas também o site.

Um esquema para uma equipe pequena: uma VPS para o runner, outra para o site em produção e, se preciso, uma terceira para o ambiente de testes (sobre ele, o artigo VPS para desenvolvedores: ambientes de teste). O runner entrega ao servidor de produção só o resultado pronto.

Quantos recursos o build precisa

A referência são os runners de nuvem do GitHub. Segundo a referência dele, o runner Linux padrão para repositórios privados tem 2 núcleos, 8 GB de memória e 14 GB de SSD; para repositórios públicos, 4 núcleos e 16 GB. Se os seus builds cabem nesses recursos, uma VPS igual dá conta tão bem quanto, e com disco rápido e cache preservado costuma ser mais rápida.

  • Núcleos. Um build com compilação e testes em paralelo usa todos os núcleos. Se os builds rodam um atrás do outro, 4 núcleos encurtam bem a fila em comparação com dois.
  • Memória. O build do front-end, a compilação de Java ou Go e os testes com banco de dados num contêiner pedem 4–8 GB por job. O número de jobs simultâneos é definido pelo parâmetro concurrent no config.toml do GitLab Runner (descrição dos parâmetros); multiplique a memória de um job por esse número.
  • Disco. Instalar dependências significa milhares de arquivos pequenos, e no NVMe isso anda mais rápido. Contrate a partir de 50 GB e limpe o cache do Docker periodicamente: docker builder prune e docker image prune. Por que o disco importa está no artigo NVMe ou SSD: faz diferença para um site?
  • Virtualização. O executor docker precisa de KVM: no OpenVZ, o Docker funciona com limitações ou não funciona (KVM ou OpenVZ: o que escolher).

Pelo catálogo da accsly.io em novembro de 2026, um plano de VPS com 2 núcleos e 4 GB de memória custa na mediana US$ 21 por mês, e um quarto desses planos sai por menos de US$ 12,50. Com 4 núcleos e 8 GB, US$ 40, e um quarto custa menos de US$ 22. Com 8 núcleos e 16 GB, US$ 80. Os preços estão em rublos no catálogo; aqui foram convertidos pelo câmbio de 7 de novembro de 2026 e arredondados. Planos adequados estão nas seleções VPS para runners de CI/CD e VPS para GitLab, se você instala também o próprio GitLab.

Servidor de build cobrado por hora

O runner só é necessário enquanto há builds, normalmente algumas horas por dia útil. Pelo catálogo da accsly.io em novembro de 2026, 173 dos 2.248 provedores com planos de VPS oferecem cobrança por hora, 298 têm API para criar e apagar servidores, e 96 têm as duas coisas. Um plano com 4 núcleos e 8 GB nos provedores com cobrança por hora custa na mediana US$ 51 por mês, cerca de US$ 0,07 por hora. Um servidor que funciona 3 horas em cada um dos 22 dias úteis sai por uns US$ 4,60 em vez do preço do mês.

Para que isso funcione sem trabalho manual, o servidor é criado pela API antes do build e apagado depois. O GitLab Runner sabe escalar assim com plugins para nuvens, e o GitHub recomenda runners efêmeros (ephemeral), que pegam um único job e são removidos. Há um ganho de segurança: o job seguinte não vê rastros do anterior. Quando a cobrança por hora compensa mais que a mensal está no artigo Cobrança por hora: quando ela compensa; os planos, nas seleções VPS com cobrança por hora e VPS com API.

Deploy por SSH com uma chave restrita

O jeito mais simples de levar o build ao servidor de produção é o SSH: rsync dos arquivos ou um comando que baixa a nova versão e reinicia o serviço. Para que a chave do CI não vire a chave do servidor inteiro:

  1. Um usuário à parte. Crie um usuário deploy sem sudo, com permissão só no diretório do site. Se for preciso reiniciar um serviço, libere no sudoers um único comando específico.
  2. Uma chave à parte. Gere um par de chaves só para o CI e não o use em nenhum outro lugar.
  3. Restrições no authorized_keys. Antes da chave, acrescente restrict, que proíbe encaminhamento de portas e terminal, e from="endereço do runner", para que a chave só funcione a partir do servidor de build. O parâmetro command="…" permite que a chave execute apenas um script de deploy (man authorized_keys).
  4. Verificação do servidor. Guarde a impressão digital da chave do servidor de produção numa variável do CI e grave-a no known_hosts antes de conectar. Desativar a verificação com StrictHostKeyChecking=no não é aceitável: assim o runner se conecta a qualquer servidor que se passe pelo seu.

Para que o site não pare durante o deploy, a nova versão é iniciada ao lado da antiga e o tráfego é trocado quando ela passa na verificação de saúde; a versão anterior fica disponível para reverter. Como montar isso em um único servidor está explicado em Atualização do servidor sem tempo fora do ar.

A proteção básica do próprio servidor de produção, com login só por chave, firewall e fail2ban, está no artigo Primeiros 10 passos depois de comprar uma VPS. Os registros de login da chave de deploy ajudam a entender o que houve se algo der errado; onde encontrá-los está no artigo Logs e auditoria de acessos no servidor.

Onde guardar os segredos

  • Fora do repositório. Senhas do banco de dados, tokens de API e chaves de deploy ficam nas variáveis do CI. No GitLab, a variável pode ser protegida, disponível só para pipelines de branches e tags protegidas, e mascarada, quando o valor aparece como [MASKED] no log do job. Um valor mascarado precisa ser uma única linha, sem espaços, com pelo menos 8 caracteres (documentação do GitLab).
  • Um valor por segredo. O GitHub avisa que um segredo em forma de JSON ou YAML é mascarado pior nos logs; guarde cada valor separadamente e não imprima segredos no log do build.
  • Segredos diferentes para o ambiente de testes e para a produção. A chave de deploy para produção deve estar disponível só para a branch protegida, e não para qualquer branch de desenvolvedor.
  • Tokens de vida curta em vez de permanentes. Para serviços de nuvem, o GitHub recomenda OpenID Connect: o job recebe um token válido durante o build, e não é preciso guardar uma chave permanente.
  • Rotação. Troque as chaves quando sair da equipe alguém com acesso às configurações do CI e depois de qualquer vazamento de log de build.

O arquivo .env com as configurações de produção é criado no servidor uma única vez, com permissão 600, e o deploy não o sobrescreve. Assim, nem uma cópia completa do repositório contém as senhas do banco de produção.

Perguntas frequentes

Quanto custa um runner próprio do GitHub Actions?

O GitHub não cobra pelos runners próprios; você paga só o servidor. Pelo catálogo da accsly.io em novembro de 2026, uma VPS com 2 núcleos e 4 GB de memória custa na mediana US$ 21 por mês, e com 4 núcleos e 8 GB, US$ 40.

Posso instalar o runner no mesmo servidor em que roda o site?

Tecnicamente pode, mas não vale a pena: o build tira núcleos do site, enche o disco, e um job com código malicioso ganha acesso ao banco e aos segredos. É melhor manter o runner numa VPS separada.

Qual executor do GitLab Runner escolher?

Para a maioria dos projetos, o docker: cada job recebe um contêiner limpo. O executor shell roda os comandos direto no sistema, e os jobs enxergam o token do runner e arquivos alheios. Ative o modo privileged só num servidor isolado.

Quantos recursos um servidor de build precisa?

A referência é o runner de nuvem do GitHub para repositórios privados: 2 núcleos e 8 GB de memória. Para vários jobs simultâneos, multiplique a memória pelo número deles; o disco, a partir de 50 GB em NVMe, com limpeza do cache do Docker.

Como fazer deploy por SSH a partir do CI com segurança?

Um usuário à parte sem sudo, uma chave só para o CI com as restrições restrict e from= no authorized_keys e verificação da chave do servidor via known_hosts. Guarde a chave numa variável protegida do CI.

A cobrança por hora compensa para um servidor de build?

Sim, se o servidor é criado pela API antes dos builds e apagado depois. Um servidor com 4 núcleos e 8 GB que funciona 3 horas por dia útil custa uns US$ 4,60 por mês, em vez de US$ 51 funcionando o tempo todo.

Mais no guia

  • Hospedagem para site de empresa e e-mail no domínioO site de uma empresa raramente tem muito tráfego, mas vem acompanhado do e-mail dos funcionários no domínio, de formulários de contato com dados pessoais e de uma contabilidade que precisa de fatura e nota fiscal. A hospedagem compartilhada resolve tudo isso num só plano, se você conferir antes os limites de e-mail, configurar SPF, DKIM e DMARC e escolher um provedor que trabalhe com empresas. Abaixo está o que observar e quanto isso custa.
  • Hospedagem para landing page e site institucionalUma landing page ou um site institucional não precisa de servidor potente nem de VPS: basta o plano mais simples de hospedagem compartilhada, por poucos dólares por mês. Importa mais outra coisa: que o plano tenha SSL gratuito, que o domínio continue seu e que a página abra rápido no celular. Abaixo está como escolher o plano, o que conferir nele e quanto ele custa.
  • Como escolher hospedagem para uma loja virtualPara uma loja pequena em WooCommerce, OpenCart ou 1C-Bitrix, um bom plano de hospedagem compartilhada basta. Mas as exigências são mais rígidas que as de um site institucional: versões recentes de PHP e do banco de dados, HTTPS em todas as páginas, folga nos limites para as liquidações e backups dos quais dá para recuperar os pedidos rapidamente. Abaixo está o que conferir no plano, quanto ele custa e quando é hora de migrar para uma VPS.
  • Banco de dados numa VPS: PostgreSQL ou MySQLUm banco de dados quase sempre esbarra não no processador, mas na memória e no disco. Se o conjunto de dados em uso cabe no cache, as consultas são rápidas mesmo num servidor barato; se não cabe, quem decide tudo é a velocidade do disco. Veja como escolher entre PostgreSQL e MySQL, quanta memória dar ao banco, que disco contratar e como não perder dados.
  • Armazenamento de arquivos numa VPS: discos e armazenamento de objetosOs arquivos de um projeto (uploads de usuários, fotos de produtos, vídeos, documentos, arquivos compactados) crescem mais rápido que o banco de dados e o código. Eles podem ficar no disco do servidor, num volume separado ou num armazenamento de objetos, e dessa escolha dependem o preço do terabyte, a velocidade e o que acontece com os arquivos quando você troca de servidor. Veja as opções e os preços pelo catálogo da accsly.io.
  • Como sair de um provedor sem perdasOs motivos para deixar um provedor variam: os preços subiram, o servidor ficou lento, o suporte não responde, é preciso outro país. Numa mudança dá para perder dados, e-mails, o domínio e o dinheiro dos meses já pagos. Veja uma ordem de passos em que o servidor antigo e o novo funcionam em paralelo por um tempo e desligar o antigo não quebra nada.
  • Logs e auditoria de acessos no servidorOs logs respondem a três perguntas: o que quebrou, quem entrou no servidor e o que fez lá. A resposta só existe se os logs estiverem ativados, forem guardados por tempo suficiente e não ficarem apenas no mesmo servidor que pode ter sido invadido. Veja onde encontrá-los no Linux, quais comandos mostram os acessos, como configurar a rotação e o que fazer com antecedência para ter o que analisar depois de um incidente.
  • VPS para desenvolvedores: ambientes de testeO ambiente de testes existe para que o erro seja encontrado por você, e não pelos clientes. Ele deve ser parecido com a produção em software e configurações, mas pode ter metade dos recursos e durar poucos dias. Veja como deixar o ambiente barato, como manter várias versões num mesmo servidor e como evitar que a cópia do site apareça nos buscadores ou mande e-mails para clientes de verdade.
  • Distribuições Linux para servidor: Ubuntu, Debian, AlmaLinuxPara um servidor, a escolha costuma ficar entre três distribuições gratuitas: Ubuntu, Debian e AlmaLinux. As três são estáveis e servem para um site ou um bot; diferem no prazo de suporte, nos pacotes e em quais painéis e programas rodam oficialmente nelas. Pelo catálogo da accsly.io (novembro de 2026), as três imagens estão disponíveis em 631 dos 1.241 provedores cuja lista de templates é conhecida.
  • Teste de carga do site antes do lançamentoO teste de carga responde quantos visitantes o site aguenta no servidor escolhido e o que quebra primeiro. Ele é feito no seu próprio servidor e só nele: o gerador de carga roda em outra máquina, o provedor é avisado e os serviços externos são substituídos por stubs. Veja quais números acompanhar, com quais programas obtê-los e como usá-los para escolher o plano.
  • Atualização do servidor sem tempo fora do arUm servidor não pode ficar sem atualizações, mas cada atualização traz o risco de derrubar o site. Esse risco se controla com processo: as pequenas correções de segurança são instaladas automaticamente, as grandes mudanças seguem um plano com snapshot, verificação e rollback pronto, e as reinicializações ficam concentradas na janela de manutenção. Veja como organizar isso numa única VPS.
  • CDN: quando um site precisa de umaA CDN guarda cópias dos arquivos do site em servidores pelo mundo todo e as entrega ao visitante a partir do mais próximo. Isso acelera o carregamento de imagens, scripts e vídeos e tira carga do seu servidor, mas não torna mais rápido um CMS lento nem substitui a escolha certa do país do servidor. Veja em quais casos a CDN é realmente necessária e quando basta uma única VPS no lugar certo.
  • Domínios e DNS para quem tem servidorO servidor pode ser trocado em uma noite, mas o domínio fica com o projeto por anos. Pelo DNS, o domínio aponta para o servidor, o e-mail e serviços de terceiros, e um único registro errado derruba o site ou manda as mensagens para o spam. Veja os registros de que o dono de uma VPS vai precisar, como funciona o cache, onde manter a zona e como migrar para um servidor novo sem que os visitantes percebam.
  • Certificados SSL: gratuitos e pagosUm certificado gratuito criptografa a conexão com a mesma segurança que um pago: o navegador não os diferencia pelo nível de proteção. A diferença está no que a autoridade certificadora verifica, em quanto tempo o certificado vale e em quem cuida da renovação. Segundo o catálogo da accsly.io (novembro de 2026), o SSL gratuito aparece de forma explícita em 1.449 planos de hospedagem compartilhada de 178 provedores. Veja quando isso basta e quando vale a pena comprar um certificado.
  • 152-FZ e hospedagem: onde guardar os dadosSe um site ou serviço coleta dados pessoais de cidadãos da Rússia, o registro e a guarda desses dados devem ser feitos em bancos de dados no território russo: é o que diz a parte 5 do artigo 18 da Lei Federal nº 152-FZ. Para a escolha de uma VPS, isso significa que importa o país do data center, não o do provedor, e que cópias no exterior já seguem regras próprias. Veja o que a lei exige, que obrigações recaem sobre o dono do servidor e quais esquemas se usam na prática.
  • GDPR e a escolha de hospedagemO Regulamento Geral sobre a Proteção de Dados da UE (GDPR, ou RGPD) não exige manter os dados na União Europeia, mas exige um contrato de tratamento de dados com o provedor e que a saída dos dados da UE siga um dos mecanismos legais. Segundo o catálogo da accsly.io (novembro de 2026), 61% dos provedores de VPS têm servidores na UE, mas quase metade deles está registrada fora do Espaço Econômico Europeu. Veja por que isso importa e o que conferir nas condições.
  • Jurisdição do provedor: o que ela defineTodo servidor tem dois países: aquele onde fica o data center e aquele onde está registrada a empresa que o aluga. Segundo o catálogo da accsly.io (novembro de 2026), em 15% dos provedores de VPS esses países são diferentes. Do primeiro dependem o ping e as exigências sobre onde guardar os dados; do segundo, a lei do contrato, o foro para disputas, os documentos para a contabilidade e quais autoridades podem pedir os dados. Veja o que cada um muda.
  • Como comparar preços de VPS: o preço por unidade de recursoO preço do plano responde à pergunta «quanto vou pagar», mas não a «quanto recebo por esse dinheiro». Segundo o catálogo da accsly.io (novembro de 2026), o gigabyte de memória num plano de 1 GB custa, na mediana, US$ 8,00 por mês, e num plano de 4 GB, US$ 5,00. Veja como calcular o preço por vCPU, por gigabyte de memória e de disco, e o que colocar na mesma base antes de comparar duas ofertas.
  • SLA e uptime: o que os provedores prometemUm SLA de 99,9% permite ao provedor 43 minutos de indisponibilidade por mês; um de 99,99%, cerca de quatro. Mas o percentual da propaganda ainda não é um compromisso: compromisso é o documento que diz o que conta como indisponibilidade, o que fica de fora e quanto você recebe de volta. Quase sempre é um desconto na próxima fatura, não dinheiro. Veja como ler esses documentos e como medir a disponibilidade por conta própria.
  • Período de teste e reembolsoHá duas formas de testar um servidor antes de pagar um mês ou um ano: um período de teste gratuito ou uma garantia de reembolso. Segundo o catálogo da accsly.io (novembro de 2026), 11% dos provedores de VPS oferecem teste, e 36% oferecem garantia de reembolso. Mas em muitos deles as condições valem só para hospedagem, só para o primeiro pedido ou só para pagamento com cartão. Veja o que conferir para que a garantia funcione de verdade.
  • Servidor em nuvem ou VPSUm servidor em nuvem e uma VPS costumam ser a mesma máquina virtual em KVM. A diferença está no que vem em volta: a nuvem vende recursos por hora via API e oferece discos em rede, snapshots e serviços prontos, enquanto a VPS clássica é um plano fixo por mês, com disco local e um pacote de tráfego. Veja do que você realmente precisa e quanto isso custa.
  • Servidor dedicado ou VPSUma VPS é uma parte de um servidor físico; um servidor dedicado é a máquina inteira. Com 4 núcleos e 8–16 GB de memória, a VPS custa quase a metade; com 4 núcleos e 32 GB, os preços se igualam; e com 64 GB em 8 núcleos ou 128 GB em 16 núcleos, o servidor dedicado sai um terço mais barato que o virtual no catálogo. Veja o que muda além do preço: vizinhos, garantias, prazos, falhas de hardware e gerenciamento remoto.
  • Hospedagem ou VPS para um siteA hospedagem compartilhada é um espaço pronto para o site, em que quem cuida do servidor é o provedor. A VPS é um servidor seu, em que você configura tudo. Para uma landing page e um site comum em WordPress, a hospedagem basta e custa várias vezes menos. A VPS é necessária quando os limites da conta não dão conta do site ou quando ele precisa de um programa que a hospedagem não permite. Abaixo está o que cada opção inclui, quanto custa e uma tabela para escolher.
  • Proteção contra DDoS: o que os provedores realmente oferecemHoje, metade dos provedores coloca «proteção contra DDoS» na descrição dos planos. Por trás dessa linha pode haver filtragem de vários terabits ou apenas o direito de desligar o seu endereço quando um ataque atrapalha os vizinhos. Vamos ver do que a proteção é feita, como os níveis L3/L4 e L7 se diferenciam e como entender pelo contrato o que você está comprando.
  • Servidor de e-mail em VPS: SPF, DKIM, DMARCInstalar o Postfix ou um pacote pronto como o Mailcow numa VPS leva uma hora. Fazer as mensagens chegarem à caixa de entrada, e não ao spam, é mais difícil: os serviços de e-mail olham a porta, o endereço do servidor, a reputação dele e três registros DNS. Vamos ver o que conferir no provedor antes da compra e como configurar SPF, DKIM e DMARC.
  • Monitoramento de servidor: uptime, carga e alertasSem monitoramento, você fica sabendo que o servidor caiu pelos visitantes, e que o disco está acabando quando o banco de dados para de gravar. Bastam algumas verificações de fora e uma dezena de métricas de dentro para ver o problema antes dos usuários. Vamos ver o que medir, onde colocar as verificações e como fazer isso de graça.
  • Como ler os planos de hospedagem: limites ocultosO card do plano mostra núcleos, memória, disco e preço mensal. Mas dois planos com os mesmos números podem custar valores diferentes já depois de um ano e se comportar de forma diferente sob carga. A diferença está nas condições escritas em letra miúda, nas regras de uso ou só no contrato. Abaixo estão oito pontos que vale conferir antes de pagar.
  • IPv4 e IPv6 no servidorUma VPS comum tem um endereço IPv4 público e, se o provedor oferece suporte, uma sub-rede IPv6. Um IPv4 adicional quase sempre custa dinheiro, e os planos mais baratos às vezes nem vêm com IPv4 próprio. Vamos ver de onde vem essa escassez, o que dá para fazer só com IPv6 e quais configurações de endereço um servidor de e-mail precisa.
  • Banda e tráfego: o que significam 1 Gbit/s e ilimitadoO plano de um servidor costuma ter duas linhas de rede: velocidade da porta e volume de tráfego. A primeira diz com que rapidez o servidor pode enviar dados; a segunda, quanto ele pode enviar por mês. As duas estão ligadas por uma aritmética simples, e, sabendo fazer a conta, fica fácil entender o que «1 Gbit/s ilimitado» realmente oferece e se «5 TB» bastam para você.
  • Docker em VPS: por onde começarCom o Docker, você roda no servidor um bot, um site, um banco de dados e o monitoramento sem que um atrapalhe o outro, e mudar para outra VPS se resume a copiar alguns arquivos e os dados. A instalação leva cinco minutos; os problemas de verdade aparecem depois: portas do banco abertas para a internet, logs de dezenas de gigabytes e dados que sumiram junto com o contêiner. Veja como evitá-los desde o início.
  • Como migrar um site da hospedagem para uma VPSA migração em si leva umas duas horas, e os erros costumam acontecer em volta dela: uma tarefa do cron esquecida, regras do .htaccess que o nginx não lê, um registro AAAA com o endereço antigo ou um e-mail que sumiu junto com a troca de IP. Abaixo, a ordem dos passos com comandos e verificações para um site em PHP e MySQL.
  • Painéis de controle de servidor: ISPmanager, FASTPANEL, aaPanelO painel transforma a VPS em algo parecido com o painel da hospedagem compartilhada: sites, bancos de dados, e-mail e certificados são criados com o mouse, e não editando arquivos de configuração. Os três painéis mais instalados em servidores russos e em servidores baratos no exterior são o ISPmanager, o FASTPANEL e o aaPanel. Eles diferem no preço, na memória que exigem e no quanto tomam conta do servidor.
  • VPS Windows para 1CUm servidor alugado para o 1C livra a empresa daquele computador debaixo da mesa do escritório que ninguém atualiza nem copia. Mas o 1C em VPS tem particularidades: a licença de software fica vinculada aos parâmetros da máquina virtual, os usuários precisam de licenças tanto do 1C quanto do Windows, e a frequência dos núcleos importa mais que a quantidade. Veja como montar um servidor para o 1C numa empresa pequena.
  • VPS Windows: licenciamento, RDP e acesso seguroUm servidor Windows custa mais que um Linux não só por causa da memória: o preço inclui uma licença, e a forma como ela é contratada define se o uso está regular e quantas pessoas podem se conectar. Uma porta RDP exposta também é o caminho mais comum para invadir esses servidores. Veja os dois temas.
  • Quando migrar da hospedagem compartilhada para uma VPSUma VPS não deixa o site mais rápido por si só: ela dá recursos e liberdade e, junto com eles, o trabalho de administrar um servidor. Veja como saber que a hospedagem ficou pequena, quando o problema se resolve sem mudança e como migrar um site sem que os visitantes percebam.
  • Backups de VPS: estratégias e ferramentasNuma VPS, os backups são responsabilidade sua, mesmo que o plano diga «backups incluídos». Vamos ver o que exatamente copiar, por que o snapshot do provedor não basta, como configurar o restic ou o BorgBackup em meia hora e como ter certeza de que dá mesmo para restaurar a partir da cópia.
  • Primeiros 10 passos depois de comprar uma VPS: segurançaTentativas de adivinhar a senha de um servidor novo começam poucos minutos depois que ele ganha um IP público. Abaixo estão dez passos que, em uma hora, fecham as brechas mais comuns: comandos para Ubuntu e Debian, as diferenças para AlmaLinux e Rocky Linux e as verificações sem as quais é fácil perder o acesso ao seu próprio servidor.
  • Como escolher o país do servidorColoque o servidor onde estão os seus visitantes. Para um público no Brasil, São Paulo dá o menor ping; Miami e a costa leste dos EUA são a alternativa comum, e a Europa fica bem mais longe. A LGPD não obriga a manter os dados no Brasil, mas a transferência para fora precisa de base legal. O preço quase não decide: no mesmo provedor, Europa e EUA costumam custar o mesmo, e só Ásia e Austrália saem bem mais caras.
  • Cobrança por hora: quando ela compensaA cobrança por hora compensa se você precisa do servidor menos de três semanas por mês: para um teste, um build, uma tarefa pesada pontual. Na maioria dos provedores, a hora custa exatamente o preço mensal dividido por 730 horas, então num mês cheio você quase não paga a mais. O custo extra está em outro lugar: os planos com cobrança por hora são, em média, mais caros, e para um servidor que roda o ano inteiro o plano mensal ou anual costuma sair mais barato.
  • Quanta memória e quantos núcleos um site precisaA maioria dos sites roda bem com 2 GB de memória e um ou dois núcleos; uma loja com milhares de produtos precisa de 4 GB e dois núcleos. Memória importa mais que núcleos: quando ela falta, o site fica lento ou cai, e um núcleo a mais sem memória quase não ajuda. Abaixo mostro como calcular a memória para o seu site e como descobrir quanto ele gasta de verdade.
  • KVM ou OpenVZ: o que escolherEm 2026 quase sempre vale escolher KVM: ele custa no máximo uns dois dólares por mês a mais que o OpenVZ, mas nele tudo funciona, do Docker ao Windows. O OpenVZ só se justifica num caso estreito, e abaixo você vê qual; no final estão os comandos para conferir o seu servidor em um minuto.
  • NVMe ou SSD: faz diferença para um site?Para um site pequeno, a diferença entre NVMe e SSD é quase imperceptível: as páginas saem da memória, não do disco. Ela aparece em lojas virtuais e sites com banco de dados grande. E no mesmo provedor o NVMe custa só uns US$ 0,50–1 por mês a mais, às vezes até menos que o SSD, então o que decide normalmente não é o tipo de disco, e sim o tamanho e como o provedor o limitou.
  • O que é VPS, explicado de forma simplesUma VPS é um pedaço de um servidor físico potente que você aluga e que se comporta como um computador independente: com sistema próprio, endereço IP próprio e acesso total. Veja como ela se diferencia da hospedagem, para quem serve, quanto custa e o que conferir logo depois da contratação.
  • VPS para bot do Telegram: do que o bot precisa e como escolher o planoUm bot com menu e alguns comandos roda bem no servidor mais barato, enquanto um bot com disparos, arquivos e banco de dados esbarra em limites totalmente diferentes. Veja o que um bot realmente consome, quais limites do Telegram definem a escolha do servidor e como não pagar a mais.
  • Como testar ping e velocidade de uma VPS antes de pagarOs números de um plano não dizem qual será a latência até seus usuários nem a velocidade real do disco. Quase tudo pode ser medido antes de pagar, e o resto na primeira hora depois de ligar o servidor. Veja as ferramentas e como interpretar os resultados.
  • Rede corporativa em VPS: acesso remoto ao escritórioUm servidor alugado pode virar o centro da rede privada de uma empresa: funcionários remotos e filiais se conectam por ele ao ERP, ao servidor de arquivos, ao CRM e ao Git. Veja os esquemas mais comuns, os protocolos, os requisitos do servidor e o básico de segurança.
  • Como escolher uma VPS: os 7 parâmetros que decidemDois planos com os mesmos «2 núcleos, 4 GB, 50 GB» podem ter velocidade várias vezes diferente e custar o dobro um ano depois. Veja o que existe por trás de cada linha de um plano VPS e o que conferir antes de pagar.
  • VPS ou VDS: existe diferença e o que realmente importaNa maioria dos mercados, VPS e VDS significam a mesma coisa: um servidor virtual. A diferença que de fato afeta o seu trabalho não está no nome, e sim no tipo de virtualização e em os recursos serem garantidos ou não.