Pular para o conteúdo
TipoDesbloqueadoEstágioProduçãoDificuldadeSimplesTrabalhoAutomatizar tarefaParaDevOps & infraParaEquipes de desenvolvimentoServiçosCronServiçosExecPor que HoodyHTTP-nativo
TipoDesbloqueadoEstágioProduçãoDificuldadeSimplesTrabalhoAutomatizar tarefaParaDevOps & infraParaEquipes de desenvolvimentoServiçosCronServiçosExecPor que HoodyHTTP-nativo
TipoDesbloqueadoEstágioProduçãoDificuldadeSimplesTrabalhoAutomatizar tarefaParaDevOps & infraParaEquipes de desenvolvimentoServiçosCronServiçosExecPor que HoodyHTTP-nativo
TipoDesbloqueadoEstágioProduçãoDificuldadeSimplesTrabalhoAutomatizar tarefaParaDevOps & infraParaEquipes de desenvolvimentoServiçosCronServiçosExecPor que HoodyHTTP-nativo
Voltar aos casos de uso
use-cases / cert-renewal-no-ssh / hero
CRON · EXEC · SEM SSH

Renove seus certificados TLS sem uma sessão SSH

O Hoody Cron carrega o agendamento. O Hoody Exec carrega a lógica de renovação. Domingo às 04:00 um curl dispara, o certbot roda, o novo bundle é enviado via PATCH para o proxy, e o reload é confirmado. Sem sessão de shell, sem chave em ~/.ssh, sem jump host entre você e o certificado.

Ler a documentação do cron
use-cases / cert-renewal-no-ssh / lifecycle

Três URLs, sem shell

O pipeline inteiro de renovação é dois endpoints e um agendamento de 5 campos. O Cron dispara o Exec. O Exec chama a ACME e faz PATCH no proxy. A confirmação volta como 200.

CICLO DE VIDA DA RENOVAÇÃOPOST UMA VEZ · RODA SEMANALMENTE
01 · AGENDAR

POST uma entrada de cron

POST /users/me/entries com schedule "0 4 * * 0" e command "curl /scripts/certs/renew". O serviço do cron escreve no crontab do usuário e começa a marcar. Você fez isso uma vez, de qualquer lugar com HTTPS.

02 · EXECUTAR

O Exec roda o script

Domingo 04:00, o cron faz curl na URL do exec. O Exec sobe o script, conversa com o endpoint ACME do Let's Encrypt, valida o desafio http-01 e escreve o bundle renovado em /files. Sem nó logando, sem sessão necessária.

03 · RELOAD

PATCH no bundle do proxy

O script faz PATCH do novo cert e key no endpoint de bundle do proxy Hoody. O proxy recarrega a quente — sem restart — e o próximo handshake TLS serve o novo certificado. O ciclo inteiro fica em menos de um minuto.

Cada passo é uma chamada HTTP que você pode replay de um terminal — `curl --dry-run` se quiser depurar, `curl -i` se quiser os headers. O pipeline não depende de uma sessão logada em nenhum momento.

use-cases / cert-renewal-no-ssh / mechanism

Como são os dois endpoints

À esquerda, a entrada de cron que agenda o job. À direita, o script exec que faz o trabalho. Ambos endereçáveis por HTTP — ambos auditáveis, ambos replicáveis a partir de qualquer laptop ou celular.

cron · registrar o agendamento
POST · uma vez
# register the weekly renewal
curl -X POST \
  https://cron.containers.hoody.com/users/me/entries \
  -H "Content-Type: application/json" \
  -d '[ "schedule":"0 4 * * 0", "command":"curl -fsS https://exec.containers.hoody.com/scripts/certs/renew", "comment":"weekly TLS renewal", "enabled":true ]'

# response
HTTP/1.1 201 Created
{ "id":"7a92", "schedule":"0 4 * * 0", "enabled":true }
exec · scripts/certs/renew.ts
GET · roda semanalmente
// scripts/certs/renew.ts
// @mode serverless
// @timeout 120000

const domains = ["your-app.com", "api.your-app.com", ...];

for (const d of domains) {
  const cert = await acme.order(d);
  await fetch("/api/v1/proxy/cert/bundle", {
    method: "PATCH",
    body: JSON.stringify({ d, cert })
  });
}

return { "renewed": domains.length };

Duas URLs, uma manhã de domingo, zero SSH. A entrada de cron é dado — POST uma vez e ela está lá até você dar DELETE. O script exec é um arquivo — altere via API e a próxima execução pega a nova lógica. Nada nesse loop exige uma pessoa em uma máquina.

use-cases / cert-renewal-no-ssh / powers

Por que isto vence o crontab via SSH

Mesmo resultado — um certificado renovado toda semana — com três propriedades que o setup legado nunca teve.

AUTH · TOKEN DE URL

Sem chave privada em ~/.ssh

Auth é um token de URL, não uma chave SSH. Rotacione via API e o token antigo para de funcionar em todo lugar de uma vez. Sem agent forwarding, sem bastion, sem arquivo de chave que você esqueceu que copiou para uma máquina de CI três anos atrás.

AUDITORIA · TRACE HTTP

Toda renovação é um log de requisição

Cada execução é uma linha no log do cron e uma linha de requisição no log do exec. Grepe por quem disparou, quando, qual cert, qual response code. O 200 do proxy é o recibo de que o reload aterrissou.

DEBUG · DRY-RUN COM CURL

Você não dá SSH para depurar

Replay a renovação do seu laptop com `curl /scripts/certs/renew?dry_run=true`. Veja a resposta, conserte o script via API de escrita do exec, tente de novo. O loop inteiro acontece sobre HTTPS — o mesmo cano que o agendamento de produção usa.

use-cases / cert-renewal-no-ssh / capacity

O que você pulou

Números do deployment, não benchmarks. A forma é o que importa: pouquíssimas peças móveis, todas falando HTTP.

  1. SESSÕES SSH0

    Setup é um POST. Renovação é um GET no agendamento. Debug é um curl. Não há sessão de shell no pipeline em momento algum — sua chave privada nunca precisa estar na máquina.

  2. ENDPOINTS USADOS2

    Uma entrada de cron para agendar a execução. Uma rota exec que roda o script. A terceira URL — o PATCH no bundle do proxy — vive dentro do script e recarrega o cert.

  3. CAMPOS · AGENDA CRON5

    Expressão padrão de 5 campos "0 4 * * 0" — domingo 04:00. Ou `@weekly` se você não se importa com o dia. O serviço do cron aceita ambos, mais auto-expiração para renovações de uma só vez.

Serviço de cron: expressões de 5 campos e macros (`@hourly`, `@daily`, `@weekly`, `@monthly`, `@yearly`), isolamento por usuário, `expires_at` opcional. Exec: V8 isolates, runtime Bun, magic comments para mode/timeout/CORS. Fluxo ACME tratado no seu script — o Hoody não roda o certbot por você, ele roda o seu código no agendamento.

use-cases / cert-renewal-no-ssh / punchline

Renovação é um curl no agendamento — sem sessão de shell, sem chave, sem jump host.

antigo · sábado antes dos certs expiraremnovo · o cron está rodando há nove meses
COMO ERA A PILHA ANTIGAssh prod && certbot renew && systemctl reload nginxchave em ~/.ssh · bastion na frente · reza para que a linha de cron tenha sobrevivido ao último reboot
COMO É AGORA
Ler a documentação do exec
use-cases / cert-renewal-no-ssh / replaces

O que isto substitui

Os jeitos padrão de manter TLS válido em produção. Cada um quer ou uma sessão de shell, ou um serviço de control-plane, ou os dois. O par cron-mais-exec não quer nenhum.

  • SSH + certbot manualUma sessão de shell, uma chave, um passo de renovação que você esquece quando está de férias
  • ssh-bastion + scriptUm jump host que você mantém só para rodar um script de uma linha
  • AWS Certificate Manager (closed-loop)Grátis, mas só na AWS — e o cert nunca sai do proxy deles
  • HashiCorp Vault PKIUm daemon de secrets inteiro para emitir certs que você renova uma vez por semana
  • cert-manager no KubernetesUm controller, um CRD, um webhook — para o que são duas chamadas HTTP
  • pipeline custom de renovação cron + jump hostScripts de cola num bastion, uma chave por runner de CI, sem trilha de auditoria
use-cases / cert-renewal-no-ssh / cta

Pare de logar para renovar certs. POST o agendamento uma vez. Veja o proxy se recarregar todo domingo de manhã.

Ler a documentação do kit
use-cases / cert-renewal-no-ssh / related

Leia os outros