"Podemos executá-la nos nossos próprios servidores?" é uma das primeiras perguntas que os compradores sérios de IoT fazem — e uma das que recebem respostas menos honestas. Auto-hospedar uma plataforma IoT é genuinamente a escolha certa para algumas implementações e um desvio caro para outras. Eis como saber em qual dos casos se encontra.

O que auto-hospedada significa realmente

Uma plataforma IoT auto-hospedada corre em infraestrutura que controla: os seus próprios servidores, a sua cloud privada ou um segmento de rede isolado. Os dados dos dispositivos nunca saem do seu perímetro, a autenticação integra-se com os seus sistemas de identidade, e a disponibilidade da plataforma é responsabilidade da sua equipa — tanto no sentido de autonomia como no sentido da chamada às 3 da manhã.

Essa última parte é o núcleo honesto deste artigo: a auto-hospedagem não é uma funcionalidade que se ativa, é uma função de operações que se assume.

As boas razões para auto-hospedar

Soberania de dados e conformidade. Os setores regulados, o setor público e as infraestruturas críticas têm frequentemente requisitos rígidos de que a telemetria permaneça on-premise ou dentro do país. Se os seus auditores dizem que os dados não podem sair, a discussão termina aí — precisa de uma implementação on-premise.

Locais isolados (air-gapped) e com baixa conectividade. Uma fábrica, um navio ou uma instalação remota com uma ligação pouco fiável pode precisar da plataforma ao lado das máquinas, não do outro lado do oceano.

Latência e localidade. Quando as decisões de automação têm de disparar em milissegundos sobre equipamentos locais, uma plataforma local elimina a viagem de ida e volta.

Controlo a longo prazo. Algumas equipas querem simplesmente a garantia de que nenhuma alteração de preços nem descontinuação de produto por parte do fornecedor poderá deixar a sua implementação encalhada.

Os custos que ninguém coloca na landing page

As plataformas open source que hospeda por conta própria — a Community Edition Apache 2.0 do ThingsBoard é o exemplo mais conhecido — são gratuitas no licenciamento, não na operação. Alguém tem de dimensionar e escalar a base de dados, aplicar patches de segurança, testar as atualizações, monitorizar a própria monitorização e ficar de prevenção. Funcionalidades que assumia estarem incluídas podem estar nas edições pagas; no ThingsBoard, por exemplo, a conectividade LoRaWAN chega através de integrações com servidores de rede externos reservadas aos escalões pagos. A nossa comparação Kilo vs ThingsBoard expõe essa troca com honestidade, incluindo onde o ThingsBoard vence realmente.

Uma regra prática útil: se não consegue nomear o engenheiro que será responsável pelas atualizações da plataforma daqui a dezoito meses, não está a escolher auto-hospedagem — está a escolher dívida técnica.

O caminho do meio: uma plataforma gerida, implementada on-premise

A escolha não se resume a "SaaS público" ou "open source em bruto". A plataforma IoT da Kilo funciona como SaaS na cloud e como implementação on-premise: a mesma plataforma — servidores de rede LoRaWAN e mioty integrados, dashboards com um gêmeo digital 3D do edifício, regras com ciclo construir-testar-implementar-reverter, cadeias de escalonamento de alarmes e o assistente de IA — instalada dentro do seu perímetro, com o fornecedor ainda responsável pelo software em si.

Isso divide a diferença exatamente onde a maioria das equipas a quer dividida: a sua infraestrutura e os seus dados, mas não a tarefa de desenvolver e manter a plataforma.

Uma checklist curta antes de decidir

Faça cinco perguntas. Alguma regulamentação exige realmente on-premise, ou apenas parece mais seguro? Quem opera a plataforma no segundo ano? A edição auto-hospedada inclui a conectividade de que precisa (servidor de rede LoRaWAN, MQTT) ou são extras pagos? Quanto custa voltar atrás se se enganar? E consegue pilotar primeiro os dois modelos com custos baixos?

Essa última é fácil de responder: o escalão cloud da Kilo é gratuito para 5 dispositivos, pelo que pode provar o valor da aplicação na cloud e passar depois para on-premise com o modelo de implementação já validado — em vez de depurar a infraestrutura e o caso de uso ao mesmo tempo.