コンテンツにスキップ
タイプアンロックステージ本番環境難易度シンプルジョブタスクを自動化対象DevOps & インフラ対象開発チームサービスCronサービスExecHoody の利点HTTP ネイティブ
タイプアンロックステージ本番環境難易度シンプルジョブタスクを自動化対象DevOps & インフラ対象開発チームサービスCronサービスExecHoody の利点HTTP ネイティブ
タイプアンロックステージ本番環境難易度シンプルジョブタスクを自動化対象DevOps & インフラ対象開発チームサービスCronサービスExecHoody の利点HTTP ネイティブ
タイプアンロックステージ本番環境難易度シンプルジョブタスクを自動化対象DevOps & インフラ対象開発チームサービスCronサービスExecHoody の利点HTTP ネイティブ
ユースケースに戻る
use-cases / cert-renewal-no-ssh / hero
CRON · EXEC · NO SSH

SSH セッションなしで TLS 証明書を更新する

Hoody Cron がスケジュールを担い、Hoody Exec が更新ロジックを担います。日曜午前 04:00 に curl が発火し、certbot が走り、新しいバンドルが PATCH でプロキシに反映され、リロードが返ってきます。シェルセッションも、~/.ssh の鍵も、あなたと証明書の間の踏み台もありません。

cron ドキュメントを読む
use-cases / cert-renewal-no-ssh / lifecycle

3 つの URL、シェルなし

更新パイプライン全体は、エンドポイント 2 つと 5 フィールドのスケジュールで完結します。Cron が Exec をトリガーし、Exec が ACME を呼び出してプロキシに PATCH。応答は 200 として返ってきます。

RENEWAL LIFECYCLE1 度だけ POST · 毎週走る
01 · SCHEDULE

cron エントリを 1 つ POST

POST /users/me/entries で schedule "0 4 * * 0"、command "curl /scripts/certs/renew"。cron サービスがこれをユーザー crontab に書き込み、刻み始めます。HTTPS が通れば、世界のどこからでも 1 度だけやれば済みます。

02 · RUN

Exec がスクリプトを走らせる

日曜 04:00、cron が exec URL を curl します。Exec はスクリプトを起動し、Let's Encrypt の ACME エンドポイントと話し、http-01 チャレンジを検証し、更新したバンドルを /files に書き込みます。誰もログインせず、セッションも要りません。

03 · RELOAD

プロキシのバンドルに PATCH

スクリプトは新しい証明書と鍵を Hoody プロキシのバンドル エンドポイントに PATCH します。プロキシはホットリロードします — 再起動なし — 次の TLS ハンドシェイクから新しい証明書が提供されます。サイクル全体が 1 分以内です。

各ステップは、ターミナルから再生できる HTTP 呼び出しです — デバッグしたいなら `curl --dry-run`、ヘッダーが見たいなら `curl -i`。パイプラインはどの時点でもログイン済みセッションに依存しません。

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

2 つのエンドポイントの形

左がジョブをスケジュールする cron エントリ。右が作業を行う exec スクリプト。どちらも HTTP でアドレス可能 — どちらも監査可能で、どんなノート PC やスマホからでも再生できます。

cron · スケジュールを登録
POST · once
# 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 · 毎週走る
// 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 };

2 つの URL、1 つの日曜の朝、ゼロの SSH。cron エントリはデータです — 1 度 POST すれば、DELETE するまでそこに居続けます。exec スクリプトはファイルです — API で変更すれば、次の実行から新しいロジックが拾われます。このループのどこにも、人が機械上にいる必要はありません。

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

これが SSH の crontab に勝る理由

結果は同じ — 毎週更新される証明書 — ですが、レガシー構成にはなかった 3 つの性質を備えます。

AUTH · URL TOKEN

~/.ssh に秘密鍵がない

認証は SSH 鍵ではなく URL トークン。API でローテートすれば、古いトークンは一斉にどこでも使えなくなります。エージェントフォワーディングも、踏み台も、3 年前に CI ボックスにコピーしたことを忘れた鍵ファイルもありません。

AUDIT · HTTP TRACE

すべての更新はリクエストログ

各実行は cron ログの 1 行であり、exec ログのリクエスト行です。誰がトリガーしたか、いつ、どの証明書、どのレスポンスコード、を grep できます。プロキシからの 200 は、リロードが届いた領収書です。

DEBUG · DRY-RUN A CURL

デバッグに SSH しない

ノート PC から `curl /scripts/certs/renew?dry_run=true` で更新を再生できます。レスポンスを見て、exec の write API でスクリプトを直し、再試行。ループ全体が HTTPS の上で起きます — 本番スケジュールが使うのと同じパイプです。

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

あなたが省いたもの

数値はベンチマークではなく実際のデプロイから。形こそが重要 — 動く部品は非常に少なく、すべてが HTTP を話します。

  1. SSH SESSIONS0

    セットアップは POST。更新はスケジュール上の GET。デバッグは curl。パイプラインのどこにもシェルセッションはありません — あなたの秘密鍵がボックスに置かれることもありません。

  2. ENDPOINTS USED2

    1 つの cron エントリで実行をスケジュール。1 つの exec ルートでスクリプトを実行。3 つ目の URL — プロキシバンドルへの PATCH — はスクリプトの中にあり、証明書をリロードします。

  3. FIELDS · CRON SCHEDULE5

    標準 5 フィールド式 "0 4 * * 0" — 日曜 04:00。曜日にこだわらないなら `@weekly` でも構いません。cron サービスは両方を受け付け、ワンショット更新には自動失効も使えます。

Cron サービス: 5 フィールド式とマクロ（`@hourly`、`@daily`、`@weekly`、`@monthly`、`@yearly`）、ユーザー単位の分離、任意の `expires_at`。Exec: V8 アイソレート、Bun ランタイム、モード/タイムアウト/CORS のためのマジックコメント。ACME フローはスクリプト内で扱います — Hoody は certbot を代わりに走らせるのではなく、あなたのコードをスケジュールに乗せて走らせます。

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

更新はスケジュール上の curl — シェルセッションも、鍵も、踏み台もない。

old · 証明書失効直前の土曜new · 9 か月走り続けた cron
古いスタックはこうだったssh prod && certbot renew && systemctl reload nginx~/.ssh に鍵 · 前面に bastion · 前回再起動でも cron 行が残っていますようにという祈り
今はこう見える
exec ドキュメントを読む
use-cases / cert-renewal-no-ssh / replaces

これが置き換えるもの

本番で TLS を有効に保つ標準的な方法。どれもシェルセッションか、コントロールプレーンサービスか、その両方を要求します。cron + exec のペアはどちらも要求しません。

  • SSH + 手動 certbotシェルセッション、鍵、休暇中に忘れる更新ステップ
  • ssh-bastion + スクリプト1 行のスクリプトを走らせるためだけに維持する踏み台
  • AWS Certificate Manager（クローズドループ）無料 — ただし AWS の中でだけ — そして証明書は彼らのプロキシから出てこない
  • HashiCorp Vault PKI週に 1 度更新する証明書を発行するためのまるごとシークレット デーモン
  • Kubernetes 上の cert-managerコントローラー、CRD、Webhook — HTTP 呼び出し 2 つで済むことのために
  • 自前の更新 cron + 踏み台パイプライン踏み台上の糊付けスクリプト、CI ランナーごとの鍵、監査証跡なし
use-cases / cert-renewal-no-ssh / cta

証明書を更新するためにログインするのはやめましょう。スケジュールを 1 度 POST し、毎週日曜の朝にプロキシが自分でリロードするのを眺めましょう。

Kit ドキュメントを読む
use-cases / cert-renewal-no-ssh / related

他のユースケースを読む

夜間マイグレーションの直前にコンテナをスナップショット

02:55 UTC に発火する hoody-cron エントリが snapshots URL を curl し、アーティファクトに pre-migration-2026-05-04 という名前を付けます。5 分後にマイグレーションが実行されます。成功すればスナップショットは何もせずコストもかかりません。失敗した場合は、たった 1 つの PATCH で 30 秒以内に復元できます。

Cron·スナップショット

フリート規模で顧客ごとのサンドボックス

800 の顧客が 3 台のベアメタルサーバーに分散 — 定額の月額請求、顧客ごとのメーターなし。各テナントは独自のカーネル名前空間、ファイルシステム、URL を持つ本物のコンテナを取得します。ほとんどはほとんどの時間アイドル状態で、すでに支払っているサーバーに上乗せでかかる費用はゼロです。

コンテナ·スナップショット·Exec