Linux ou Windows para servidor de RedM: qual vale mais a pena em 2026?
Comparação para servidores RedM: consumo de recursos, compatibilidade com VORP e RSG, tamanho típico de cidade e o sistema ideal para cada perfil.
O RedM herda quase tudo do FiveM, inclusive os artifacts. E herda também a discussão sobre Linux e Windows, com um agravante próprio: a comunidade de RedM é bem menor.
Isso muda a conta de um jeito que ninguém costuma mencionar. Quando você trava num problema de Linux em FiveM, existe um fórum inteiro com a resposta pronta. Em RedM, muitas vezes você é a primeira pessoa a documentar aquele erro específico com VORP.
Esse fator, sozinho, já inclina a recomendação para quem está começando. Mas não elimina as vantagens técnicas do Linux, que continuam reais. Este guia separa as duas coisas.
O que RedM tem de particular
Antes da comparação, três características que mudam a decisão em relação ao FiveM.
Os artifacts são os mesmos. O RedM roda sobre o mesmo FXServer do FiveM. Você
baixa da mesma página de builds e vai ver fivem no endereço. Isso significa que
tudo que vale para um vale para o outro em termos de sistema operacional.
As cidades costumam ser menores. Roleplay de velho oeste é um nicho, e a maioria dos servidores opera com trinta a oitenta jogadores, não com trezentos. Nessa faixa, a folga de recurso do Linux é menos decisiva.
O mapa é gigante e o streaming pesa. O mapa do Red Dead Redemption 2 é enorme, e servidores com muitos assets customizados consomem bastante memória. Aqui o Linux ganha relevância de volta.
Comparação item a item
Facilidade de administração
Windows vence, e em RedM a margem é maior.
O motivo não é técnico, é de ecossistema. Com interface gráfica você resolve sozinho olhando a tela. No Linux, quando trava, você depende de encontrar quem já passou pelo mesmo, e em RedM esse alguém é mais raro.
Some a isso que boa parte dos tutoriais de VORP e das bases prontas foi escrita supondo Windows, e a diferença de atrito fica clara.
Performance
Linux vence.
O FXServer concentra a lógica do jogo num processo principal, e o que o jogador sente como travamento é a queda do tick rate desse processo. Menos disputa por processador significa tick mais estável.
Na prática, em cidade de quarenta pessoas a diferença é sutil. Ela começa a aparecer acima de cem, ou quando a base tem muitos scripts rodando em paralelo.
Consumo de memória
Linux vence, e este é o argumento mais forte a favor dele no RedM.
| Situação | Windows Server | Linux sem interface |
|---|---|---|
| Sistema em repouso | 1,5 a 2 GB | 200 a 400 MB |
| Sobra num plano de 4 GB | ~2 GB | ~3,6 GB |
Por que isso importa especialmente aqui: servidores de RedM costumam carregar bastante conteúdo customizado, de roupas de época a propriedades e interiores. O streaming desses assets ocupa memória, e a folga de 1 GB deixa de ser detalhe.
Estabilidade
Ligeira vantagem para o Linux.
Principalmente por não sofrer reinício automático de atualização do Windows, que é um problema real em servidor de roleplay: derrubar a cidade às 3h da manhã no meio de uma trama em andamento gera reclamação legítima.
A ressalva vale sempre: estabilidade depende muito mais dos seus resources que do sistema. Vazamento de memória em script derruba os dois.
Compatibilidade com VORP Core
Empate. VORP roda em Linux sem problema.
O VORP é um conjunto de resources em Lua com banco MySQL, e nada nele depende de sistema operacional. O mesmo vale para RSG Core e RedEM:RP.
O que quebra em migração raramente é o framework. É o acúmulo de scripts de terceiros, e quase sempre pelo mesmo motivo descrito a seguir.
O detalhe que mais quebra migração
Sensibilidade a maiúsculas.
O Windows trata Config.lua e config.lua como o mesmo arquivo. O Linux não. Um
fxmanifest.lua que declara Client/main.lua quando o arquivo real é
client/main.lua funciona no Windows e falha no Linux.
Em bases de RedM montadas ao longo do tempo, com scripts de várias origens, esse é o problema número um.
Boas práticas para evitar:
- Use sempre minúsculas em nome de arquivo e pasta
- Referencie caminho com
/, nunca com\ - Declare todos os arquivos no
fxmanifest.luacom a grafia exata - Ao baixar script de terceiro, confira a grafia antes de subir
Compatibilidade com txAdmin
Empate. O txAdmin vem junto dos artifacts, é multiplataforma e funciona igual. O recipe de instalação, o console ao vivo e o agendamento de reinício funcionam nos dois.
A diferença é como o processo é iniciado. No Windows você executa o FXServer.exe.
No Linux você roda o run.sh sob um gerenciador como systemd, screen ou
tmux, para ele continuar rodando depois que o SSH fechar.
Se ainda não usa, o caminho está em como criar um servidor de RedM do zero.
Segurança
Empate técnico, vantagem prática para o Linux por ter menos serviço exposto por padrão.
O maior risco nos dois é o mesmo: acesso remoto com senha fraca. Servidor de RedM tem IP público e recebe tentativa automatizada diariamente, mesmo sendo pequeno.
No Windows, troque a porta do RDP conforme como trocar a porta RDP da sua VPS. No Linux, faça o mesmo com SSH em como alterar a porta do SSH.
E nunca exponha a porta do txAdmin sem necessidade. Mais em como proteger o servidor de RedM contra DDoS.
Atualizações
Linux vence pela previsibilidade. Você atualiza quando quer, com um comando, e raramente precisa reiniciar.
No Windows, além das atualizações pedirem reinício, existe a renovação periódica da licença do Windows Server, descrita em como ativar o Windows na sua VPS.
Custos
Linux vence, com margem menor do que parece.
A licença do Windows costuma vir embutida no preço da VPS. O custo real inclui também o recurso desperdiçado e, principalmente em RedM, o seu tempo: com menos documentação disponível, cada problema no Linux tende a demorar mais para resolver.
Para cidade pequena, a diferença total é pequena. Para cidade grande, a eficiência do Linux compensa.
Tabela comparativa
| Critério | Windows | Linux |
|---|---|---|
| Facilidade de administração | Alta | Baixa |
| Documentação para RedM | Farta | Escassa |
| Performance e tick rate | Boa | Melhor |
| RAM do sistema | 1,5 a 2 GB | 200 a 400 MB |
| Estabilidade | Boa | Ligeiramente melhor |
| VORP, RSG, RedEM:RP | Compatível | Compatível |
| txAdmin | Compatível | Compatível |
| Sensibilidade a maiúsculas | Não | Sim, exige cuidado |
| Segurança padrão | Boa, ajustar RDP | Boa, menos exposição |
| Custo de licença | Embutido | Nenhum |
| Automação de rotina | Limitada | Excelente |
Vantagens e desvantagens, resumidas
Windows
Vantagens: interface gráfica, diagnóstico visual, compatibilidade sem armadilha de grafia, maioria dos tutoriais de RedM escritos para ele, curva curta.
Desvantagens: consome mais de 1 GB de RAM só de sistema, atualizações pedem reinício, automação limitada, licença embutida no custo.
Linux
Vantagens: consumo mínimo de recursos, tick rate mais estável sob carga,
atualizações previsíveis, automação de backup e reinício via cron e systemd,
sem custo de licença.
Desvantagens: tudo por terminal, sensibilidade a maiúsculas quebra scripts de terceiros, documentação específica de RedM escassa, curva de aprendizado real.
Para qual perfil cada sistema é indicado
Primeiro servidor de RedM
Windows. A escassez de material específico de RedM em Linux pesa muito no começo. Você vai gastar mais tempo procurando resposta do que resolvendo.
Cidade pequena de roleplay, até 64 jogadores
Windows resolve bem. É a faixa mais comum em RedM, e a folga do Linux não é decisiva. Escolha pelo conforto.
Cidade em crescimento, 64 a 128 jogadores
Momento de avaliar. Com muitos assets customizados carregados, a memória aperta. Antes de subir de plano, teste se o Linux resolve na configuração atual.
Cidade grande, acima de 128 jogadores
Linux. Nesse tamanho, cada GB economizado é jogador que cabe, e a automação deixa de ser luxo.
Você tem equipe de staff
Linux, se houver alguém que domine. Acesso limitado por usuário e registro do que cada um fez valem muito num servidor de roleplay com vários administradores.
Erros comuns
Migrar esperando conserto de travamento. Se o problema é script pesado, ele vai junto.
Ignorar a grafia dos arquivos. É a causa número um de resource que para de funcionar ao migrar.
Migrar direto em produção. Monte em paralelo e só aponte o endereço quando estiver funcionando.
Rodar o FXServer como root. Nunca. Crie usuário sem privilégio administrativo.
Esquecer o gerenciador de sessão. Sem systemd, screen ou tmux, o
servidor morre quando o SSH cair.
Assumir que tutorial de FiveM serve igual. Na maior parte serve, porque a base é a mesma, mas confira antes de aplicar comando encontrado em fórum de FiveM.
Dicas avançadas
Use systemd. Ele reinicia o servidor se o processo morrer e sobe junto com a máquina, o que resolve boa parte das quedas noturnas.
Padronize a grafia antes de migrar. Renomeie tudo para minúsculas ainda no Windows, teste, e só depois migre. Assim você separa os dois problemas.
Monitore por núcleo. O FXServer concentra carga, então a média engana. É o núcleo mais ocupado que mostra o limite real.
Automatize o backup do banco. Uma linha no crontab. Backup na mesma máquina
não é backup.
Cuide do streaming. Em RedM, boa parte do consumo de memória vem de assets customizados. Auditar o que realmente é usado costuma liberar mais recurso que trocar de sistema.
Perguntas frequentes
RedM roda bem em Linux?
Roda. Ele usa os mesmos artifacts do FiveM, mantidos pela Cfx.re, e servidores de RedM em Linux funcionam sem problema. A diferença é a quantidade de material de apoio disponível quando algo dá errado.
VORP Core funciona em Linux?
Funciona, sem alteração. É um conjunto de resources em Lua com banco MySQL, e nada nele depende do sistema operacional.
txAdmin roda em servidor RedM Linux?
Roda. Vem junto dos artifacts e o painel é idêntico ao do Windows.
Preciso de artifacts diferentes para RedM?
Não. São os mesmos do FiveM. Você escolhe apenas entre a build de Windows e a de Linux.
Quanto de RAM o Linux economiza?
Entre 1 GB e 1,5 GB comparado a um Windows Server, contando só o sistema em repouso. Num plano de 4 GB, é cerca de um quarto da máquina.
Vale a pena migrar uma cidade pequena para Linux?
Raramente. Abaixo de sessenta jogadores o ganho é pequeno e o custo de tempo é alto, especialmente com a documentação escassa de RedM.
Como migro sem perder o progresso dos jogadores?
O progresso vive no banco MySQL, não no sistema. Exporte o banco, copie os resources, monte o servidor Linux em paralelo, importe, teste e só então aponte o endereço.
Conclusão
Para RedM especificamente, a recomendação é um pouco mais conservadora que para FiveM, e o motivo é ecossistema, não tecnologia.
Escolha Windows se este é o seu primeiro servidor de RedM ou se a cidade opera na faixa mais comum do nicho, até algumas dezenas de jogadores. A escassez de material específico em Linux transforma cada problema numa investigação mais longa, e esse tempo tem valor.
Escolha Linux quando a cidade crescer, quando o streaming de assets começar a apertar a memória, ou quando você já dominar o terminal e quiser a automação de backup e reinício. Acima de cem jogadores, a folga de recurso vira estabilidade percebida.
E vale o ponto que fecha a discussão: os dois dependem da máquina embaixo. Como o FXServer concentra a lógica num processo, o que mais decide o tick rate da sua cidade é clock por núcleo, seguido de memória suficiente para o streaming e disco rápido para o banco. Linux numa máquina de clock baixo entrega pior que Windows numa máquina bem dimensionada.
Se você está montando ou migrando e quer que a base não seja o gargalo, vale conhecer os planos de host de RedM da WyzeHost. Você escolhe o sistema na contratação, e a máquina usa AMD Ryzen 9, com SSD NVMe, proteção DDoS inclusa, cache externo de 10Gbps e servidores no Brasil, que é o que segura o ping baixo para o público brasileiro.
Para dimensionar antes de contratar, veja como escolher a VPS para o seu servidor de RedM.


