Pular para o conteúdo
Criar conta grátis
Criar conta grátis
Hospedagem própriaServidor disponível mediante solicitação

Rode o servidor onde você já trabalha

O servidor do Crunu foi feito para ser cego. Em app.crunu.com ou numa infraestrutura que você controla, ele armazena texto cifrado, chaves públicas e registros assinados, e não tem nenhuma chave que descriptografe um único valor.

Criar conta grátisLer o guia de hospedagem própria
Exemplo. A Kiteline é uma empresa fictícia.

O que você precisa antes

  • 1Node.js 24 e o código do servidorAs ferramentas do operador server-init, doctor e crunu-server rodam nele. O servidor não é um download público: escreva para support@crunu.com para recebê-lo.
  • 2Um endereço que você vai manterAs assinaturas de login, os links de compartilhamento, as passkeys e os agentes ficam vinculados ao domínio do servidor, então ele não pode mudar depois.
  • 3Um lugar seguro para o .envUm gerenciador de senhas serve. O arquivo guarda a SERVER_KEY, o principal segredo do servidor.

Uma vez por servidor

Instalar

Cinco etapas levam você de uma máquina ou conta de nuvem vazia a um servidor rodando, com o primeiro Owner.

  1. 1Decida quem opera o servidor

    A criptografia acontece no navegador e no agente crunu, nunca no servidor. Por isso, escolher entre app.crunu.com e um servidor próprio é decidir quem o opera e quem vê os metadados dele. Em nenhum dos casos alguém do lado do servidor consegue ler os seus valores.

    • app.crunu.com: o Crunu opera o servidor no Cloudflare Workers com um banco de dados D1, grátis durante o acesso antecipado
    • Servidor próprio: você o opera, paga o seu provedor de plataforma, e só você vê os metadados dele
    • Metadados são os nomes de organizações, projetos, ambientes e máquinas, os endereços de e-mail, o log de auditoria e o tamanho e o horário das versões
    Exemplo. A Kiteline é uma empresa fictícia.

  2. 2Gere as configurações do servidor

    O server-init grava um arquivo .env com uma nova SERVER_KEY, um BOOTSTRAP_TOKEN de uso único para o primeiro Owner e um CRON_SECRET. Só o seu usuário consegue ler o arquivo.

    • Guarde uma cópia no seu gerenciador de senhas na mesma hora
    • Perder a SERVER_KEY desconecta todo mundo e quebra os links de compartilhamento. Os dados dos ambientes continuam intactos

  3. 3Escolha uma de cinco plataformas

    Todas as plataformas rodam o mesmo servidor com o mesmo esquema de banco de dados, e o app web vem embutido nele. Cada script de deploy confere o .env com o mesmo código que o servidor usa ao iniciar, então uma configuração errada interrompe o deploy com uma mensagem clara.

    • Docker no seu próprio servidor: o Caddy emite os certificados TLS, e o Cloudflare Tunnel funciona quando você não quer nenhuma porta aberta
    • Cloudflare Workers: o plano Free serve para um teste, mas uma equipe precisa do Workers Paid, porque o Free dá a cada requisição 10 ms de CPU
    • Vercel: as previews ganham banco de dados e chave do servidor próprios, e no plano Hobby a limpeza roda no máximo uma vez por dia
    • AWS App Runner só em contas da AWS que já o usam: a AWS fechou o serviço para novos clientes, e o Crunu não tem script para o Amazon ECS Express Mode
    Exemplo. A Kiteline é uma empresa fictícia.

  4. 4Faça o deploy com o script da plataforma

    Um comando por plataforma monta o servidor e faz o deploy. Os segredos chegam à plataforma pelo stdin ou por um arquivo que só você consegue ler, nunca por argumentos de comando nem pela saída. O próprio servidor aplica as migrações do banco de dados ao iniciar.

    • O mesmo script instala a primeira versão e todas as atualizações
    • No Cloudflare, código e segredos vão juntos como uma só versão, então um deploy que falha não muda nada

  5. 5Crie o primeiro Owner

    Abra o endereço do servidor e digite a chave de inicialização do .env. As chaves da sua conta e da organização são criadas no seu navegador, e a chave de inicialização deixa de funcionar depois desse único uso. Em seguida, guarde o seu Emergency Kit, crie um código de recuperação e ative um segundo fator.

    • Sem o Emergency Kit e a sua senha, um dispositivo novo não consegue entrar
    • Todas as outras pessoas entram por convite

Todo dia

Operar

Com o servidor no ar, três hábitos o mantêm saudável: uma verificação depois de cada deploy, monitoramento e um backup diário.

  1. 6Confira o deploy com o doctor

    O doctor verifica um servidor em funcionamento pelo lado de fora: saúde, TLS e validade do certificado, cabeçalhos de segurança, compressão das respostas da API, o relógio do servidor, o release do agente, as migrações, a limpeza e o endereço do cliente atrás de proxies.

    • Um resultado geral e um código de saída, para caber no cron e no CI
    • --json gera uma saída legível por máquina

  2. 7Acompanhe saúde, métricas e alertas

    O GET /v2/health funciona com verificadores de disponibilidade como o UptimeRobot ou o Better Stack. O GET /v2/status com um token de operador devolve métricas em JSON ou no formato do Prometheus, sem valores e sem endereços de e-mail. Os alertas chegam à sua equipe por um webhook assinado ou por e-mail.

    • Slack, Microsoft Teams e PagerDuty se conectam pelos webhooks de entrada deles
    • No Cloud Run e no App Runner, a limpeza só roda quando há tráfego, então os alertas baseados em estado podem chegar com atraso

  3. 8Faça backup no armazenamento que preferir

    O crunu-server export grava o banco de dados inteiro num único arquivo compactado. Ele não contém valores abertos, então você pode guardá-lo em qualquer provedor. Mantenha o arquivo .env separado dele, no seu gerenciador de senhas.

    • Exporte todo dia e guarde 30 dias. O servidor não tem agendador embutido, e o guia de backups traz uma linha de cron pronta para Docker
    • Confira uma cópia todo mês, ou melhor, restaure-a num banco de dados de teste
    • Uma restauração desfaz tudo o que veio depois da cópia, e os dispositivos que viram dados mais novos recusam o estado mais antigo até você redefini-los

Quando precisar

Alterar

Mudar de plataforma, rotacionar a chave do servidor e atualizar usam os scripts de deploy e o crunu-server que você já tem.

  1. 9Mude de plataforma com um único arquivo

    Exporte o banco de dados, confira o arquivo, importe-o num banco de dados vazio na nova plataforma e faça o deploy lá com o mesmo .env; depois, troque o DNS. Qualquer uma das seis configurações pode migrar para qualquer outra, nos dois sentidos.

    • Mantenha a mesma SERVER_KEY e o mesmo endereço. Só o registro DNS muda
    • As máquinas continuam rodando com as variáveis que já têm durante a concessão, até 24 horas
    • Mantenha a plataforma antiga por uma semana. Voltar é uma mudança de DNS
    Exemplo. A Kiteline é uma empresa fictícia.

  2. 10Rotacione a chave do servidor sem desconectar ninguém

    Durante uma rotação, a chave anterior continua funcionando, os tokens recebem um novo hash com a chave nova à medida que são usados, e o rotate-key criptografa de novo os segredos TOTP e os canais de alerta. As pessoas continuam conectadas, e os links de compartilhamento continuam abrindo. Os dados dos ambientes nunca são criptografados com essa chave.

    • Quatro etapas: new-server-key, deploy, rotate-key, drop-previous-key
    • Rotacione quando o .env pode ter sido visto, depois de uma mudança de plataforma ou uma vez por ano

  3. 11Atualize sem uma etapa separada de migração

    Uma atualização usa o mesmo script de deploy da primeira instalação, e o servidor aplica as migrações ao iniciar. As migrações só acrescentam, e as já lançadas são protegidas por checksums, então você pode voltar o código para uma versão anterior sem voltar o banco de dados.

    • Os releases web são assinados, e o servidor entrega a assinatura para que um site publicado possa ser conferido com ela
    • Não é possível voltar para uma versão anterior à 6.0

Guias para operadores

Perguntas sobre hospedagem própria

O que os operadores perguntam antes de rodar o próprio servidor.

Outra dúvida? Escreva para support@crunu.com.

O app.crunu.com é o mesmo software que eu posso hospedar?

Sim. O app.crunu.com roda o mesmo servidor do Crunu, com deploy no Cloudflare Workers e um banco de dados D1.

Quem opera o app.crunu.com consegue ler os meus segredos?

Não. O servidor armazena texto cifrado e não tem chave para descriptografá-lo. Como operador, o Crunu vê os metadados: nomes de organizações, projetos, ambientes e máquinas, endereços de e-mail, o log de auditoria e o tamanho e o horário de cada versão. Um risco vale para todo cofre baseado na web: um servidor comprometido poderia entregar um app web modificado que vê a sua senha e a sua Secret Key quando você entra. Releases assinados e uma política de segurança de conteúdo rígida reduzem esse risco, e a página de limitações explica o resto.

Posso passar do app.crunu.com para um servidor próprio depois?

Não num único passo. O arquivo que leva um servidor de uma plataforma para outra é gerado a partir do banco de dados inteiro do servidor, e no app.crunu.com só o operador tem acesso a ele. A qualquer momento, você pode exportar cada ambiente que consegue ler como um arquivo .env ou baixar uma cópia offline, e depois adicionar esses arquivos ao seu próprio servidor. O histórico, as configurações de acesso e o log de auditoria não vão junto dessa forma.

A AWS é compatível?

Em parte. O script do Crunu faz o deploy no AWS App Runner, mas a AWS fechou o App Runner para novos clientes, então ele só funciona em contas que já o usam. O Crunu não tem script para o Amazon ECS Express Mode, o serviço que a AWS recomenda no lugar dele. Com uma conta nova da AWS, escolha o Cloud Run, a Vercel ou um servidor próprio.

O que acontece com as máquinas e o CI durante uma mudança de plataforma?

As máquinas continuam rodando com as variáveis que já têm, enquanto durar a concessão, até 24 horas. Peça à equipe para não alterar ambientes nem convidar pessoas por 15 a 30 minutos durante a troca: o que for gravado no servidor antigo depois da exportação não chega ao novo.

Posso rodar várias instâncias do servidor para alta disponibilidade?

No Postgres, várias instâncias podem compartilhar um banco de dados: as gravações no log de auditoria são serializadas por um lock do banco de dados. Não existe guia para um cluster de failover, então planeje-o como uma configuração sua.

As ferramentas do operador têm interface em inglês?

Sim. O server-init, o doctor e o crunu-server mostram as mensagens em inglês, ou em russo quando o CRUNU_LANG ou o locale do sistema estiver em russo.

Como eu consigo o servidor para hospedar por conta própria?

O servidor não é publicado como download público. Escreva para support@crunu.com e diga qual plataforma pretende usar.

Experimente o Crunu primeiro no serviço hospedado

Grátis durante o acesso antecipado. A sua senha e a sua Secret Key são criadas no seu navegador e nunca chegam ao servidor.

Criar conta grátisPerguntar sobre hospedagem própria