NexTool Solutions

O GLPI open source não tem mensalidade, mas "sem licença" está muito longe de "sem custo". Quem compara só o preço de tabela do GLPI self-hosted com o de um ServiceNow erra a conta nas duas direções: subestima o que o self-hosted consome em operação e superestima o que o SaaS entrega de fábrica. Este comparativo coloca lado a lado os quatro modelos que mais implantamos - GLPI self-hosted, GLPI Cloud, ServiceNow e Jira Service Management - no eixo que realmente move o TCO: a unidade de cobrança e o trabalho de operação.

Os quatro modelos, em uma frase cada

• GLPI self-hosted (open source): software gratuito, sem limite de usuários; você paga infraestrutura e mão de obra.
• GLPI Cloud (Teclib): o mesmo GLPI, hospedado e mantido pela Teclib, com assinatura por técnico.
• ServiceNow: plataforma ITSM enterprise, licença por agente sob cotação, voltada a automação e governança em larga escala.
• Jira Service Management: ITSM da Atlassian, assinatura por agente em planos, forte para quem já vive no ecossistema Jira/Confluence.

Os três pagos cobram por agente ou técnico: o custo cresce de forma aproximadamente linear com o tamanho da equipe de atendimento. O self-hosted inverte a lógica - o software é fixo em zero e o custo vem da operação. É essa diferença de natureza, e não o preço de um mês isolado, que decide qual sai mais barato no horizonte de três anos.

Comparativo direto

Quantos "agentes" você realmente paga

Aqui está a armadilha que só aparece na hora da fatura: nos modelos por agente, quem custa é o usuário com interface técnica (central), não o requerente que só abre chamado pelo autoatendimento. Requerentes costumam ser ilimitados e gratuitos nos três. Ou seja, o número que define o seu boleto não é "quantas pessoas usam o GLPI", e sim "quantas têm perfil de técnico".

No self-hosted esse número é invisível - ninguém cobra por ele, então as organizações distribuem perfil central com folga: o coordenador que só quer ver dashboard, o gerente que "às vezes precisa olhar a fila", o estagiário que fechou dois chamados no ano passado. Na migração para qualquer SaaS por agente, cada um desses vira uma linha na fatura. Antes de pedir cotação, rode esta consulta no banco do seu GLPI para saber o número real:

-- Quantos "agentes" você pagaria num SaaS por agente?
-- Agente faturável = usuário com perfil de interface central (técnico),
-- não o usuário de autoatendimento (helpdesk), que costuma ser ilimitado.
SELECT COUNT(DISTINCT pu.users_id) AS agentes_faturaveis
FROM glpi_profiles_users pu
JOIN glpi_profiles p ON p.id = pu.profiles_id
JOIN glpi_users     u ON u.id = pu.users_id
WHERE p.interface = 'central'   -- interface técnica (exclui helpdesk)
  AND u.is_active  = 1
  AND u.is_deleted = 0;

Já vimos esse número vir 40% acima do que o cliente estimava "de cabeça". Antes de comparar preço com SaaS, faça a faxina: rebaixe para autoatendimento quem não atende de fato. Isso reduz a fatura futura e, de quebra, limpa os relatórios de produtividade no próprio GLPI.

O custo oculto que não entra na planilha

Na sustentação de parques GLPI para clientes, o item que mais estoura o TCO do self-hosted não aparece em tabela nenhuma: é a dívida de atualização. O cliente sobe o GLPI, funciona, e ninguém toca por dois anos. Quando enfim precisa de um recurso novo ou de um plugin compatível, descobre que pular de uma 9.5 para a 11 não é "clicar em atualizar" - é migrar schema, revisar plugins que quebraram e testar em homologação. O que era manutenção de 2h/mês virou um projeto. O erro comum é orçar o self-hosted só pelo VPS e tratar atualização como evento raro; ela é recorrente e exige janela, backup testado e ambiente de teste.

E há o outro custo que ninguém coloca na conta: o backup que existe mas nunca foi restaurado. No self-hosted, o DR é responsabilidade sua por inteiro - e um dump que ninguém testou é um backup que você não tem. O mínimo viável é dump diário do banco e dos arquivos, com verificação periódica:

# /etc/cron.d/glpi-backup - dump diário do banco + arquivos do GLPI.
# No self-hosted, backup e DR são 100% seus; um dump nunca restaurado não conta.
30 2 * * *  root  mysqldump --single-transaction glpi | gzip > /backup/glpi-$(date +\%F).sql.gz
45 2 * * *  root  tar czf /backup/glpi-files-$(date +\%F).tar.gz /var/www/glpi/files
# Guarde cópia FORA do host e teste o restore ao menos uma vez por trimestre.

No GLPI Cloud, no ServiceNow e no Jira SM, atualização, backup e disponibilidade entram no preço da assinatura - é exatamente isso que você compra ao pagar por agente. A pergunta certa não é "qual é mais barato", e sim "esse trabalho operacional fica no meu time ou terceirizado na mensalidade?".

Veredito por cenário

• Use GLPI self-hosted quando você tem (ou contrata) quem opere Linux, banco e backup, valoriza soberania de dados e quer teto de custo previsível mesmo dobrando a equipe de agentes. É imbatível em custo por agente à medida que o time cresce; se for esse o caminho, comece pela instalação via Docker.
• Use GLPI Cloud quando quer o mesmo GLPI - mesma base, mesmos conceitos, mesmos plugins compatíveis - sem manter infraestrutura, e a equipe de técnicos é pequena o suficiente para a assinatura ainda sair menor que um sysadmin dedicado.
• Use ServiceNow quando a necessidade real é automação e governança enterprise (fluxos complexos, integrações corporativas, compliance) e há orçamento para o patamar mais alto do mercado. Contratar ServiceNow só para abrir chamado é pagar por um avião para atravessar a rua.
• Use Jira Service Management quando a empresa já roda em Jira/Confluence e quer o ITSM colado nesse ecossistema, aceitando a cobrança por agente e os limites de inventário/CMDB frente ao GLPI.

Custo e esforço, com faixas honestas

O eixo da decisão não é a licença - é para onde vai o trabalho de operação. No self-hosted, o desembolso em dinheiro é baixo (um VPS de poucas dezenas a poucas centenas de reais por mês, conforme a escala), mas exige horas técnicas recorrentes: uma implantação bem-feita raramente cabe em menos de alguns dias de trabalho, e a sustentação pede uma janela mensal para atualização e verificação de backup. Nos modelos por agente, o desembolso é maior e cresce linearmente com o time, mas as horas de operação de infraestrutura vão para perto de zero. A conta de três anos costuma favorecer o self-hosted quanto maior a equipe de agentes e quanto mais barata for a hora técnica disponível; favorece o SaaS quando a equipe é enxuta e não há quem opere infraestrutura. Não crave um número de TCO fechado antes de ter o total de agentes faturáveis e o custo real da sua hora técnica - sem esses dois, qualquer comparativo é chute.

Na NexTool implantamos e sustentamos os quatro cenários em clientes - do GLPI self-hosted enxuto ao migrado para Cloud - e a decisão que mais rende é sempre a mesma: dimensionar o custo pela unidade certa (agentes faturáveis) e pelo trabalho de operação que a sua equipe consegue absorver. Se quiser um TCO honesto para o seu caso, sem chute de tabela, nossa consultoria monta esse comparativo com os seus números.

Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.