Skip to main content

ローンチ前チェックリスト

公開前にこれを実行してください。各項目は以下の関連セクションにリンクしています。
1

マルチインスタンス向けリプレイ保護の設定

デフォルトのアダプターはインメモリのみです。複数のプロセス(Gunicornワーカー、PM2クラスター、Kubernetes)を実行する場合は、SUPABASE_URL + SUPABASE_ANON_KEY を設定するか、RedisReplayAdapter を使用してください。詳細 →
2

シークレットマネージャーへの環境変数の格納

APIキーをハードコードしないでください。ローカルでは .env を使用し、本番環境ではシークレットマネージャーを使用してください。詳細 →
3

ヘルスチェックエンドポイントの存在

モニタリングのpingがインボイス作成をトリガーしてはいけません。有料ルートの前に /health ルートを追加してください。詳細 →
4

エラーレスポンスが内部情報を漏洩しないこと

プロバイダーエラーをキャッチし、スタックトレースではなくクリーンな503を返してください。詳細 →
5

価格が意図的に設定されていること

priceSats は実際の価値を反映する必要があります。1 sat ≈ 0.0006として、プレミアムエンドポイントに100sats0.0006 として、プレミアムエンドポイントに100 sats ≈ 0.06 は妥当です。誤って0に設定しないでください。
6

インボイスエンドポイントのアップタイムモニタリング

402レスポンスをモニタリングしてください(これはエラーではなく正常なレスポンスです)。UptimeRobotなどのツールはカスタムステータスコードの期待値をサポートしています。
7

インボイス作成へのレート制限

認証されていないリクエストはすべてLightningインボイスを作成します。レート制限がなければ、攻撃者は無料でプロバイダーのインボイスクォータを使い果たすことができます。公開デプロイ前に express-rate-limit を追加してください。詳細 →

重要: 本番環境でのリプレイ保護

デフォルトのリプレイアダプターはインメモリのみ — プロセスの再起動ごとにリセットされ、複数のサーバーインスタンスにまたがって動作しません。複数のプロセス(Gunicornワーカー、Kubernetesポッド、PM2クラスター)を使用する本番環境では、同じpreimageが2回受け入れられる可能性があります。修正方法: 環境に SUPABASE_URL + SUPABASE_ANON_KEY を設定してください。ミドルウェアは自動的にSupabaseをリプレイストアとして使用し、すべてのインスタンス間で共有されます。Redisの場合: RedisReplayAdapter を明示的に渡してください(TypeScript SDK または Python SDK を参照)。

環境変数

キーをハードコードしないでください。常に環境変数を使用してください:

支払いログ(Supabase)

VS Code拡張機能のダッシュボードとアナリティクスのために、すべての支払いをSupabaseに記録してください:

Cloudflare Workersへのデプロイ

l402-kit APIはCloudflare Workers(V8アイソレート、コールドスタートゼロ)上で動作します。インメモリのリプレイストアはアイソレートごとにリセットされます — トラフィックの多いAPIでは、リプレイ保護にCloudflare KVまたはDurable Objectsを使用してください。

Docker


ユーザーデータの削除

ユーザーが自分のデータを永久に削除できるよう、削除エンドポイントを公開してください。l402-kitバックエンドには /api/delete-data がすぐに使える形で含まれています:
VS Code拡張機能はこれをダッシュボード下部のDanger Zoneパネルとして表示します — ユーザーは確認のためにLightningアドレスを入力する必要があり、その後すべての支払い履歴とProアクセスが削除されます。この操作はサーバーサイドでSupabaseサービスキーを使用します。anonキーにはDELETE権限がありません。

エラーハンドリング

フォーマットされていない500として表面化する前に、プロバイダーエラーをキャッチしてください:
基本的なルール:
  • クライアントにスタックトレースを返さないこと — サーバーサイドでログに記録してください。
  • プロバイダーのタイムアウト(503)は一時的なものです — バックオフを使って安全に再試行できます。
  • トークンエラー(401)は一時的ではありません — 自動再試行せず、新しいインボイスを要求してください。
  • レート制限エラー(429)— retryAfter フィールドを呼び出し元に公開してください。
構造化エラーコードの完全なリストはエラーリファレンスを参照してください。

レート制限

認証されていないリクエストはすべて、LightningプロバイダーでのÀ createInvoice() をトリガーします。レート制限がなければ、誰でもエンドポイントをフラッドさせてプロバイダーのAPIクォータを無料で使い果たすことができます — 1 satも支払わずに。 L402ルートの前に express-rate-limit を追加してください:
既に支払い済みのクライアントは skip 関数によってスキップされます — 制限は新しいインボイスをトリガーする未認証の呼び出しにのみ適用されます。正当な支払い者がスロットルされることはありません。
FastAPIの場合:

ヘルスチェックエンドポイント

モニタリングツールがインボイス作成をトリガーしないよう、常に無料のヘルスチェックを追加してください:

モニタリング

追跡すべき主要メトリクス:
  • 402レスポンス率 — 正常なベースラインは高い(ほとんどの呼び出し元は支払いが必要)
  • 支払い検証率 — 支払い済みと未払いの呼び出しの比率
  • プロバイダーレイテンシーblink.createInvoice() は500ms未満であるべき
  • リプレイ試行 — スパイクはトークン再利用攻撃を示す

パフォーマンス

  • トークン検証は O(1) — 純粋な暗号処理で、DBもネットワークも不要
  • インボイス作成(402パス)はLightningプロバイダーAPIを呼び出します — 支払い前に同じエンドポイントが繰り返しヒットされることが予想される場合はキャッシュを追加してください
  • リプレイストアはインメモリの Set — マルチインスタンスデプロイメントでは、Redisに切り替えてください