Sua infraestrutura. Seus dados. Suas chaves.
O Cronable foi feito para rodar como uma parte confiável da sua própria stack. Veja exatamente como ele mantém sua automação, seus segredos e seu histórico sob o seu controle.
On-premises por design
O Cronable instala na sua própria máquina — um app de desktop para Mac ou Windows, ou um servidor sob o systemd/launchd. Não há camada SaaS nem dependência de nuvem. As chamadas de saída rotineiras são uma verificação periódica de licença — que confirma sua assinatura e reporta contagens simples de tarefas e usuários — e uma verificação de novas versões assinadas; e, apenas se você os ativar, uma conexão de saída para o relay hospedado da Cronable para webhooks de entrada ou controle remoto. Sua carga de trabalho — definições de tarefas, segredos, execuções e saídas — fica na máquina e nunca é enviada para nós. A única exceção é uma sessão de controle remoto ativa: o tráfego do painel dela é retransmitido pela nossa borda de rede (a mesma confiança de qualquer proxy hospedado), com a criptografia de ponta a ponta até a sua própria máquina como uma opção Enterprise planejada.
Segredos e credenciais criptografados em repouso
Os valores dos segredos são criptografados com AES-256-GCM usando uma chave derivada da sua própria chave de criptografia (scrypt com um salt aleatório por instalação). Credenciais tipadas — chaves de API, tokens bearer, autenticação básica, cabeçalhos personalizados e strings de conexão do Postgres — vivem no mesmo cofre criptografado e são referenciadas por nome, nunca coladas em arquivos de tarefa. Nada é gravado no git e nada sai da sua máquina. Você faz o backup da chave separadamente — perca-a e os segredos ficam irrecuperáveis por design.
Mascarados em cada log e stream
Os valores resolvidos de segredos e credenciais são ocultados como «***» em arquivos de log, na saída das tarefas e no stream de logs ao vivo — mesmo quando um valor é dividido entre trechos do streaming. O que roda na sua máquina fica na sua máquina.
Autenticado e com privilégio mínimo
O console web exige logins por usuário com hashing de senha argon2id e bloqueio contra força bruta. O motor se vincula ao localhost por padrão e deve rodar como um usuário dedicado de baixo privilégio. Chamadas servidor-a-servidor usam um token bearer privado; os navegadores usam um cookie de sessão de curta duração — e sair, ou uma sessão expirar, encerra até os streams de logs ao vivo abertos em segundos. As senhas também precisam passar por uma verificação de robustez — um comprimento mínimo mais um teste de previsibilidade — para que as fracas ou fáceis de adivinhar sejam rejeitadas. A autenticação de dois fatores (TOTP) opcional adiciona um código de uso único de um app autenticador como o Google Authenticator, com códigos de recuperação caso você perca o dispositivo; ela é obrigatória para usar o acesso remoto, portanto uma máquina só pode ser aberta ao painel hospedado por uma pessoa que a tenha ativado.
Acesso da equipe com funções
O console web é multiusuário, com quatro funções ordenadas — visualizador (somente leitura), editor (cria tarefas, segredos e execuções), administrador (gerencia usuários, funções e configurações) e proprietário, a primeira conta da instalação. Os administradores adicionam e removem usuários, definem a função de cada pessoa, redefinem uma senha ou um dispositivo de dois fatores e revogam o acesso em Configurações → Usuários — assim, um colega que sai perde o acesso na hora e ninguém compartilha um login. Instalações mais restritas podem ativar mais controles: a divisão em níveis de execução restringe quem pode criar tarefas que executam comandos, e a aprovação de alterações adiciona uma revisão de quatro olhos, de modo que um segundo administrador precisa aprovar uma alteração pendente de uma tarefa ou de um segredo antes que ela entre em vigor.
Single sign-on via OIDC
Traga seu provedor de identidade — Okta, Entra ID, Google, Keycloak — pelo fluxo de código de autorização do OIDC com PKCE e verificação completa do ID token. Os logins via SSO precisam mapear para uma conta local existente: nada é provisionado automaticamente, e os erros do provedor aparecem como mensagens fixas e amigáveis, em vez de redirecionamentos crus.
Uma trilha de auditoria que você realmente consegue ler
Logins e tentativas malsucedidas, alterações de segredos e credenciais, edições de tarefas, atualizações de configuração e sincronizações do git são registrados em uma trilha de auditoria somente-anexação — apenas nomes e metadados, nunca valores — visível e filtrável direto no console em Configurações → Auditoria.
Webhooks de entrada reforçados
Os webhooks de entrada chegam ao seu daemon através do nosso relay controlado por licença, por uma conexão que o seu servidor abre para fora, então você nunca expõe uma porta — a menos que escolha deliberadamente fazê-lo. Cada hook é vinculado à sua licença — nenhum outro cliente pode reivindicá-lo ou receber seus eventos, mesmo sabendo a URL — e protegido por um token por hook armazenado apenas como um hash SHA-256 e verificado em tempo constante. A URL precisa de pelo menos 32 caracteres imprevisíveis mais esse token; errado, ausente, desativado ou desconhecido, todos retornam o mesmo 401 genérico, e sondagens repetidas de um IP são temporariamente banidas — então não há nada para enumerar nem nada para atacar por força bruta. Os tokens são revelados uma vez na criação e rotacionáveis em um clique. Se preferir que as cargas de entrada nunca passem pelos nossos servidores, você pode dispensar o relay e servir o seu próprio endpoint HTTPS — esse é o único caso em que você realmente abre uma porta, e os webhooks chegam então diretamente à sua máquina.
Histórico auditado por git e reversível
Cada definição de tarefa é um arquivo em um repositório git que é seu. Cada alteração é um commit — totalmente comparável, atribuível e reversível. Seu histórico de tarefas é auditável com as ferramentas que sua equipe já usa. Ao vincular um repositório para sincronização bidirecional, o Cronable aceita apenas um privado — ele recusa um repositório público e interrompe a sincronização se um repositório vinculado for tornado público depois — para que suas definições de jobs nunca fiquem legíveis publicamente.
Honestos sobre o limite de confiança
O trabalho do Cronable é executar comandos, agentes de IA e HTTP em seu nome, então trate-o como um shell na máquina. As expressões rodam em um sandbox de proteção contra erros, não em um limite reforçado — nunca o alimente com entrada não confiável. Ajudamos você a implantá-lo com privilégio mínimo e isolamento de rede sensato.
Rode-o atrás do seu firewall.
Tem requisitos de segurança a cumprir? Conte-nos sobre o seu ambiente e vamos percorrer juntos a implantação, o hardening e os controles de acesso.
Cronable, e nunca sai da sua máquina.