O módulo WHMCS para CyberPanel, e a alternativa

Quem faz correr o WHMCS e quer vender alojamento OpenLiteSpeed vai à procura de um módulo de aprovisionamento CyberPanel. Medidos a 21 de agosto de 2026, os resultados dessa pesquisa são um repositório GitHub mantido por uma só pessoa, e um tópico de fórum comunitário.

Isto não é uma crítica ao trabalho de ninguém. É a descrição de uma lacuna: um software que se situa entre as suas faturas e os sites dos seus clientes, e que a maioria dos alojadores encontra sob a forma de projeto paralelo em vez de produto.

Esta página trata do que um módulo destes pode fazer, do que estruturalmente não pode, e do aspeto de uma forma diferente de solução. A primeira parte é a que mais pesa, porque o teto não é o módulo: é a API do CyberPanel.

O teto: o que a API do CyberPanel autoriza

Medido contra o CyberPanel 3.0, não retirado da documentação. Qualquer módulo (o do GitHub, um escrito por conta própria, ou o descrito mais abaixo) está limitado por tudo o que se segue.

Criar um site responde antes de conhecer o resultado

createWebsite devolve o controlo em cerca de três segundos com createWebSiteStatus: 1. Isso não é um veredicto; significa que o trabalho foi iniciado. O endpoint lança um comando em segundo plano e devolve o controlo de imediato. O progresso real vive num ficheiro de estado que tem de ser sondado à parte.

Medido com dados deliberadamente errados:

Só a forma do domínio e do endereço é validada à partida. Um módulo que confia na primeira resposta marca uma encomenda WHMCS como ativa para um site que nunca foi criado, e o cliente recebe credenciais de boas-vindas para algo que não existe.

Sondar esse ficheiro de estado comporta mais duas ciladas. Ler um estado concluído apaga-o, pelo que uma sondagem a mais transforma uma criação terminada num «ainda a trabalhar» permanente. E a chamada de estado situa-se na parte da API do CyberPanel que recusa todo o administrador que não se chame literalmente admin.

A criação completa demora cerca de cinquenta segundos, dos quais cerca de vinte e oito são uma tentativa de SSL que o CyberPanel faz incondicionalmente. A API sobrepõe-se a esse indicador seja o que for que se envie. Qualquer módulo precisa de um tempo-limite que o acomode.

Mudar de pacote muda um campo em base de dados

changePackageAPI devolve o controlo em cerca de 270 milissegundos e o painel mostra o novo nome. Medido depois a partir do interior do servidor, com um pacote com limites diferentes: a quota de disco estava inalterada (soft 0, hard 0) e a configuração vhost ainda tinha os limites de memória e de processos do pacote antigo.

Nada foi aplicado. Assim, uma encomenda de upgrade WHMCS pode concluir-se, ser faturada e mudar o nome no painel, ao passo que os limites reais do cliente são exatamente os de antes. Nenhum módulo pode corrigir isto: toda a implementação deste endpoint é uma atualização de campo.

A suspensão não bloqueia a conta

O CyberPanel suspende um site reescrevendo o seu vhost para uma página de suspensão e reiniciando o servidor web. O utilizador unix não é bloqueado; o FTP, o correio e as bases de dados continuam a funcionar. Se suspende por falta de pagamento, o seu cliente continua a ter o correio e a base de dados. Isso pode ser exatamente o que quer, mas deveria ser uma decisão e não uma surpresa.

Há também uma aresta mais afiada: a implementação é if state == "Suspend": … else: <reativar>, sem validação. Medido: enviar "suspend" em minúsculas reativou um site suspenso e anunciou êxito. Qualquer módulo deveria manter esses dois valores como constantes e nunca compô-los a partir de uma variável.

Não há dados de utilização

A largura de banda é calculada pelo CyberPanel e depois descartada antes de chegar a qualquer listagem. A utilização de disco provém de uma cache no registo do site, que está vazia num site novo, pelo que o valor recai para zero. E um zero vindo de uma cache vazia não se distingue de um site que não consome nada.

O WHMCS dispõe de um hook de recolha de utilização que espera valores de disco e de largura de banda. No CyberPanel não há nada de honesto para lá colocar: um módulo que o preenche mesmo assim está a reportar um valor por predefinição, não uma medição.

O acesso à API está desativado, e a ordem das verificações esconde porquê

Num CyberPanel novo, a API está desativada, incluindo para o administrador principal, e o indicador é verificado antes da palavra-passe, pelo que, com ele desligado, uma palavra-passe correta e uma errada devolvem o mesmo API Access Disabled. A falha de primeira execução de todos os módulos para este painel parece um problema de credenciais e não o é.

O que isto significa para um módulo

Nada do que precede é reparável dentro de um módulo WHMCS, porque nada disto é um problema de módulo. O que difere entre módulos é a honestidade com que o tratam:

• Sonda o estado de criação, ou confia na primeira resposta?
• Lê o estado uma vez e regista o resultado, ou sonda até apagar esse resultado por acidente?
• Avisa que uma mudança de pacote não aplicou nada?
• Deixa o hook de utilização vazio, ou enche-o de zeros que parecem dados?
• Diz «o acesso à API está desativado» em vez de «credenciais inválidas»?

São estas as perguntas a fazer a qualquer módulo que se esteja a ponderar. Respondem-se lendo o código, e pesam mais do que a lista de funcionalidades. Há mais uma, que diz respeito a si e não ao código: quem o mantém daqui a dezoito meses? Um módulo de aprovisionamento está no caminho crítico de cada encomenda que aceita.

A alternativa: uma camada de aprovisionamento, não um módulo de painel

O Provibr coloca-se entre o seu sistema de faturação e a sua infraestrutura. Não é um módulo WHMCS para CyberPanel; é uma plataforma de aprovisionamento que fala com o CyberPanel, e com a qual o WHMCS fala através de um único módulo, independentemente do que esteja por baixo.

A diferença prática:

Duas linhas merecem um desenvolvimento, porque são as honestas.

O custo. O módulo é gratuito e o Provibr não é. O Provibr cobra a capacidade que reserva (quantas contas de alojamento pode fazer correr ao mesmo tempo) a um preço unitário por escalões que baixa à medida que o número sobe. O que cobra aos seus próprios clientes continua inteiramente seu. Se tem doze sites CyberPanel e nenhum plano de crescimento, um módulo gratuito é a resposta certa.

Os mesmos limites, uma honestidade diferente. O Provibr não repara a mudança de pacote do CyberPanel, não inventa valores de utilização, e não bloqueia uma conta suspensa. Não o pode fazer: são propriedades do painel. O que faz é recusar-se a fingir o contrário.

Como se encaixa no WHMCS

Um módulo, instalado como um simples zip em modules/servers/. No WHMCS adiciona-se um servidor que aponta para o Provibr com uma chave de API, e depois faz-se apontar um produto WHMCS para um plano de alojamento web Provibr. Uma encomenda paga cria a conta, uma suspensão suspende-a, uma rescisão remove-a. O seu cliente mantém uma conta, uma fatura e um início de sessão.

A chave de API contém âmbitos, e o que pode realmente fazer é a interseção desses âmbitos e das permissões do membro a que pertence, pelo que uma chave só pode restringir o acesso, nunca alargá-lo. Retire-se uma permissão a um colega e todas as suas chaves ficam mais restritas no pedido seguinte, sem que ninguém tenha de revogar seja o que for.

Se não faz correr o WHMCS, as mesmas operações estão disponíveis através da API REST: uma chave, um URL de base. Tudo o que toca numa máquina responde «aceite» com um comando a seguir, porque a sua infraestrutura só é acessível através do agente que está dentro da sua própria rede. As leituras respondem de imediato.

Quando o módulo é a melhor escolha

Para ser direto: se o CyberPanel é o único painel que faz correr, se já tem o WHMCS, se o seu volume é pequeno e se ler PHP quando algo se avaria não o incomoda, um módulo representa menos maquinaria e nenhum custo mensal. Os limites do topo desta página aplicam-se igualmente às duas opções.

O argumento a favor de uma camada por cima começa quando faz correr mais do que um painel, quando quer as credenciais fora do seu anfitrião WHMCS, quando algo que não o WHMCS tem de colocar encomendas, ou quando quer que o caminho de aprovisionamento seja o produto de alguém em vez do fim de semana de alguém.

O Provibr faz correr hoje os seus painéis de controlo, os seus hipervisores e os seus painéis de jogo lado a lado, num só inventário, sob um só modelo de permissões, com um só registo de atividade. Não é obrigatório escolher entre o CyberPanel e tudo o resto.