Como Auto-Hospedar o Uptime Kuma em um VPS

Você pode auto-hospedar o Uptime Kuma em um VPS da VoyraCloud selecionando a imagem de aplicativo pré-instalada, criando o primeiro administrador através de um túnel SSH privado e, em seguida, adicionando monitores para os serviços que você opera. A imagem fornece um ponto de partida persistente do Uptime Kuma, enquanto o acesso público, HTTPS confiável, notificações, backups, atualizações, planejamento de capacidade e resposta a incidentes permanecem sob seu controle.

TL;DR

A imagem do aplicativo VoyraCloud Uptime Kuma fornece um painel de monitoramento pré-instalado em Cloud VPS e Residential IP VPS.
A porta 3001 está vinculada a 127.0.0.1 por padrão, então crie o primeiro administrador através de um túnel SSH em vez de expor uma página de configuração não inicializada à internet.
O Uptime Kuma suporta monitores de HTTP, HTTPS, TCP, ping, DNS, WebSocket, push, palavra-chave e consulta JSON, entre outros tipos de monitores documentados pelo projeto.
O acesso ao painel público ou à página de status requer seu próprio domínio, um proxy reverso que suporte atualizações de WebSocket e HTTPS confiável pelo navegador.
A configuração, usuários, histórico de monitoramento, notificações e páginas de status são armazenados em /app/data no armazenamento local persistente. A persistência de reinicialização não é um backup.
Uma carga de trabalho de 20 monitores, com intervalos de 60 segundos, é o perfil de validação inicial da imagem, não uma garantia de monitor ilimitado ou um substituto para medir sua própria carga de trabalho.
O monitoramento do mesmo VPS tem um ponto cego importante: se esse VPS, sua região ou seu caminho de rede falharem, o Uptime Kuma pode não conseguir enviar o alerta.

O que é o Uptime Kuma?

O Uptime Kuma é um aplicativo de monitoramento de código aberto e auto-hospedado para verificar sites, APIs, serviços de rede e outros pontos de extremidade acessíveis a partir de um painel que você controla. Ele registra os resultados das verificações e informações de resposta, apresenta o histórico de serviços e pode enviar notificações através de integrações configuradas pelo administrador.

O projeto oficial do Uptime Kuma lista suporte para tipos de monitores como HTTP(S), TCP, palavra-chave HTTP(S), consulta JSON HTTP(S), WebSocket, ping, registro DNS, push e monitoramento de contêiner Docker. Ele também fornece várias páginas de status, informações de certificado, gráficos de ping, autenticação de dois fatores, suporte a proxy e uma ampla gama de integrações de notificação.

A auto-hospedagem é útil quando você deseja:

Um painel de monitoramento sob sua própria administração de servidor.
Controle sobre a configuração de monitores, usuários, histórico e páginas de status.
Uma maneira simples de verificar vários sites, APIs ou serviços de rede.
A opção de conectar provedores de notificação que você já usa.
Uma ferramenta de monitoramento que pode funcionar continuamente em um pequeno VPS.

O Uptime Kuma não é um serviço de monitoramento gerenciado quando implantado dessa forma. Você possui o VPS, controles de acesso, atualizações, backups, credenciais de notificação e processo de resposta. Você também deve decidir se um local de monitoramento fornece visibilidade suficiente para os serviços que são importantes para você.

Como você começa com a imagem do aplicativo VoyraCloud?

A maneira mais rápida de auto-hospedar o Uptime Kuma é criar um VPS VoyraCloud suportado com a imagem do aplicativo e completar a primeira configuração através de um túnel SSH local. Você não precisa instalar o Uptime Kuma manualmente, mas deve criar o administrador de forma segura antes de configurar os monitores.

Abra a página da VoyraCloud para Uptime Kuma e continue para o fluxo de compra do VPS.
Selecione um plano de Cloud VPS ou Residential IP VPS elegível, em seguida, escolha qualquer região atualmente oferecida por esse produto.
Confirme que o Uptime Kuma está selecionado na seção Imagens, em seguida, crie o VPS.
Espere até que o recurso VPS e o aplicativo estejam prontos.
Abra os detalhes do recurso e localize a seção Aplicativo.
Copie o comando do túnel SSH exibido. Ele segue este padrão:

ssh -p <ssh-port> -L 3001:127.0.0.1:3001 <ssh-user>@<server-ip>

7. Mantenha essa sessão SSH aberta e navegue para:

http://127.0.0.1:3001

8. Complete a página de configuração oficial do Uptime Kuma e crie um nome de usuário de administrador exclusivo e uma senha forte.

9. Faça login, crie um monitor de teste e confirme que as verificações aparecem no painel.

10. Reinicie o VPS uma vez e verifique se o Uptime Kuma retorna automaticamente e se a conta, o monitor e o histórico permanecem disponíveis.

O endereço do navegador é local, mas o aplicativo é executado no VPS. O SSH encaminha sua porta local 3001 através de uma conexão criptografada para 127.0.0.1:3001 no servidor. Fechar a sessão SSH fecha o túnel; isso não para o Uptime Kuma.

Se o seu computador já usa a porta local 3001, escolha outra porta local sem alterar o destino remoto:

ssh -p <ssh-port> -L 33001:127.0.0.1:3001 <ssh-user>@<server-ip>

Você então abriria http://127.0.0.1:33001 em seu navegador. Mantenha o lado remoto como 127.0.0.1:3001.

Use o nome de usuário SSH e a porta mostrados para seu próprio recurso, em vez de assumir root e a porta 22.

O que a imagem do aplicativo inclui?

A imagem do aplicativo inclui uma instância do Uptime Kuma pré-instalada e persistente, mas não converte o VPS em um serviço de monitoramento gerenciado. A seguinte delimitação é importante ao planejar o uso em produção.

Entregue pela imagem do aplicativo	Gerenciado pelo usuário ou não incluído
Versão estável do Uptime Kuma aprovada para a imagem	Atualizações automáticas do aplicativo
Ambiente operacional de Cloud VPS ou Residential IP VPS	Administração de servidor gerenciada
Recuperação de serviço após uma reinicialização normal do VPS	Alta disponibilidade ou failover automático
Acesso local apenas em `127.0.0.1:3001`	Exposição da porta pública `3001`
Fluxo de configuração do primeiro administrador oficial	Administrador pré-criado ou senha fixa
Armazenamento local persistente em `/app/data`	Backups automáticos fora do servidor
Painel de monitoramento, histórico, notificações e recursos de página de status	Contas de notificação de terceiros pré-configuradas
Instruções de túnel SSH nos detalhes do recurso	Registro de domínio, proxy reverso ou HTTPS confiável
Configuração de monitor controlada pelo usuário	Precisão de detecção garantida ou entrega de alerta
Uptime Kuma sob sua licença de código aberto	Manutenção do Uptime Kuma pela VoyraCloud após a entrega

A imagem não inclui uma credencial de administrador fixa, modo sem autenticação, segredos de notificação, um domínio, um certificado ou um ponto de gerenciamento público. Isso mantém o primeiro acesso privado e evita colocar uma página de criação de conta não inicializada diretamente na internet.

Quais tipos de monitores você deve usar?

Escolha cada tipo de monitor do Uptime Kuma de acordo com a camada que você precisa testar, porque um ping bem-sucedido não prova que um site, API ou aplicativo funciona corretamente. Um conjunto de monitoramento útil verifica a camada voltada para o usuário e as dependências selecionadas, em vez de depender de um único heartbeat genérico.

Tipo de monitor	O que pode verificar	Limitação importante
HTTP ou HTTPS	Uma URL responde e retorna um status esperado	Uma resposta bem-sucedida ainda pode conter conteúdo incorreto
Palavra-chave	Uma resposta inclui ou exclui texto esperado	Verificações de texto não validam cada função de negócios
Consulta JSON	Uma resposta de API contém um valor esperado	A consulta deve corresponder à estrutura real da resposta
Porta TCP	Um serviço de rede aceita uma conexão	Uma porta aberta não prova que o aplicativo está saudável
Ping	Um host responde ao ICMP	ICMP pode ser filtrado, e uma resposta não prova que um aplicativo funciona
Registro DNS	Um resolvedor retorna o registro esperado	Uma visão de resolvedor pode não representar a propagação global
WebSocket	Um ponto de extremidade WebSocket pode ser alcançado	Isso não valida cada fluxo de mensagem
Push	Um trabalho ou processo remoto relata seu próprio heartbeat	Um push ausente precisa de uma janela de alerta projetada para esse trabalho
Informações do certificado	Estado do certificado e informações de expiração	A renovação ainda depende do seu processo de certificado

Para um site público, um conjunto prático pode incluir uma verificação de HTTPS, uma verificação de palavra-chave ou JSON para conteúdo significativo e uma verificação de expiração de certificado. Para um serviço interno acessível a partir do VPS, uma verificação de TCP ou HTTP pode adicionar visibilidade à infraestrutura. Para um trabalho agendado, um monitor de push pode detectar quando o heartbeat esperado não chega.

Evite criar vários monitores que falham pelo mesmo motivo e depois tratá-los como evidências independentes. O design do monitor deve refletir modos reais de falha: DNS, TLS, acessibilidade de rede, resposta do aplicativo, correção de conteúdo e conclusão de trabalhos em segundo plano.

O que significa o perfil de validação de 20 monitores?

O perfil de 20 monitores é uma carga de trabalho de aceitação conservadora para a configuração inicial da imagem, não uma promessa de capacidade máxima. A validação planejada usa 20 monitores em intervalos de 60 segundos por 24 horas, seguida por uma reinicialização do VPS e uma verificação de persistência.

Essa validação tem como objetivo responder a uma pergunta específica: a configuração de entrada elegível pode executar uma pequena instalação do Uptime Kuma sem eventos de falta de memória, bloqueio de banco de dados, reinicializações inesperadas de contêiner ou perda de dados sob uma carga de trabalho definida? Não prova que o mesmo plano pode suportar:

Monitores ilimitados.
Intervalos de verificação muito curtos.
Corpos de resposta grandes ou consultas JSON caras.
Vários usuários simultâneos ou visitantes de páginas de status públicas.
Longos períodos de retenção sem crescimento de armazenamento.
Volume elevado de notificações.
Monitoramento de Docker com acesso ao soquete do host.
Aplicativos adicionais compartilhando o mesmo VPS.

O uso real de recursos depende do tipo de monitor, intervalo, tempo limite, tamanho da resposta, retenção de histórico, comportamento de notificação, atividade do painel e outros softwares no servidor. Comece com um conjunto medido, observe o uso de CPU, memória, disco, comportamento do banco de dados e duração da verificação, e depois mude para uma configuração de VPS VoyraCloud maior quando a carga de trabalho real exigir.

Não interprete o mínimo do fluxo de compra como uma recomendação de dimensionamento universal. É um portão de elegibilidade para o perfil de partida validado.

Como você deve publicar o Uptime Kuma de forma segura?

Publique o Uptime Kuma através de um domínio ou subdomínio dedicado, um proxy reverso capaz de WebSocket e HTTPS confiável pelo navegador, mantendo a porta 3001 vinculada ao localhost. O acesso de túnel SSH a longo prazo também é válido quando apenas administradores precisam do painel e nenhuma página de status pública é necessária.

O guia de proxy reverso do Uptime Kuma explica que o aplicativo usa WebSocket e requer que o proxy passe os cabeçalhos Upgrade e Connection. Também observa que o Uptime Kuma não suporta ser hospedado sob um subdiretório de URL normal, como /uptime-kuma; use um nome de host dedicado, como status.example.com.

Um bloco de localização típico do Nginx inclui:

location / {
    proxy_pass http://127.0.0.1:3001;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Esse trecho cobre apenas o caminho do proxy. Você deve configurar separadamente o nome do host, certificado TLS confiável, renovação de certificado, redirecionamento de HTTP para HTTPS, firewall e política de acesso. Verifique o exemplo oficial atual para seu proxy reverso escolhido antes de aplicá-lo.

Use esta lista de verificação de produção:

Crie um registro DNS para um nome de host dedicado.
Mantenha 3001/tcp indisponível a partir da internet pública.
Configure o proxy reverso para alcançar 127.0.0.1:3001.
Preserve os cabeçalhos de atualização do WebSocket.
Instale um certificado confiável por navegadores normais.
Redirecione HTTP simples para HTTPS.
Confirme que o painel é atualizado sem erros de WebSocket.
Teste login, logout, atualizações de monitor e páginas de status.
Restringa o nome do host da administração quando o acesso público não for necessário.
Revise as configurações de proxy confiável apenas após o caminho do proxy e do firewall estarem corretos.

HTTPS confiável protege credenciais e tráfego de sessão em trânsito, mas não garante uma senha de administrador fraca ou um servidor desatualizado. Mantenha o SSH endurecido, limite privilégios, habilite autenticação de dois fatores quando apropriado e mantenha o sistema operacional e o proxy reverso.

Como funcionam as notificações e páginas de status?

Notificações e páginas de status são recursos que você configura após a inicialização; a imagem não inclui contas de terceiros, credenciais, garantias de entrega ou um domínio público. O Uptime Kuma suporta muitos métodos de notificação, mas cada provedor tem sua própria conta, disponibilidade, preços, limites e comportamento de entrega.

A documentação dos métodos de notificação fornece referências de configuração específicas do provedor. Adicione apenas integrações que sua equipe possui, armazene credenciais com cuidado e envie uma notificação de teste antes de depender delas. Um teste bem-sucedido prova que uma mensagem funcionou naquele momento; não garante entrega futura.

Para cada monitor importante:

Decida quem deve receber um alerta.
Defina um intervalo de verificação e uma política de repetição que se encaixe no serviço.
Configure um ou mais métodos de notificação de propriedade do usuário.
Teste notificações de falha e recuperação.
Confirme que uma pessoa de plantão pode agir sobre a mensagem.
Documente o que fazer quando o monitor reportar uma falha.

Páginas de status permitem que você compartilhe estados de monitores selecionados e informações de incidentes. Elas não precisam expor todos os monitores internos. Agrupe serviços de uma maneira que os clientes entendam, evite publicar nomes de host sensíveis ou topologia interna e use seu próprio domínio e caminho de proxy seguro para acesso público.

Não assuma que toda integração de notificação é gratuita. Alguns serviços podem cobrar, limitar o uso, alterar suas APIs ou exigir configuração adicional. A VoyraCloud não fornece essas contas de terceiros e não pode garantir que um provedor aceite ou entregue uma mensagem.

Como os dados do Uptime Kuma são armazenados e respaldados?

O Uptime Kuma mantém seu estado de aplicativo em /app/data, que deve permanecer em armazenamento local persistente e deve ser respaldado separadamente do VPS em execução. A orientação de instalação oficial requer suporte ao sistema de arquivos para bloqueios de arquivos POSIX e alerta contra problemas de bloqueio de arquivos comumente associados ao NFS.

Os dados persistentes incluem o banco de dados e o estado do aplicativo necessários para itens como:

Configurações de administrador e usuário.
Definições de monitor.
Histórico de monitoramento.
Configuração de notificações.
Páginas de status.
Agendas de manutenção.
Outras configurações da instância.

Uma reinicialização normal do VPS deve preservar esses dados e reiniciar o aplicativo. Esse comportamento é persistência, não recuperação de desastres. Exclusão acidental, corrupção de banco de dados, credenciais comprometidas, falha na atualização, perda de armazenamento ou exclusão do VPS ainda podem remover a única cópia.

Uma rotina de backup mais segura é:

Identifique o volume Docker local real ou diretório local mapeado para /app/data.
Agende backups para um destino fora do VPS.
Quiesça ou pare o Uptime Kuma quando o método de backup escolhido exigir uma cópia consistente do banco de dados.
Copie o conjunto completo de dados, não apenas uma lista de monitores exportados.
Criptografe e proteja o backup, pois ele pode conter detalhes operacionais e credenciais de notificação.
Mantenha mais de um ponto de recuperação.
Restaure para uma instância de teste separada e verifique contas, monitores, histórico, notificações e páginas de status.
Registre a versão do aplicativo associada ao backup.

Não coloque o diretório ativo /app/data no NFS para esta imagem. Um destino de backup remoto é apropriado para artefatos de backup copiados; é diferente de executar o banco de dados ativo diretamente em um sistema de arquivos de rede.

Qual é o ponto cego do monitoramento no mesmo servidor?

Uma instância do Uptime Kuma não pode relatar falhas de forma confiável que também removem seu próprio caminho de computação, rede ou notificação. Se o Uptime Kuma estiver em execução no mesmo VPS que o site que monitora, uma interrupção do VPS pode parar tanto o site quanto o monitor antes que o alerta seja enviado.

Mesmo quando o serviço monitorado está em outro servidor, uma localização do Uptime Kuma ainda o observa de uma rede e uma região. Uma rota de ISP local, problema de rede regional, diferença de resolvedor DNS ou política de firewall pode afetar essa visão sem representar a experiência de cada usuário.

Use a implantação de acordo com a consequência:

Necessidade de monitoramento	Abordagem apropriada
Painel conveniente para pequenos serviços	Uma instância do Uptime Kuma auto-hospedada pode ser suficiente
Monitorar um serviço em outro VPS	Coloque o Uptime Kuma fora do domínio de falha do servidor monitorado quando prático
Detectar diferenças de acessibilidade regional	Use verificações independentes de múltiplas localizações
Alertar durante a falha do VPS de monitoramento	Adicione um heartbeat externo ou serviço de monitoramento independente
Monitoramento de alta disponibilidade	Desenhe uma arquitetura de monitoramento multi-sistema separada

A imagem do aplicativo não fornece monitoramento distribuído, alta disponibilidade ou um verificador externo independente. Trate-a como um ponto de monitoramento e adicione cobertura independente quando alertas perdidos tiverem um impacto significativo nos negócios.

Como você deve atualizar o Uptime Kuma?

Atualize o Uptime Kuma deliberadamente verificando a orientação oficial de lançamento, respaldando /app/data e validando a nova versão antes de confiar nela. A VoyraCloud não atualiza automaticamente as instâncias dos clientes após a criação do VPS.

Siga a orientação de atualização do Uptime Kuma que se aplica à versão principal instalada e ao método de implantação. Antes de uma atualização:

Leia as notas de lançamento e os requisitos de migração.
Registre a versão do aplicativo atualmente em execução.
Crie e verifique um backup fora do servidor de /app/data.
Confirme espaço livre em disco suficiente.
Planeje uma janela de manutenção para uma instância de monitoramento importante.
Use uma versão específica aprovada em vez de uma tag flutuante não revisada.
Inicie a instância atualizada e revise seus logs.
Teste o login do administrador, vários tipos de monitor, uma notificação, uma página de status e recuperação de reinicialização.
Mantenha um plano de reversão compatível com as alterações de banco de dados descritas pelo lançamento.

Não assuma que reverter a imagem do contêiner é sempre suficiente. Uma migração de versão principal pode alterar dados do aplicativo, então a recuperação pode exigir o backup de dados pré-atualização, bem como a versão anterior da imagem.

Atualizações do sistema operacional, atualizações do Docker, atualizações do proxy reverso e renovação de certificado são responsabilidades separadas. Um contêiner Uptime Kuma atual não torna o resto do servidor atual.

Erros comuns a evitar

A maioria dos erros de implantação do Uptime Kuma vem da exposição da inicialização, superestimação de um local de monitoramento ou tratamento do armazenamento persistente como um plano operacional completo. Evite esses erros:

Publicar a porta 3001 antes de criar o administrador. Mantenha-a no localhost e use o túnel SSH.
Deixar o painel em HTTP público. Use HTTPS confiável para qualquer acesso público.
Esquecer os cabeçalhos de proxy do WebSocket. A interface pode carregar, mas falhar em atualizar corretamente.
Hospedar sob um subdiretório. Use um domínio ou subdomínio dedicado.
Executar /app/data ativo no NFS. Mantenha-o em armazenamento local compatível.
Chamar a persistência de reinicialização de um backup. Armazene cópias testadas fora do VPS.
Assumir que uma página de status cria monitoramento independente. Ela é apresentada pela mesma instância do Uptime Kuma.
Monitorar um VPS apenas a partir dele mesmo. Uma falha completa do servidor pode silenciar tanto o serviço quanto seu monitor.
Tratar 20 monitores como um máximo ou mínimo garantido. É uma carga de validação definida, não um resultado de capacidade universal.
Esperar que a entrega de notificações seja garantida. A disponibilidade do provedor, credenciais, cotas, roteamento e o host de monitoramento são todos importantes.
Habilitar cada integração sem um proprietário. Configure apenas canais que alguém teste e responda.
Atualizar sem uma cópia de dados restaurável. Faça backup de todos os dados do aplicativo antes de mudar de versão.

FAQ

Posso auto-hospedar o Uptime Kuma sem instalá-lo manualmente?

Sim. A imagem do aplicativo VoyraCloud fornece uma instância do Uptime Kuma pré-instalada em um Cloud VPS ou Residential IP VPS elegível. Você ainda cria o primeiro administrador, adiciona monitores, configura notificações e gerencia segurança, atualizações, backups e acesso público.

Por que `http://127.0.0.1:3001` é mostrado em vez do IP do servidor?

O endereço local impede que a página de configuração do administrador não inicializada seja exposta diretamente à internet. Estabeleça o túnel SSH a partir do seu computador, mantenha a sessão aberta e, em seguida, navegue até a URL local. O túnel encaminha com segurança sua conexão de navegador para o Uptime Kuma no VPS.

Posso expor a porta `3001` diretamente à internet?

A exposição direta não é o caminho de produção recomendado. Mantenha o serviço vinculado ao localhost e use um proxy reverso com um nome de host dedicado, suporte a WebSocket, HTTPS confiável e uma política de acesso apropriada. A imagem do aplicativo não configura automaticamente esse caminho público.

O Uptime Kuma inclui SMS, email, Slack ou outros serviços de notificação gratuitos?

Não. O Uptime Kuma pode se integrar a muitos provedores de notificação, mas você fornece e gerencia a conta e as credenciais do provedor. Preços de terceiros, cotas, disponibilidade e entrega de mensagens estão fora da imagem do aplicativo e podem mudar.

Um VPS de 1 GB é suficiente para o Uptime Kuma?

Pode ser um ponto de partida elegível apenas após a validação da imagem definida passar, mas a capacidade real depende da sua carga de trabalho. O perfil inicial usa 20 monitores em intervalos de 60 segundos por 24 horas. Mais monitores, intervalos mais curtos, respostas maiores, histórico mais longo, serviços extras ou uso mais intenso do painel podem exigir mais memória, CPU e armazenamento.

O Uptime Kuma fornece alta disponibilidade ou monitoramento externo?

Não. Esta imagem fornece uma instância do Uptime Kuma auto-hospedada em um VPS. Alta disponibilidade, verificações distribuídas e monitoramento externo independente requerem sistemas e arquitetura adicionais que não estão incluídos.

O Uptime Kuma me alertará se seu próprio VPS falhar?

Pode não alertar, porque o processo que envia o alerta pode falhar com o VPS ou seu caminho de rede. Use um heartbeat externo ou uma localização de monitoramento independente quando detectar falha do host do Uptime Kuma for importante.

O que devo respaldar?

Faça backup de todos os dados persistentes mapeados para /app/data e armazene a cópia de recuperação fora do VPS. Proteja o backup, pois ele pode conter configuração de monitoramento e segredos de notificação, e teste uma restauração em vez de assumir que um conjunto de arquivos copiados é utilizável.

A VoyraCloud atualiza automaticamente o Uptime Kuma?

Não. Novos recursos do VPS recebem a versão do aplicativo aprovada para a imagem no momento da criação, enquanto atualizações posteriores são gerenciadas pelo cliente. Revise as instruções oficiais de atualização, faça backup de /app/data e teste a instância atualizada antes de depender dela.

Conclusão

Auto-hospede o Uptime Kuma quando você quiser um painel de monitoramento direto, verificações configuráveis, notificações e páginas de status sob sua própria administração. Comece de forma privada através do túnel SSH, desenhe monitores em torno de modos reais de falha, mantenha /app/data em armazenamento local persistente, faça backup fora do VPS e adicione um proxy reverso capaz de WebSocket com HTTPS confiável apenas quando o acesso público for necessário.

Uma instância é útil para muitas pequenas necessidades de monitoramento, mas continua sendo um ponto de observação com um domínio de falha. Adicione monitoramento independente quando o próprio host do Uptime Kuma, a acessibilidade regional ou a continuidade do alerta também precisarem ser cobertos.

Use a imagem do aplicativo VoyraCloud para Uptime Kuma para começar a partir de um ambiente VPS pré-instalado da VoyraCloud, mantendo acesso, dados, notificações e operações sob seu controle.