Requisitos de Servidor para Moodle 5.x: o Guia Prático

Os requisitos de servidor para Moodle mudaram mais entre 2025 e 2026 do que em toda a década anterior: o PHP 8.3 virou piso na versão 5.2, o Oracle saiu de cena e o PostgreSQL subiu três versões em três releases. Este guia traz os números oficiais, o que eles escondem e como dimensionar CPU, RAM, PHP e banco para o seu número real de alunos simultâneos.

TL;DR

• PHP: 8.2.0 é o mínimo do Moodle 5.0 e 5.1; 8.3.0 passou a ser o mínimo na 5.2, lançada em 20/04/2026. Apenas 64 bits, extensão sodium obrigatória e max_input_vars ≥ 5000.
• Banco: MariaDB 10.11.0 e MySQL 8.4 desde a 5.0. PostgreSQL foi de 14 (5.0) para 15 (5.1) e 16 (5.2). Oracle deixou de ser suportado a partir da 5.0.
• Hardware: os requisitos de servidor para Moodle em hardware (512 MB de RAM, 1 GHz) servem para instalar, não para operar. Dimensione por pico de usuários simultâneos.
• Prazo: o Moodle 5.3 LTS chega em 05/10/2026 — exatamente a data em que a 5.0 perde o suporte de segurança.
• Ordem de prioridade: nos requisitos de servidor para Moodle, OPcache e Redis vêm antes de comprar CPU.

O que os requisitos de servidor para Moodle realmente significam

Administro ambientes Moodle desde 2008 e já perdi a conta de quantas migrações começaram com a mesma frase: "o servidor atende os requisitos". Atende — para instalar. A tabela oficial de requisitos de servidor para Moodle é um piso de compatibilidade: ela diz o que impede a instalação de rodar, não o que sustenta 400 pessoas fazendo um questionário ao mesmo tempo na véspera do fechamento das notas.

Vale separar as duas coisas:

• Requisito de compatibilidade — versão de PHP, versão de banco, extensões. Se faltar, o instalador barra. É binário: passa ou não passa.
• Requisito de capacidade — CPU, RAM, disco, IOPS, workers de PHP. Não aparece em nenhum alerta do instalador. Aparece em 502, em Error writing to database e em aluno abrindo chamado.

O primeiro grupo se resolve numa checagem de 5 minutos. O segundo separa o ambiente que aguenta a semana de provas do que cai. Este post cobre os dois.

O relatório que você deveria abrir antes de qualquer coisa

Antes de discutir hardware, confira os requisitos de servidor para Moodle dentro do próprio sistema: Administração do site → Servidor → Verificação do ambiente. O Moodle compara sua instalação com a matriz de requisitos de servidor para Moodle da versão instalada e da próxima, e marca em vermelho o que impede o upgrade. É a fonte da verdade do seu ambiente, mais confiável que qualquer painel de hospedagem.

PHP: qual versão usar em cada release do Moodle 5.x

Aqui está a mudança que mais pegou gente de surpresa em 2026. Os requisitos de servidor para Moodle na camada de PHP subiram duas vezes em pouco mais de um ano:

Release	Lançamento	PHP mínimo	PHP suportado
Moodle 4.5 LTS	07/10/2024	8.1.0	8.1 – 8.3
Moodle 5.0	14/04/2025	8.2.0	8.2, 8.3, 8.4
Moodle 5.1	06/10/2025	8.2.0	8.2, 8.3, 8.4
Moodle 5.2	20/04/2026	8.3.0	8.3, 8.4
Moodle 5.3 LTS	05/10/2026	8.3.0 (previsto)	—

Fonte: páginas de release do moodledev.io.

Três detalhes que a tabela não mostra e já derrubaram instalação:

1. Só PHP de 64 bits. Build de 32 bits é recusado desde a linha 4.x. Raro em servidor Linux, comum em ambiente Windows herdado.
2. A extensão sodium é obrigatória desde a 4.2 e vem em pacote separado em muitas distros (php8.3-sodium). Sem ela, o instalador para.
3. max_input_vars precisa ser ≥ 5000. O padrão do PHP é 1000, e com ele formulários grandes — a página de notas de uma turma cheia, por exemplo — salvam pela metade sem erro visível. É a falha silenciosa mais comum que encontro.

Escolha a versão de PHP pelo calendário, não pelo "mais novo"

Nos requisitos de servidor para Moodle, versão de PHP é decisão de calendário. O PHP 8.2 entra em fim de suporte de segurança em 31/12/2026; o 8.3 vai até 31/12/2027 e o 8.4 até 31/12/2028 (php.net). Cruzando com o calendário do Moodle, a recomendação para quem vai ficar parado por dois anos é PHP 8.3 com Moodle 5.2 ou 5.3 LTS. O 8.4 traz ganho marginal e mais risco de plugin incompatível — vale só com inventário pequeno e testado.

Quando não subir de PHP: com plugin proprietário sem manutenção (relatório customizado, integração antiga com sistema acadêmico), teste em réplica antes. Plugin que quebra no primeiro dia de semestre custa mais que um ano de suporte estendido.

Banco de dados: MariaDB, PostgreSQL e o fim do Oracle

Os requisitos de servidor para Moodle no banco também endureceram. Da 5.0 em diante:

Banco	Moodle 5.0	Moodle 5.1	Moodle 5.2
MariaDB	10.11.0	10.11.0	10.11.0
MySQL	8.4	8.4	8.4
PostgreSQL	14	15	16
SQL Server	2017	2017	2019
Oracle	não suportado	não suportado	não suportado

O salto do MariaDB de 10.6 para 10.11.0 na 5.0 é o que mais trava upgrade no Brasil, porque muita instalação ainda roda o pacote padrão de distribuições antigas. E o prazo joga contra: o MariaDB 10.6 encerrou o suporte da comunidade em 06/07/2026, enquanto o 10.11 vai até 16/02/2028 (endoflife.date). No PostgreSQL, a 14 morre em 12/11/2026 e a 16 vai até 09/11/2028.

Ou seja: se o seu ambiente está em MariaDB 10.6 ou PostgreSQL 14, o problema não é o Moodle — é que o banco já está fora de suporte ou a poucos meses disso.

Duas armadilhas de banco que aparecem só no upgrade

• Prefixo de tabela maior que 10 caracteres. Desde a 4.3, $CFG->prefix está limitado a 10 caracteres, e instalação antiga com prefixo tipo moodle_prod_ não atualiza. A correção é renomear todas as tabelas antes, em janela planejada.
• Charset legado. Bases antigas ainda usam utf8 (3 bytes) em vez de utf8mb4. Funciona até alguém colar um emoji num fórum. A conversão é lenta em base grande e entra no mesmo planejamento do upgrade.

Escolher entre MariaDB e PostgreSQL importa menos que manter qualquer um dos dois na versão certa e bem ajustado. Usamos MariaDB na maioria dos ambientes, e PostgreSQL quando a instituição já tem DBA de Postgres.

CPU e RAM nos requisitos de servidor para Moodle: como dimensionar

A documentação oficial de instalação do Moodle diz: processador de 1 GHz mínimo, 2 GHz dual core recomendado; memória de 512 MB mínimo, 1 GB ou mais recomendado, "8 GB ou mais provavelmente em um servidor de produção grande" (docs.moodle.org). São números honestos e quase inúteis para planejamento: a variável que importa não é quantos alunos você tem, é quantos clicam ao mesmo tempo.

Para traduzir requisitos de servidor para Moodle em números, a conta que uso é simples e conservadora:

1. Estime o pico de usuários simultâneos ativos (não logados: ativos). Uma regra de bolso usável é 5% a 10% dos usuários ativos do dia em uso normal, e 20% ou mais em dia de prova.
2. Cada requisição PHP do Moodle consome tipicamente entre 80 MB e 200 MB de RAM, dependendo de plugins e do relatório aberto. Reserve 256 MB por worker do PHP-FPM para ter folga.
3. Número de workers ≈ pico de requisições concorrentes. RAM da camada web ≈ workers × 256 MB + 1 GB de sistema.
4. O banco quer memória separada: innodb_buffer_pool_size deve caber a base ativa. Em servidor dedicado ao banco, a documentação de performance recomenda até 80% da RAM disponível.

Três faixas que uso como ponto de partida

Cenário	Usuários simultâneos no pico	vCPU	RAM	Arquitetura
Curso livre / escola pequena	até 50	2	4 GB	Tudo em um servidor
Instituição média, EAD ativo	50 – 300	4 – 8	8 – 16 GB	Web + banco separados
Universidade / semana de provas	300+	8+ por nó	16 GB+ por nó	2+ nós web, banco dedicado, Redis dedicado

Duas observações que economizam dinheiro. Acima de 300 simultâneos, aumentar a máquina para de resolver: o gargalo migra para banco e disco, e a saída é separar camadas. E videoaula hospedada dentro do Moodle muda tudo — vídeo deve sair para streaming ou CDN, porque servir MP4 pelo PHP é a forma mais cara de entregar vídeo.

Disco, moodledata e backup: o que ninguém dimensiona

Disco é a parte dos requisitos de servidor para Moodle que mais gente subestima. O código ocupa cerca de 200 MB; o resto é conteúdo — e o moodledata cresce de um jeito que quase ninguém projeta. A documentação sugere 5 GB como mínimo realista; na prática, some:

• Arquivos de curso e envios de alunos. É a maior fatia. Um curso com PDFs e trabalhos enviados por 200 alunos passa fácil de 10 GB por semestre.
• Cache em disco e sessões. Alguns GB, recicláveis.
• Backups automáticos. Por padrão o Moodle guarda backups no próprio moodledata, e curso grande mantido por vários ciclos dobra o consumo de disco. Direcione para fora e defina retenção.
• Logs. Com logstore_standard sem política de expurgo, a tabela de log vira a maior do banco em instalação antiga.

Nos requisitos de servidor para Moodle, o tipo de disco pesa: use SSD/NVMe, não HDD. A diferença de IOPS aparece exatamente nos momentos em que você não pode falhar — restauração de curso, cron pesado e relatório de notas. E backup na mesma máquina não é backup: precisa de cópia externa, testada com restauração real. Já escrevi sobre o custo de descobrir isso tarde no caso de exclusão de conteúdos no Moodle da UFOP.

Ajustes que valem mais que hardware novo

Os requisitos de servidor para Moodle não se resolvem só com máquina maior. Antes de aprovar orçamento, garanta que estes cinco itens estão feitos. Na maioria dos ambientes que auditamos, eles entregam mais ganho que dobrar a CPU.

1. OPcache ligado e dimensionado. A documentação recomenda opcache.memory_consumption a partir de 128 MB, opcache.max_accelerated_files = 10000, opcache.use_cwd = 1, opcache.validate_timestamps = 1 e opcache.save_comments = 1 — este último é obrigatório para o Moodle funcionar. Como o código do Moodle 5.0 já passa de 150 MB de arquivos PHP, subir o memory_consumption para 256 MB em instalação com muitos plugins e pacotes de idioma é sensato.
2. Redis como cache MUC. A própria documentação de performance do Moodle registra que instalar o Redis foi a maior melhoria isolada obtida em um site de porte médio. Configure application cache e session cache no Redis, não em disco.
3. innodb_buffer_pool_size ajustado. É o item número um de desempenho de MySQL/MariaDB segundo a documentação. Buffer pequeno transforma leitura de memória em leitura de disco.
4. Cron por CLI, a cada minuto. Rode php admin/cli/cron.php pelo crontab do sistema, não pelo navegador. Cron atrasado quebra notificações, fila de e-mail, backups e notas — e o sintoma que chega ao suporte nunca é "o cron está parado".
5. HTTP/2, compressão e cabeçalhos de cache no servidor web. Barato, imediato, e reduz a carga percebida pelo aluno.

Quando não otimizar: se os cinco itens já estão em dia e o ambiente ainda satura no pico, o problema é capacidade — aí vale escalar. Insistir em ajuste fino num ambiente já ajustado custa mais em incidente do que custaria o servidor.

Quando atualizar, e quando não

Como os requisitos de servidor para Moodle mudam a cada release, o calendário pesa tanto quanto a tabela — e ele está bem definido para 2026. O Moodle 5.0 perde o suporte de segurança em 05/10/2026 — o mesmo dia em que a 5.3 LTS é lançada. A 5.1 tem suporte geral até 05/10/2026 e segurança até 19/04/2027. A 4.5 LTS, ainda muito usada, mantém apenas suporte de segurança até 04/10/2027.

O caminho mínimo de upgrade também importa: para chegar à 5.0 ou 5.1 é preciso estar em 4.2.3 ou superior; para a 5.2, em 4.4 ou superior. Quem está numa 4.1 ou anterior precisa de salto intermediário — não existe pulo direto.

Minha recomendação para quem não quer revisar requisitos de servidor para Moodle todo ano: espere a 5.3 LTS de outubro de 2026 e faça um único salto, com PHP 8.3 e MariaDB 10.11 (ou PostgreSQL 16). Já detalhei esse raciocínio de versão e LTS no post sobre versão, LTS e upgrade do AVA da UFBA, e o caso de uma migração institucional real está no upgrade do PVANet para o Moodle 4.5.

Quando não atualizar agora: no meio do semestre, sem réplica de homologação, ou com plugin crítico ainda não validado na versão de destino. Upgrade de Moodle é obra planejada, não tarefa de sexta-feira.

Como a Agathas Web resolve isso

Nós operamos ambientes Moodle desde 2008, e a hospedagem Moodle gerenciada da Agathas Web existe justamente para tirar essa lista de decisões da mesa do gestor de TI. O que está incluso:

• Stack já dentro dos requisitos de servidor para Moodle. PHP na versão suportada pela sua release (8.3 como padrão hoje), com sodium, max_input_vars e OPcache ajustados; MariaDB 10.11 com innodb_buffer_pool_size dimensionado para a sua base; Redis para cache MUC e sessões; NGINX com HTTP/2.
• Dimensionamento pelo seu pico real. Analisamos os logs de acesso e a agenda acadêmica para definir vCPU, RAM e workers a partir do pico de simultâneos — inclusive reforço temporário em semana de prova, sem contrato anual em cima de um pico de três dias.
• Cron, backup e monitoramento. Cron por CLI a cada minuto, backup diário fora da máquina com restauração testada, monitoramento de disco, fila de cron e tempo de resposta.
• Upgrade acompanhado. Réplica de homologação, inventário de plugins, teste do caminho mínimo de upgrade e janela combinada. Você aprova a data; nós executamos e voltamos atrás se algo sair do previsto.
• Desenvolvimento sob medida quando o Moodle não basta. Integração com sistema acadêmico, relatórios e avisos de turma pela API oficial do WhatsApp são feitos pela nossa equipe, no mesmo contrato.

Como se contrata: você nos envia a versão atual, o número de usuários ativos e o pico estimado. Devolvemos um diagnóstico com o que já atende os requisitos de servidor para Moodle, o que precisa mudar e o custo mensal — sem taxa de migração para quem vem de outro provedor. Se preferir começar pela conversa, a página de hospedagem Moodle tem o formulário direto com a nossa equipe técnica.

Conclusão: piso oficial, teto operacional

Os requisitos de servidor para Moodle têm duas camadas, e confundir as duas é o erro que gera 90% dos incidentes. A camada oficial é objetiva e você resolve hoje: PHP 8.3, MariaDB 10.11 ou PostgreSQL 16, sodium, max_input_vars em 5000, prefixo de tabela com até 10 caracteres. A camada operacional é a que exige medição: pico de simultâneos, RAM por worker, buffer pool, IOPS, Redis, cron e disco para backup.

Faça na ordem: primeiro a verificação do ambiente no próprio Moodle, depois os cinco ajustes de configuração, e só então hardware. Se quiser pular a parte do diagnóstico e receber o ambiente já ajustado, com upgrade acompanhado e backup testado, é exatamente isso que entregamos na hospedagem Moodle gerenciada.