Changelog¶

全ての重要な変更はこのファイルに記録されます。

書き方はKeep a Changelogに基づきます。
バージョンはSemantic Versioningに従います。

[Unreleased]¶

0.45.0 - 2026-10-16¶

Added¶

• [cloudfront.<name>.waf] に rate_limits を追加しました。送信元 IP ごとのレートリミット （AWS WAF の rate-based rule）を { limit, window_sec, path, action } の配列で宣言すると、 WebACL の全ルールの先頭に付きます。allow_rules の秘密ヘッダを持つ呼び手や IP allowlist 済みの IP も超過すれば止まります（block は 429 を返し、count は記録だけします）。 enable_ip_set = false の必須条件に action = "block" の rate_limits も数えるようにしたので、 「IP allowlist 無し + レートリミットだけ」の WebACL も宣言できます
• pocket waf ratelimit list --name <cf> --stage <stage> が、deploy 済みの rate rule ごとにレート超過として 追跡中の IP（WAF の managed keys）を表示します。WAF 側の反映は数分〜十数分遅れます

Changed¶

• allow_rules / rate_limits の path に使える文字を RFC 3986 の path 文字（" と \ を除く）に 制限し、* を除いた長さを 200 bytes 以内（WAF の ByteMatch SearchString の上限）に制限しました。 CloudFormation template への埋め込みを安全にし、deploy 時に失敗する宣言を手前で止めるためで、 通常の URL path には影響しません
• allow_rules / rate_limits の path の比較を URL デコード後に行うようにしました（WAF の TextTransformation URL_DECODE）。従来は /%61pi/auth/login のようにエンコードした path が /api/auth/* に一致せず、backend 側は同じ処理に到達するためレートリミットを迂回できました。 allow_rules ではエンコードした同等 path も allow の対象になります（backend の解釈と揃う方向）
• WAF の CloudFormation template のコメントを更新したため、[cloudfront.<name>.waf] を使っている既存の stack は次回 deploy で一度 update されます（ルールの内容は変わりません）
• 0.29.0 の multi-container 移行で deploy が削除する旧形式の container stack（{slug}-container）について、 削除の完了を待つようにしました（最大 5 分）。CloudFormation 側の一過性エラーで DELETE_FAILED に なった場合は、失敗したリソースと理由、再実行コマンドを表示します（deploy 自体は成功のまま終わります）。 従来は削除を開始するだけで終わっていたため、失敗に気付けませんでした。DELETE_FAILED のまま残った 旧 stack は次回 deploy でも理由付きで再検出し、削除を再実行できます

Documentation¶

• 宣言から外したまま残した 0.36 以前の backup plan は旧 vault を参照し続け、pocket cleanup-deprecated が 中止する旨と対処（plan / selection を手で削除してから再実行）を設定ガイドに追記しました

0.44.0 - 2026-10-10¶

Added¶

• [iam] namespace で、external_roles の role 名の namespace だけを上書きできるようにしました （既定は [general] namespace。SQS / secret store / S3 など他のリソース名は変わりません）。 IAM を組織で一括管理する場合に、pocket.toml を読まずに role 名を決められます
• pocket permissions role-names --stage <stage> が、external_roles で事前に作る role の名前を種別ごと （lambda / scheduler / codebuild / backup）に JSON で出力します。AWS には問い合わせません。 規則 {stage}-{project}-{namespace}-{kind}-role は互換を保つ公開仕様で、Python からは pocket.permissions.external_role_names(settings) で得られます

Changed¶

• [iam] external_roles = true の role を container 単位から種別単位に変えました。Lambda 実行 role は {prefix}lambda-role、scheduler role は {prefix}scheduler-role を全 container で共用します （0.41.0〜0.43.0 の {prefix}{container}-lambda-role / -scheduler-role から改名）。 pocket permissions roles は共用 role を 1 つにまとめ、複数 container の権限は managed policy の 和集合・同名 inline policy の Statement の和集合として出します

0.43.0 - 2026-10-09¶

Changed¶

• [iam] external_roles = true の deploy 前検査を、role の存在と信頼ポリシー（pocket の service に sts:AssumeRole を許可しているか）だけにしました。0.41.0 では managed policy と inline policy が pocket permissions roles の出力と一致することも検査していましたが、IAM を別に管理する組織では role の policy は組織の標準で組まれるため、文面一致を求めると pocket の版更新のたびに全 project の deploy が止まります。権限の充足は role の持ち主の責任とし、pocket permissions roles の出力は 「pocket が必要とする権限の仕様」として使います
• pocket permissions list は external_roles = true の stage で iam:GetRolePolicy / iam:ListAttachedRolePolicies を出さなくなりました。action_groups() の external_roles グループは空になります（キーは残ります）

0.42.0 - 2026-10-02¶

Added¶

• versioning = "deploy_hash" の route を使う staticfiles で、STATIC_URL が <route の prefix>{DEPLOY_HASH}/（例: static/{DEPLOY_HASH}/）の形でなければエラーにする Django system check（pocket.E001）を追加しました (KN1688)。0.41.0 から hash を外すのは route の prefix 直下の 1 セグメントだけなので、static/v2/{DEPLOY_HASH}/ のような形では static がすべて 403 になっていました
• get_storages() が登録し、collectstatic / runserver / check で実行されます
• pocket django deploy / promote / deploystatic は、collectstatic に Lambda と同じ DEPLOY_HASH を渡すようになりました。形が合わなければ Lambda の更新前に止まります （初回 deploy は Lambda の更新後の collectstatic で止まります）
• DEPLOY_HASH が未設定（ローカル開発で dev 等に落ちる）のときは検査しません

0.41.1 - 2026-10-02¶

Changed¶

• pocket django deploy / promote が、static を Lambda の更新より先に upload するように なりました (KN1676)。これまでは Lambda の更新の後だったため、その間に新しい URL で読まれた ファイルは upload 前の内容（新規ファイルなら 403）が返り、versioning route ではそれが ブラウザに versioned_max_age の間残りえました。pocket deploy が upload する versioning route（build / upload_dir）も同じ順序になります。
• 「deploystatic?」の確認は image の build の後、Lambda の更新の前に出ます。collectstatic が 失敗した場合、Lambda は更新されません
• 初回 deploy（bucket や CloudFront が未作成）と、SPA など versioning の無い route は 従来どおり Lambda の更新の後に upload します
• publish = "command" の場合は deploy が static を扱わないので、pocket django deploystatic を deploy より先に実行してください

Fixed¶

• is_default = true の S3 route に versioning = "deploy_hash" を付けても、hash を外す CloudFront Function が DefaultCacheBehavior に付かず、/<hash>/... の URL が 403 になっていた のを修正しました。path_pattern 付きの route と同じく、Function と専用の CachePolicy を付けます

0.41.0 - 2026-10-01¶

Added¶

• [iam] external_roles = true で、pocket が IAM role を作らず、事前に作られた role を名前で参照する モードを追加しました。deploy 権限（CI や開発者のキー）から IAM の書き込みを外したい組織向けです。 対象は Lambda 実行 / scheduler / CodeBuild / AWS Backup の 4 種の role です。
• pocket permissions roles --stage <stage> が、必要な role の名前・信頼ポリシー・managed policy・ inline policy を JSON で出力します。CloudFormation の変数は展開済みで、CreateRole / PutRolePolicy にそのまま渡せます。出力は pocket.toml と account / region だけで決まるため、 DB を作る前に最終形の role を用意できます
• deploy は何かを変更する前に、実際の role が出力と一致するかを検査し、足りない policy を示して 止まります。出力に無い policy が付いていても構いません
• pocket permissions list は、このモードでは IAM の書き込み（iam:CreateRole など）を出さず、 検査用の iam:GetRolePolicy / iam:ListAttachedRolePolicies を足します。action_groups() に external_roles グループが増えます
• 既存の stage を切り替える手順は docs の「AWS 権限 > IAM role を事前に作る」を参照してください。 Lambda 実行 role と scheduler role は別の名前になり、切り替えの deploy で CloudFormation が古い role を削除するため、その deploy だけは IAM の書き込み権限が残った状態で実行します

Changed¶

• Lambda 実行 role の DB 権限を、deploy 時に AWS から取得した ARN ではなく pocket.toml から決まる 値だけで書くようにしました。RDS の managed secret は secret:rds!cluster-* を RDS が付ける aws:rds:primaryDBClusterArn タグ（元 cluster の ARN）で、DSQL は cluster/* を pocket が付ける Name タグで絞ります。password_strategy = "static" の secret は名前で指定します。どちらも 作成時に AWS が乱数を含む ARN を決めるため、これまでは DB を作るまで role の policy が 決まりませんでした。あわせて、既定の aws/secretsmanager key で暗号化される secret には不要だった kms:Decrypt を外しました。次回 deploy で inline policy が書き換わります（権限の範囲は同じです）
• scheduler role の sqs:SendMessage の対象を、Fn::GetAtt ではなく queue 名から組み立てた ARN で 書くようにしました（同じく role を stack の外で作れるようにするため）。次回 deploy で inline policy が書き換わります（権限の範囲は同じです）

Fixed¶

• versioning = "deploy_hash" の route で、deploy のたびに数分間、新しい hash の static URL が 403 になり、その 403 がブラウザに長期間残る問題を修正しました (KN1670)。原因は 2 つでした。
• hash を外す CloudFront Function が現在の hash だけを外していたため、Lambda が新しい hash の URL を出し始めてから Function が切り替わるまでの間（container が複数あると長くなります）と、 旧 hash の HTML を開いたままの端末で、存在しないキーを読んでいました。route の prefix 直下の セグメントが git hash の形（小文字 16 進 7〜40 桁）なら、値を問わず外すようにしました。 Function は deploy ごとに変わらなくなります。DEPLOY_HASH を git hash の形でない値で 上書きしている場合は、従来どおりその値を外します
• versioning route（content_hash を含む）の cache-control: public, max-age=..., immutable を ResponseHeadersPolicy で付けていたため、403 / 404 にも付き、ブラウザがエラーを 1 年間・ 再検証なしで保存していました。viewer-response の CloudFront Function で、成功応答 （2xx / 304）にだけ付けるようにしました
• versioning = "deploy_hash" の route で、deploy して hash が変わっても CloudFront の edge キャッシュが切り替わらず、同じ名前のまま中身が変わったファイルが最大 24 時間古い内容で返り、 それがブラウザに新しい hash の URL で残りうる問題を修正しました。CloudFront のキャッシュキーは hash を外した後の URI になるため、すべての hash の URL が 1 つのキャッシュを共有していました。 外した hash をリクエストヘッダ x-pocket-deploy-hash に載せ、route 専用の CachePolicy （Managed-CachingOptimized と同じ TTL・圧縮設定）でキャッシュキーに含めるようにしました

次回 deploy で CloudFront の stack が更新されます（ResponseHeadersPolicy を削除し、Function と CachePolicy を追加します）。すでに 403 を保存してしまったブラウザは、この修正では直りません （キャッシュの消去が必要です。次の deploy で hash が変われば、新しい URL は正しく読めます）。 hash を外す対象は route の prefix の直後のセグメントだけになったため、STATIC_URL を static/{DEPLOY_HASH}/ 以外の形（hash が prefix の直後に来ない形）にしている場合は、docs の 「hash の判定」を確認してください。

0.40.0 - 2026-09-24¶

Added¶

• [<stage>.rds] に master password のローテーション窓を宣言する rotation_schedule（UTC の cron(...) / rate(...)）と rotation_duration を追加しました。AWS 既定の窓は UTC の 1 日全体で、 JST では営業時間を必ず含みます。宣言すると deploy で managed secret の窓を差分検出し、 RotateImmediately=False で当てます（cluster の作り直しや snapshot 復元で secret が作り直されても 窓が既定に戻りません）。未宣言なら従来どおり窓に触れません。password_strategy = "static" との 併用はエラーです
• deploy 権限の [rds] グループに secretsmanager:DescribeSecret / secretsmanager:RotateSecret を追加しました（上記の窓の検出と適用用）

Changed¶

• deploy の最後に、受信ドメインごとの SES 検証結果を 1 行出すようにしました (例: inbound domain mail.example.com: verification=SUCCESS (waited 95s))。既に検証済みでも waited 0s と出るため、待ったのか・既に済んでいたのかをログだけで判別できます。 manage_dns = false で未検証の場合と待ち時間切れの場合は、状態と pocket resource inbound ... status での確認方法を表示します

0.39.1 - 2026-09-22¶

Fixed¶

• [inbound.*] の受信 container に permissions_boundary を必須にしていたため、Permissions Boundary を持たない account (POCKET_PERMISSIONS_BOUNDARY_ARN / FORGE_PERMISSIONS_BOUNDARY_ARN も未設定) では deploy の事前チェックで止まっていたのを修正しました。他の機能と同じく「指定が あれば付ける」任意項目になります。受信した原本・metadata の削除禁止は実行 role の明示 Deny で 担保しており、Boundary の有無には依存しません

0.39.0 - 2026-09-21¶

更新時の作業 ([inbound.*] を使っている project)¶

• 受信ドメインの SES identity と DNS を pocket が CloudFormation で持つようになりました (下記 Changed)。pocket は既存の identity / レコードを取り込まないため、0.38.0 以前に受信口を 作った stage は、deploy の前に次を削除してください (削除から検証完了までの数分は受信が 止まります)。
  1. SES identity: aws sesv2 delete-email-identity --email-identity <domain> --region <region>
  2. 手で登録した DNS レコード: _amazonses.<domain> の TXT と、<domain> の MX その後 pocket deploy すると、受信ドメインの stack が identity / DKIM CNAME / MX を作り直し、 検証完了まで待ちます。受信スタック (bucket / rule / queue) はそのまま使われます。
• zone が別 account や外部 DNS にある場合は manage_dns = false を指定してください (指定が無く zone も見つからないと deploy はエラーで停止します)。

Changed¶

• (破壊的変更) [inbound.*] の受信ドメインを、pocket deploy だけで受信できる状態まで 持っていくようにしました (KN1537)。stage × domain ごとに「受信ドメインの stack」を作り、 SES identity (AWS::SES::EmailIdentity、Easy DKIM)・DKIM CNAME 3 本・MX を CloudFormation で 管理します。hosted zone は CloudFront の独自ドメインと同じく domain から自動で探し (hosted_zone_id_override で明示可)、deploy の最後に SES の検証完了を最大 10 分待ちます。 同じ stage の複数 inbound が同じ domain を使う場合は stack を共有します。
  • pocket resource inbound ... init は廃止しました。TXT (_amazonses) による検証も使いません。
  • 外部 DNS 向けに manage_dns = false を追加しました。identity だけを作り、登録すべき DKIM CNAME / MX は deploy の末尾と inbound ... status に表示します (検証は待ちません)。
  • 同じドメインの identity が既にある場合は取り込まず、削除コマンドを案内して停止します。 同名の MX が既にある場合も stack の作成が失敗します (稼働中の配送先を奪いません)。
  • inbound ... destroy は、その domain を使う最後の受信口なら受信ドメインの stack も 削除します。inbound の domain を変えた後の旧 stack は次の deploy が削除します。
  • deploy 権限の inbound グループが変わります: ses:GetIdentityVerificationAttributes を 外し、ses:GetEmailIdentity / ses:CreateEmailIdentity / ses:DeleteEmailIdentity / ses:PutEmailIdentity*Attributes / ses:TagResource / ses:UntagResource と route53:ListHostedZones / route53:ChangeResourceRecordSets / route53:GetChange を 追加しました。権限を絞った deploy ロールは更新してください。
• pocket が作る IAM role (Lambda 実行 / scheduler / CodeBuild / AWS Backup) の定義を 1 か所に まとめました。権限の中身は変わりませんが、テンプレートの書き方が変わるため、次回 deploy で 各 container stack の LambdaRole が更新されます (inline policy 名の Fn::Sub 除去のみ。 role の作り直しは起きず、信頼ポリシーは従来と同じ文書のままなので追加の deploy 権限も 要りません)。
• AWS Backup のサービスロールを削除する際、inline policy も列挙して削除するようにしました (iam:ListRolePolicies は従来から deploy 権限に含まれています)。

Fixed¶

• pocket resource container yaml / yaml-diff が DB (rds / dsql) と scheduler の設定を含めずに テンプレートを組み立てていたため、deploy 済みの stack と比べると実際には無い差分が出ていました。 deploy と同じ内容で表示するようにしました。

0.38.0 - 2026-09-21¶

更新時の作業 (SPA token を検証しているアプリ)¶

• verify_token の戻り値が user_id の文字列から VerifiedToken に変わります (下記 Changed)。 Python は verify_token(token) == user_id を verified.user_id == user_id に、Rust は Some(user_id) を Some(verified) → verified.user_id に書き換えてください。 SpaTokenCookieMiddleware をそのまま使っているだけなら作業は不要です。

Changed¶

• (破壊的変更) SPA token の verify_token (Python pocket.django.spa_auth / Rust pocket-spa-auth) が、有効な token に対して VerifiedToken (user_id と有効期限 expires_at) を返すようにしました。残り寿命は Python remaining_seconds / Rust remaining_secs() で取れるため、sliding refresh のために token 文字列を split して 内部形式に依存する必要がなくなります。docs の sliding refresh 例もこれに合わせました。
• DLQ / inbound 配送アラートの email 購読が、topic はあるのに見つからない場合 (未確認のまま 確認期限の 3 日を過ぎて SNS が自動削除した場合など) は、pocket status に NotSubscribed と 表示し、deploy 後の警告で aws sns subscribe による再購読コマンドを案内するようにしました。 従来は topic 未作成と同じ「Check the container stack deployment」の警告で、原因が読み取れませんでした。

0.37.0 - 2026-09-18¶

更新時の作業 (AWS account を複数の stage / project で共有している場合)¶

1. 同じ AWS account を使うすべての stage・project を、この版以上の pocket で deploy します (backup の保存先・ロール、CodeBuild のロールは deploy / ビルド時に自動で新しい名前へ切り替わります)。
2. その後、account / region ごとに 1 回 pocket cleanup-deprecated --stage=<stage> を実行し、 旧バージョンが残した共有リソース (backup vault pocket-backup、IAM role forge-pocket-backup-role) を削除します。未更新の stage が残っていれば、参照を検出して中止します。 旧 vault に recovery point が残っている間は vault を残し、すべて失効する日付を案内します (--delete-recovery-points でデータごと削除できます)。

この版以降の最初の deploy は、stage 単位の backup サービスロールを新規に作成します。deploy 権限が Permissions Boundary 付きのロール作成だけを許している account では、deploy を実行する環境 (CI の deploy job を含む) に POCKET_PERMISSIONS_BOUNDARY_ARN か permissions_boundary の設定が無いと iam:CreateRole の AccessDenied で止まります。

Added¶

• pocket cleanup-deprecated を追加しました。旧バージョンが残した account 単位の共有リソースを、 どの stage からも参照されていないことを検査した上で削除します (--dry-run / -y 対応)。

Changed¶

• AWS Backup の vault とサービスロールを、account 共有の固定名 (pocket-backup / forge-pocket-backup-role) から stage 単位の名前 ({stage}-{project}-{namespace}-backup / …-backup-role) に改めました。所有者のいない共有物だったものが stage の所有物になり、 pocket destroy がサービスロールも削除するようになります (vault と recovery point は 従来どおり残します)。更新後の最初の deploy が plan の保存先と selection のロールを 自動で切り替えるため、手作業は不要です。 旧 vault の recovery point は移動されず、取得時の保持期限で失効するまで pocket backup cleanup / destroy の件数表示の対象外になります (復元には使えます)。 旧 vault・旧ロールは他 stage / project と共有のため deploy / destroy では削除せず、 pocket cleanup-deprecated で削除します (上の「更新時の作業」を参照)。
• CodeBuild のサービスロール名から、pocket の命名規約と無関係だった forge- prefix を 外しました (forge-{prefix}codebuild-role → {prefix}codebuild-role)。次のビルドで 新しいロールを作って CodeBuild project を付け替え、旧ロールは pocket が削除します。 IAM の role 名を forge-* で絞っている deploy role は、許可パターンの更新が必要です。

0.36.0 - 2026-09-18¶

Changed¶

• pocket resource inbound ... init は共有の receipt rule set を作成・有効化しなくなりました (KN1496)。 receipt rule set は account/region で 1 つしか active にできない共有物のため、project 単位の 道具である pocket からは触りません。active なセットが無い場合、init と deploy は default-rule-set を作成・有効化する AWS CLI の手順を案内して停止します。active なセットが あれば名前を問わずそのまま使う点は従来どおりです。これに伴い init の確認プロンプトが 無くなり、ses:ListReceiptRuleSets / ses:CreateReceiptRuleSet / ses:SetActiveReceiptRuleSet は pocket の実行主体に不要になりました。0.35.0 の init で作成済みの pocket-inbound は そのまま使い続けられます。

Added¶

• pocket resource inbound ... init --format json で、登録すべき DNS レコード (TXT / MX) と active な rule set 名・検証状態を機械可読に出力できます (KN1496)。
• pocket resource inbound ... destroy に -y / --yes を追加しました (KN1496)。確認は 他コマンドと同じ assume-yes の仕組みを通るようになり、CI や LLM から非対話で実行できます。

0.35.0 - 2026-09-14¶

Added¶

• [inbound.<name>] によるSES受信を追加しました。原本・受信情報の保存、 SNS→SQS配送、DLQ・EventBridge対応の通知、初期設定・照合・コピー・取り込みCLIを備えます (KN1449)。 条件付き保存に必要なboto3の下限を1.35.2へ更新しました。
• magic-pocket-rs に feature inbound を追加しました (KN1449)。Python の pocket.inbound と同じ契約で、SNS/SES 通知の検証と原本の版・hash・完全な通知の 条件付き保存を行ってから利用側の処理を呼ぶ worker ヘルパ (Receiver / process_inbound_records / load_import) を Rust の container からも使えます。
• Django に依存しない pocket build --stage=<stage> を追加しました。 pocket django build は同じ処理の別名として維持します (KN1448)。

Changed¶

• Lambda 環境変数 DEPLOY_HASH を、CloudFront の deploy_hash route の有無に関係なく 全 container に常に注入するようにしました (KN1450)。route を撤去しても他 container の version 表示・Sentry release 等の版識別が消えなくなります。envs に DEPLOY_HASH を 明示している場合はそちらが優先されます。

Fixed¶

• pocket destroy が 0.29.0 以前の旧命名 ({slug}-container / {prefix}lambda) の container stack・ECR repository・log group を検出して削除対象に含めるように しました (KN1456)。移行 deploy を経ずに旧 stack だけ消す (region 移設・廃止) ケースで、現行命名が NOEXIST でも取りこぼしません。
• [neon] 宣言があっても NEON_API_KEY が無い環境では、pocket status / pocket destroy が Neon の解決 (401) で止まらず warning を出して続行するように しました (KN1456)。stack の確認・削除に Neon の資格情報は不要です。
• 削除直後の同名 bucket (region 移設で旧 region を destroy した直後など) の CreateBucket が OperationAborted で拒否された場合、deploy が 30 秒間隔で最長 1 時間まで待って再試行するようにしました (KN1454)。state bucket と [s3] bucket の両方が対象で、進捗は stderr に出ます。
• SPA gate (require_token) の CloudFront Function が pocket-spa-token cookie の 値を decodeURIComponent してから検証するようにしました (KN1458)。axum-extra の CookieJar 等で : が %3A に percent-encode された cookie でも 302 にならなく なります。不正な percent-encoding はログインへ redirect します。
• VPC 削除前にスタック外の ENI / SG を検知し、CloudFormation の失敗理由を リソース単位で表示するようにしました。VPC / RDS の削除待機を30分に延長し、 削除中に再実行した場合は待機を再開します (KN1447)。
• VPC の resource コマンドに --stage を追加し、stage 別の VPC 宣言を撤去時にも 選択できるようにしました。宣言を消す前に削除する手順も明記しました (KN1443)。
• API Gateway handler への最後の CloudFront route を削除した際に、参照中の Export を先に削除しようとして deploy が rollback する問題を修正しました (KN1444)。API が存在する間は route の有無に関係なく Export を維持します。 handler / API 自体の撤去は、先に route を削除して deploy してから行ってください。

0.34.1 - 2026-09-08¶

Fixed¶

• DLQ アラートの email 購読が unsubscribe 済み (SubscriptionArn=Deleted) の とき、deploy 後の警告と pocket status が Confirmed と誤表示していたのを 修正しました (状態 Deleted として警告します)。実 ARN のときだけ確認済みと 判定し、再購読で Deleted の残骸と PendingConfirmation が並ぶ場合は 後者を採ります。あわせて、メールスキャナが確認リンクと unsubscribe リンクを 自動クリックして購読が勝手に解除されるケースの対処 (aws sns confirm-subscription --authenticate-on-unsubscribe true) を docs に記載しました

0.34.0 - 2026-09-07¶

Changed¶

• 破壊的変更: SQS の DLQ アラート宣言 (sqs.dead_letter_alert) を必須に しました (KN1110)。sqs = {} を持つ既存の pocket.toml は設定ロード時に エラーになります。通知するなら sqs = { dead_letter_alert = { email = "ops@example.com" } }、意図的に 監視しないなら sqs = { dead_letter_alert = { enabled = false } } を 宣言してください。email 宣言時は handler ごとに SNS topic + email 購読 + DLQ の CloudWatch アラーム (ApproximateNumberOfMessagesVisible >= 1、 復旧の OK 通知つき) を生成します。SNS の email 購読は宛先が確認メールを 踏むまで通知が届かないため、未確認のあいだは deploy の最後と pocket status に警告を出します。背景: pocket は queue / DLQ を自動生成する 一方で「DLQ に溜まったこと」を知らせる手段が無く、example-tidb で DLQ に 1,072 通が 11 日間気づかれず滞留する実害がありました。deploy ロールには sns:* / cloudwatch:* が追加で必要です (docs/permissions/aws.md)

0.33.0 - 2026-09-07¶

Changed¶

• get_databases() の持続接続 (CONN_MAX_AGE + CONN_HEALTH_CHECKS) を TiDB 限定から pocket 管理の全 DB (TiDB / Neon / RDS) に広げました (KN1351)。 接続確立コスト (TLS handshake 含む) は Lambda + TLS 必須 DB に共通のためです。 既定値は「無期限 (None)」から「300 秒」に変更しています (接続の生存期間を 有界にする保険。TiDB も同様)。get_databases(conn_max_age=...) で調整でき、 None = 無期限 / 0 = 従来の毎リクエスト接続。psycopg の pool (OPTIONS["pool"]) を使う場合は conn_max_age=0 を渡してください (Django が併用を ImproperlyConfigured で弾きます)。ローカル開発 (stage 解決なし) の DB には適用しません

0.32.1 - 2026-09-07¶

Fixed¶

• use_vpc = false の container が [rds] のある stage で CreateStack の validation ("Unresolved resource dependencies [LambdaSecurityGroup]") に 落ちていたのを修正しました (KN1352)。VPC 外 Lambda は RDS SG への ingress 自体が不要なため、LambdaRDSAccess を出力しません。あわせて、この組合せでは 「container が RDS に到達できない」旨を pocket settings 等の設定読込時に 警告します (DB を使わない container なら無視して構いません)
• django 未導入の環境で pocket CLI 全体が ModuleNotFoundError: django の traceback で起動不能になっていたのを修正しました (KN1281)。0.32.0 の django-storages extra 化で django が transitive に入らなくなったことで 顕在化していました。django 非依存のサブコマンド (pocket deploy / pocket settings 等) は django 無しで動作し、pocket django ... の実行時のみ magic-pocket[django] の install 手順を 1 行で案内して終了します。 extra なしの magic-pocket で pocket django を使っていた project は install 行を magic-pocket[django] に変更してください

0.32.0 - 2026-08-27¶

Changed¶

• 破壊的: django-storages を必須依存から [django] extra へ移しました。 django-storages は django を必須依存に持つため、extra 無しの magic-pocket を入れるだけで Django 一式が入ってしまい、SQS worker 等の 非 Django container の image を細くできませんでした。 magic-pocket[django] を使っている Django プロジェクトは無影響です。 extra 無しで S3 storage を使っていた場合は magic-pocket[django] に 切り替えてください
• build context の other-read チェックの警告を強化しました (deploy は通るのに Lambda が INIT で必ず死ぬ状態に気付きにくかったため)。警告にファイル名に加えて mode (600 等) を出し、build ログに埋もれないよう deploy の最後にも再掲します。 さらに management Lambda の INIT 失敗エラーには、build 時に検出済みのファイルが あればそれを列挙して原因の切り分けを短縮します

Fixed¶

• SSO 失効や未認証の状態で CLI を実行すると botocore の traceback (約 100 行) がそのまま流れていたのを、原因 1 行 + 認証手順の案内 + 非ゼロ exit に 変換しました。pocket deploy の事前チェックだけでなく全サブコマンドが対象です (pocket resource dsql endpoint 等)。あわせて botocore.tokens が出す SSO token refresh attempt failed の WARNING traceback も抑制しています

Added¶

• get_databases() が DATABASE_URL のクエリパラメータ (?ATOMIC_REQUESTS=True 等) を検出したとき、パラメータ名を挙げて警告するようにしました。 django-environ の env.db() と違い解釈されないため、黙って捨てると 「URL に書いてあるのに効いていない」形で顕在化していました。 docs にも解釈されないことを明記しています
• pocket django deploy / pocket django promote に --skip-migrate を追加しました。 migrate を確認ごと省きます。migrate は Lambda 経由で実際に DB へ接続するため DB が停止・制限中だと失敗しますが、-y は「聞かれたことに全部 yes」の意味なので 非対話実行では migrate を外す手段がありませんでした (pocket deploy へ切替えると collectstatic も行われなくなる)

0.31.2 - 2026-08-20¶

Fixed¶

• managed 宣言が空の secret store view を runtime が読みに行き、Lambda が INIT で AccessDeniedException (ssm:GetParametersByPath) を出して全 handler が 落ちる問題を修正しました。0.29.0 の multi-container 化以降、shared = true の 宣言が無くても stored user secret (type =) があれば shared store の view が 生成される ため、「managed 空 + user あり」の view ができます。IAM 側は managed が空だと store パス (/{pocket_key}/*) を許可しないのに runtime は 無条件に読んでいたため、条件が食い違っていました。managed が空の view は store を読まないようにしています (全キーが捨てられるだけなので挙動は変わらず、 cold start の store 往復が 1 回減ります)

0.31.1 - 2026-08-20¶

Fixed¶

• pocket.runtime.toml 生成器が、bare key に使えない文字 (: 等) を含むキーを quote せず不正 TOML を吐いていた問題を修正しました。IAM Condition ("kms:ViaService" 等) を [container.<name>.iam.inline_policies] に宣言すると deploy は成功するのに、image に焼かれた pocket.runtime.toml が壊れており その container の全 Lambda が INIT で TOMLDecodeError 死していました
• 同生成器が inline table 内のネストした dict / list を Python の repr() で 出力していた問題を修正しました ({'StringLike': {...}} は不正 TOML)。 IAM Statement の Condition がこれに該当します

Changed¶

• pocket.runtime.toml の生成直後に自己検証 (tomllib.loads) を行い、 不正な TOML なら生成時点で fail-loud で停止するようになりました (従来は image に焼かれ、Lambda INIT で初めて落ちていました)
• [container.<name>.iam] は Lambda execution role を組む provision 専用で runtime は参照しないため、pocket.runtime.toml に出力しなくなりました

0.31.0 - 2026-08-20¶

Changed¶

• build context の other-read チェックで、runtime が INIT フェーズで読む pocket.toml / pocket.runtime.toml に other-read が無い場合は警告でなく エラーで deploy を中断するようになりました (該当 container が確実に INIT 失敗するため。chmod 644 で修正、image に COPY しないなら .dockerignore へ)。 その他のファイルは従来どおり警告です (COPY --chmod で image 内を正規化 する構成があるため)
• CLI が生成する pocket.runtime.toml は umask に依らず other-read 付き (0644) で書き出すようになりました

0.30.0 - 2026-08-19¶

Added¶

• pocket-rs が enable_origin_verify に対応しました。 Rust runtime の set_envs() が cloudfront 設定 (enable_origin_verify / waf.allow_rules[].header) から Python と同じ導出で 自動注入 managed secret (POCKET_ORIGIN_VERIFY_SECRET 等) を解決し、 container に secrets 宣言が無くても runtime env に載るようになりました。 また feature axum で Django 版 OriginVerifyMiddleware 相当の 検証 middleware (origin_verify::origin_verify_middleware) を提供します (secret header の定数時間比較 + 詐称耐性 client IP の ClientIp extension 提供。 env secret 未設定時は no-op、不一致は 403)

0.29.0 - 2026-08-19¶

Changed¶

• 破壊的変更: [awscontainer] (単数) を廃止し、[container.<name>] の dict 形式に一般化しました。1 プロジェクトで複数 container (異 runtime の 並行稼働 / strangler 移行) を宣言できます。<name> は英小文字始まりの 英小文字 + 数字 (最大 32 文字、hyphen 不可) です
• 破壊的変更: cloudfront routes / scheduler の handler 参照を "<container>.<handler>" のドット記法に変更しました (container が 1 つ でも必須)
• 破壊的変更: 物理リソース名に container slot を挿入しました。 既存 stage は次回 deploy で計算リソースが新名称で作り直されます (データと secrets は保全されます。下記の移行手順を参照):
  • Lambda 関数: {prefix}{handler} → {prefix}{name}-{handler}
  • ECR repo: {prefix}lambda → {prefix}{name}-lambda
  • container stack: {slug}-container → {slug}-container-{name}
  • API domain Export: {slug}-{handler}-api-domain → {slug}-{name}-{handler}-api-domain
  • SQS queue: {prefix}{handler} → {prefix}{name}-{handler}
  • Lambda 実行ロール: lambda-{slug}-{namespace} → lambda-{slug}-{name}-{namespace}
  • scheduler ロール: {prefix}scheduler → {prefix}{name}-scheduler
• 破壊的変更: managed secret の保存先が container ごとに分かれました。 既定 (shared なし) は container store ({stage}-{project}-{name}-{namespace}) に保存され、container ごとに独立した 値になります (SM コンソール上も container 名で識別可能)。複数 container で 値を共有する場合は全宣言に shared = true を付けます (保存先は従来どおりの {stage}-{project}-{namespace})。shared なしの同名宣言は container ごとに 独立した値になり、shared と無印の混在も可能です (shared 宣言側だけが共有)。 cloudfront から名前参照される secret (token_secret / basic_auth / signing_key) のみ、値の候補が複数になる同名宣言はエラーになります。 既存 secret の値は移行 deploy 時に 旧パスから container store へ自動コピーされます (再生成しないため Django の session / 署名 cookie は無効化されません)。user secret (stored mode) の 正準パスと dsql endpoint publish 先は project 側のまま不変で、外部 provisioner (pocket.naming) への影響はありません。store / pocket_key_format は全 container で一致が必要です
• 各 Lambda に POCKET_CONTAINER=<name> を注入し、runtime (Python / Rust) が自分の [container.<name>] を自動選択するようにしました
• runtime env: 自 container の handler は従来どおり POCKET_<HANDLER>_HOST 等で参照できます。他 container の handler は POCKET_<CONTAINER>_<HANDLER>_HOST / _ENDPOINT / _QUEUEURL の修飾名で 参照します
• CLI: pocket resource awscontainer ... を pocket resource container ... にリネームし、container 単位のコマンド (yaml / url / reload-env / status-env / image repo / image uri 等) に --container <name> を 追加しました (container が 1 つだけなら省略可)。pocket django build / promote は全 container を build / retag します
• pocket.naming.ecr_repo_name() に container キーワード引数が必須に なりました (外部ツール向け公開 API の破壊的変更)
• deploy 完了後に旧形式の container stack ({slug}-container) と旧 ECR repo ({prefix}lambda) を検出し、確認プロンプト付きで自動削除するようにしました (-y で自動承認)。旧 stack の scheduler / SQS event source が動き続ける 事故を防ぐためです
• リリース跨ぎの移行処理を migrate フェーズ (pocket_cli.migrations の registry) に集約しました。deploy は毎回このフェーズを呼び (冪等・移行済み 環境では実質 no-op)、旧 project 共有パスからの managed secret の引き継ぎと 旧リソースの掃除はここで行われます。pocket migrate container-secrets で deploy 前に引き継ぎだけ先行実行することもできます。将来この移行を registry から外すリリースでは、CHANGELOG に「移行を含む版で一度 deploy (または pocket migrate) を挟ぶ必要がある」旨を明記します

移行手順 (0.28.x → 0.29.0)¶

1. pocket.toml の [awscontainer] 系セクションを [container.<name>] へ リネームします (stage override は [<stage>.container.<name>])。 cloudfront routes / scheduler の handler をドット記法へ変更します
2. pocket deploy --stage <stage> (Django なら pocket django deploy) を 実行します。managed secret は旧 project 共有パスから container store へ 自動コピーされ (値は再生成されません)、新名称の container stack が作成され、 CloudFront が新 origin へ切り替わった後、旧 stack / 旧 ECR repo / 旧パスの secret 残骸の削除確認が表示されます
3. 注意点:
   • SQS 付き handler は queue が作り直されるため、queue が空の タイミングで deploy してください (in-flight / DLQ のメッセージは 引き継がれません)
   • 運用スクリプトや docs が旧 Lambda 関数名 / log group 名を参照している 場合は追随が必要です
   • ecr_name 明示指定 (build once の stage 間共有) は名前が変わらない ため再ビルド不要です

0.28.2 - 2026-08-17¶

Fixed¶

• upload_dir route の 8MB 超のファイルが、内容不変でも毎 deploy 再アップロードされ、route の path_pattern 全体の invalidation が毎回走る 問題を修正しました。boto3 既定の multipart 閾値 (8MB) を超えると S3 の ETag が multipart 形式になり、差分 skip (素の MD5 比較) が恒久的に効かなく なるためです。アップロード時の multipart 閾値を 128MB に引き上げ、閾値以下は 単一 PUT (= ETag が素の MD5) を保つようにしました。過去に multipart で 上がった既存オブジェクトも、次の deploy で一度上げ直された後は skip が 効くようになります (128MB 超のファイルは引き続き毎回再アップロードされます)
• pocket permissions list の backup グループに KMS 権限が漏れており、 リスト準拠の deploy role では vault の初回作成 (CreateBackupVault) が 必ず AccessDenied になる問題を修正しました。CreateBackupVault は既定の AWS managed key (aws/backup) を vault に紐付ける際、呼び出し元に KMS 権限を要求します。backup グループに kms:CreateGrant / kms:Decrypt / kms:DescribeKey / kms:GenerateDataKey / kms:RetireGrant を追加し、 権限不足時の警告文言も backup グループ全体 (backup:* と kms 系) を 案内するよう改めました

0.28.1 - 2026-08-16¶

Fixed¶

• 0.27 以前に [dsql.backup] を宣言して deploy した stage で、0.28.0 に 上げても旧形式名 ({prefix}dsql-backup) の backup plan が残り、新 plan ({prefix}backup-dsql) と同じ cluster に二重で定期バックアップが走る 問題を修正しました。deploy が旧形式名の plan を検出すると selection → plan の順に自動削除します ([backup] 未宣言の stage でも掃除だけ走ります)。 destroy の掃除対象にも旧形式名を含めました。recovery point (バックアップ データ) は削除しません。手動で対処する場合は aws backup list-backup-plans で旧名の plan を特定し、 aws backup delete-backup-selection → aws backup delete-backup-plan の 順に削除してください

0.28.0 - 2026-08-16¶

Added¶

• トップレベル [backup] を追加しました。DB 層の定期バックアップ (AWS Backup の backup plan) をエンジン別に [backup.dsql] / [backup.rds] で宣言します (opt-in。未宣言なら AWS Backup を使いません)。1 行の宣言で GFS 階層保持が 既定で有効になります: dsql は daily 35 日 / weekly 365 日 / monthly 1095 日 (長期階層は 90 日で cold storage へ)、rds は weekly / monthly のみ (直近は PITR が秒単位で担うため daily 階層を持ちません)。plan はエンジン別 ({prefix}backup-dsql / -rds) に provision します (AWS Backup の rule は selection 全体に一律適用のため、エンジン差は plan 分割でしか表現できません)。 deploy role に backup 権限が無い場合は deploy を失敗させず警告してスキップ します
• pocket backup cleanup を追加しました。stage のバックアップデータ (recovery point) を削除する CLI で、誤操作ガードとして [backup] の deletable = true 宣言が必要です。destroy でも同宣言下でのみ [y/N] 確認 (既定 No) を経てデータを削除できます (--yes の一括承認では削除 しない)。データが残る destroy では件数を警告表示します

Changed¶

• 破壊的変更: [dsql.backup] を廃止し、トップレベル [backup.dsql] に 移行しました (旧宣言は pydantic の Extra inputs エラーになります。旧名 {prefix}dsql-backup の plan が残っていれば AWS Backup コンソールで削除して ください)。backup 関連の宣言は厳密に検証します: [backup] 単体・ [backup.neon] 等の対象外エンジン・対象資源 ([dsql] / managed [rds]) の 無い宣言・[backup.rds] への cold_storage_after_days (Aurora は cold storage 非対応)・[backup.rds.daily] は、すべてエラー停止します
• [rds.backup] の retention_days (PITR 保持日数) の既定を 7 日から 35 日 (ネイティブ上限) に引き上げました。クラスタ属性のため追加リソースは 無く、Aurora のバックアップストレージはクラスタ容量まで無課金のため、変更の 少ないワークロードでは通常コスト増もありません。既存クラスタは次回 deploy の ModifyDBCluster (ApplyImmediately) で収束します。PITR は [backup.rds] の宣言と無関係に常に有効です
• pocket resource dsql backup の保持日数の継承元が [backup.dsql] の 最長階層 (monthly) の delete_after_days になりました (既定同士なら従来と 同じ 1095 日)
• IAM Action を簡素化し、feature group backup (backup:* + backup-storage:MountCapsule) を新設しました (dsql group から分離)。 [dsql] 使用時に加え、[backup.rds] 宣言時にも必要になります。backup:* にはデータ削除も含まれますが、pocket が削除するのは deletable = true + 明示確認の経路のみです。権限レベルで禁止したい場合の Deny 例を docs/permissions/aws.md に記載しました

0.27.0 - 2026-08-13¶

Changed¶

• pocket resource dsql backup で --retention-days を省略したときの保持日数を、 [dsql.backup] の delete_after_days → 宣言が無ければ 1095 日 (3 年) の順で 解決するようにしました。従来は Lifecycle を渡さず 無期限保持 になっていましたが、 pocket にも deploy role にもバックアップデータの削除権限が無いため、 一度作ると console 作業でしか消せない recovery point が積み上がっていました。 復元前に取られる現用クラスターのバックアップ (利用者が明示的に頼んでいない分) も 同じ解決を通ります。解決結果は実行時に 1 行表示されます。 意図的に無期限にする場合は --retention-days=0 を明示してください (警告のうえ Lifecycle なしで実行します)

Documentation¶

• dsql backup の docs に、短サイクル検証向けの設定例 (cold_storage_after_days = 0 で 90 日制約を外す) と、plan 由来の job が ListBackupJobs に現れるまで 30 分ほどラグがある旨の注記を追加しました

0.26.0 - 2026-08-12¶

Added¶

• staticfiles 宣言に link を追加しました。link = true を宣言すると pocket django deploy / promote / deploystatic のすべての経路で collectstatic に --link が付き、ビルド先が全量 symlink になります (大容量資産の複製コスト削減。aws s3 sync は symlink を追うため アップロード互換)。従来の deploystatic --link フラグは --link/--no-link になり、宣言の上書き用に使えます

Changed¶

• link 有効時は、ビルド先 (pocket_cache/static_build/<stage>/) を collectstatic の前に毎回クリアするようにしました。非 link で作られた 実体ファイルが混在すると collectstatic がモード不一致で全ファイルを 実体コピーし直すこと、ソース削除後に残る壊れた symlink が aws s3 sync を exit 2 で失敗させることを避けるためです。 非 link 時は従来どおりクリアしません

0.25.1 - 2026-08-12¶

Fixed¶

• DSQL バックアップで使う AWS Backup vault (pocket-backup) の自動作成が、 vault が 1 つも無いアカウントで AccessDeniedException になり失敗する問題を 修正しました。AWS Backup は存在しない vault への Describe に ResourceNotFoundException ではなく AccessDeniedException を返すため、 「describe → 無ければ create」では未作成を判定できませんでした。 CreateBackupVault を先に実行し AlreadyExistsException を握る方式 (create-first) に変更しています。オンデマンドバックアップ・定期バックアップ (backup plan の ensure)・復元の 3 経路すべてに影響していました
• pocket resource dsql backup の AWS エラー表示に、失敗した API 名を含める ようにしました (例: AccessDeniedException (API: CreateBackupVault): ...)。 従来は AWS の文言だけで、どの呼び出しで落ちたのか分かりませんでした

0.25.0 - 2026-08-11¶

Added¶

• pocket deploy / pocket promote に -y / --yes を追加しました。 pocket django deploy にしか無く、django を使わない (axum 等の) プロジェクトが 非対話実行できませんでした。確認は pocket_cli.cli.interaction.confirm 経由に なり、deploy 配下で確認が増えてもこのフラグで抑止されます

Changed¶

• build / upload_dir route のアップロードを差分のみにしました。S3 上の オブジェクトと内容が一致するファイル (ETag が素の MD5 で、ローカルの MD5 と 一致) は skip します。数千ファイル規模の配信アセットを upload_dir に置いても deploy 時間が伸びません。multipart アップロード済み (ETag が <hash>-<n>) や ETag が MD5 にならないオブジェクト (SSE-KMS 等) は内容を断定できないため常に 再アップロードします (サイズ比較での代替はしません)
• CloudFront の invalidation を変更があった route の path_pattern に限定し、 変更が無ければ invalidation 自体を発行しないようにしました。従来は毎 deploy /* 固定で、アップロードしていない配信専用 route のキャッシュまで落ちていました

0.24.0 - 2026-08-07¶

Added¶

• [cloudfront.<name>.waf] に allow_rules を追加しました。IPSet / managed rules より先に評価される allow ルールを宣言でき、IP allowlist で閉じた stage でも外形 smoke や uptime チェックの経路を開けられます。 path (末尾 * で prefix 一致) の素通しと、header (managed secret を 自動生成し、固定ヘッダ x-pocket-waf-allow の値一致で allow) の 2 形を サポートし、両方指定で AND になります。WAF を弱める宣言のため、deploy 時に 一覧が表示されます
• docs: managed secret が Lambda の設定 env に現れず runtime 注入である旨と、 外部 (CI 等) からは secret store (SSM /{pocket_key}/<KEY>) を読む必要が ある旨を明記しました
• [[s3.lifecycle_rules]] に expiration_days (Expiration.Days) を追加しました。 現行バージョンのオブジェクトを prefix 単位で日数削除できます (trash prefix の 自動削除など)。従来の noncurrent_version_expiration_days は optional になり、 少なくとも一方の指定が必要です (両方の同時指定も可)

0.23.1 - 2026-08-04¶

Fixed¶

• [dsql] 使用時の必要権限に backup-storage:MountCapsule が抜けていたのを 修正しました。backup:CreateBackupVault の実行にはこの権限 (Resource *) が 必須で、pocket permissions list の出力から deploy 用 IAM policy を組んでいる 環境では pocket-backup vault の初回作成が AccessDenied で失敗していました。 service prefix が backup ではなく backup-storage である点に注意してください

0.23.0 - 2026-08-04¶

Added¶

• [rds.backup] retention_days を追加しました (1〜35、既定 7 日)。Aurora の 自動バックアップ (PITR) の保持日数で、クラスターのネイティブ属性のため追加 リソース・追加権限は不要です。設定と異なる既存クラスターは次の deploy で ModifyDBCluster (ApplyImmediately) により収束します
• [dsql.backup] を追加しました。宣言すると deploy が AWS Backup の vault / サービスロール / backup plan / selection を冪等に provision します。 DSQL は組み込みの自動バックアップを持たないため、これが唯一の定期バックアップ 手段になります。既定は「毎日 3:00 (UTC) / 35 日後に cold storage へ移動 / 365 日後に削除」で、cron / timezone / cold_storage_after_days / delete_after_days で変更できます。pocket destroy は plan と selection を 削除しますが、vault と recovery point (バックアップデータ) は削除しません
• pocket resource dsql restore / restore-status を追加しました。recovery point (--latest で最新) から復元し、現用クラスターの切り替え (Name タグの付け替えと SSM の endpoint 更新) まで行います。復元前に現用クラスターのバックアップを取るか 確認します (--skip-backup / --yes)。AWS Backup の復元は常に新しい クラスターを作るため、切り替え後は pocket deploy が必要です (Lambda の POCKET_DSQL_ENDPOINT と dsql:DbConnectAdmin の対象 ARN が CloudFormation 管理のため)。旧クラスターは戻り先として残します (明示的に削除するまで課金され 続けます)。どちらもコマンドが警告として案内します
• [dsql] を設定していて [dsql.backup] の宣言が無い stage の deploy で、 自動バックアップが無いことを警告するようにしました。他の DB backend と 違い黙って通ると「managed DB だから守られている」と誤解されたまま、誤削除・ 論理破壊からの復元手段がゼロの状態で運用されるためです

Changed¶

• RDS の自動バックアップ保持日数の既定が 1 日 (AWS 既定) から 7 日に変わります。 1 日だと「PITR があるからいつでも戻せる」という理解と実態 (24 時間しか遡れない) が乖離するためです。既存クラスターも次の deploy で 7 日へ収束します (保持期間が 延びる方向のみ)。Aurora のバックアップストレージはクラスター容量までは無課金の ため、通常は増分コストは生じません。従来の挙動を保つ場合は [rds.backup] retention_days = 1 を明示してください

0.22.0 - 2026-08-03¶

Added¶

• pocket resource dsql backup / pocket resource dsql backup-status を追加 しました。DSQL には組み込みの自動バックアップ (PITR・スナップショット) が無く、 AWS Backup 統合が唯一のバックアップ手段のため、オンデマンドバックアップの開始と job の状態確認を CLI から行えるようにします。両コマンドとも --watch で終端 状態まで待機できます (backup は開始後に確認コマンドの案内も表示)。前提と なる vault (pocket-backup) とサービスロール (forge-pocket-backup-role、 permissions boundary 対応) は初回実行時に冪等に自動作成されます。既存の vault / ロールは --vault / --iam-role-arn で指定でき、--retention-days で recovery point の保持日数を設定できます。[dsql] 使用時の必要権限に backup 系 5 Action が追加されています (docs/permissions/aws.md 参照)

Changed¶

• magic-pocket-cli の依存 magic-pocket を同 minor に束縛しました (>=0.22.0,<0.23)。従来は下限のみだったため、cli を version pin している 消費者にも lib 側の破壊的変更がリリース当日に届き deploy が壊れる事象が ありました。0.x では minor が breaking の単位のため、これで「cli の pin = lib の pin」になります

0.21.0 - 2026-08-02¶

Added¶

• pocket resource neon store-url が保存前に、解決した接続先 (stage=... → project=... → branch=... → endpoint=...) を表示するように なりました。意図と異なる branch へ焼いても「保存しました」だけでは気づけない ため、書き込み前に解決済みの情報を見せて pocket.toml の意図と目視照合できる ようにします。この実行で branch を新規作成した場合 (= 空の branch に接続する) は警告を添えます。あわせて公開 API に ensure_url_for_context_with_info (解決情報付き版。endpoint host は URL から解析し追加 API call なし) を追加 しました
• build context の非可読ファイル (other-read なし、mode 600 等) を build 前に 検出して警告するようにしました (docker / depot backend)。Lambda の実行 ユーザーは非 root のため、該当ファイルが image に COPY されると全 handler が INIT フェーズで失敗しサイトごと 500 になります (codebuild backend は従来 どおり source zip 作成時に 0644/0755 へ自動正規化)。あわせて
• pocket django init 生成の Dockerfile テンプレートの COPY に --chmod を 付け、host 側の permission 事故を build 段で吸収するようにしました
• management handler の INIT 失敗メッセージに、runtime 版不整合と並ぶ原因候補 として build context のファイル permission を追記しました
• 廃止済みフラグ --skip-check-existing (0.6.0 で削除) を渡した場合に、click の "No such option" ではなく provisioning = "command" + pocket resource <db> store-url への移行手順を示してエラーになるようにしました (pocket deploy / pocket promote / pocket django deploy / pocket django promote)。旧 バージョンからの一括アップデートで CI が案内なしに停止する実害への対応です (設定キー側の fail-fast ガイドと対になる CLI フラグ版)
• [neon] の branch_name 未指定 (default branch fallback) で、project に stage 名の branch が存在する場合に警告を出すようにしました。0.5.0 の デフォルト変更 (stage 名 → default branch) を跨いで移行すると、store-url / deploy が実データと別の branch へ接続 URL を焼く事故 (空 DB 参照) につながる ため、branch 一覧の取得済みデータから追加 API call なしで検出します。意図が stage 名 branch なら branch_name = "{stage}" の明示を案内します

Changed¶

• 破壊的変更: CloudFront route の build_dir と文字列形式の build = "..." を 廃止し、ビルド責任を宣言で分離しました。旧キーは起動時に移行手順つきのエラーに なります
• pocket にビルドさせる場合: build = { dir = "frontend/dist", cmd = "just frontend-build" } (dir / cmd とも必須。deploy が upload 前に cmd を shell 実行)
• ビルドは外部 (CI 等) の責任でアップロードのみの場合: upload_dir = "frontend/dist" (deploy はビルドを実行しない。成果物の最新化は利用者の責任)
• 背景: 旧スキーマは build_dir 単独で有効なため「宣言すれば pocket がビルド してくれる」誤解を招き、古い成果物のまま配信される事故 (deploy は成功ログ・ API は新しい・画面だけ古い) が実際に発生しました。ビルドさせる/させないを どちらも明示宣言にすることで、この見落としを構造的に防ぎます

Added¶

• [dsql] の deploy が cluster endpoint を stored user secret の正準パス /{stage}-{project}-{namespace}-user/dsql_endpoint へ publish するように なりました。DSQL は cluster identifier が AWS 自動生成で endpoint を命名規約 から導出できないため、deploy の外の消費者 (migration ツール・外部 provisioner 等) が endpoint を決定的に引ける作成記録を deploy が書き込みます
• 保存先は stored user secret 機構に相乗り (secrets.store に応じた SSM SecureString / Secrets Manager)。毎 deploy で冪等に上書きし (値が同じなら書き込まない)、cluster 削除時には publish も削除します
• pocket.naming に secret_type 定数 DSQL_ENDPOINT を追加しました。 消費者は stored_user_secret_name(project=..., stage=..., secret_type=DSQL_ENDPOINT, store=...) で正準名を導出できます
• ssm feature group に ssm:DeleteParameter (単数) を追加しました (secrets.store = "ssm" 構成での unpublish / pocket migrate-secret-paths の旧パス削除用)

0.19.0 - 2026-07-20¶

Added¶

• platform = "linux/arm64" で Lambda が arm64 (Architectures) で作成される ようになりました。従来は build だけ arm64 で Lambda が x86_64 固定のため、 起動時に exec format error (Runtime.InvalidEntrypoint) で必ず失敗していました。 未知の platform 値は設定読込時にエラーになります
• handler 単位の環境変数上書き [awscontainer.handlers.<name>].envs を追加 しました。[awscontainer].envs とマージされ handler 側が優先されます。 同一イメージ・同一バイナリを環境変数でモード切替して複数の Lambda に並べる 用途 (Rust 単一バイナリの管理系 handler 等) に使えます
• ECR repo 名 / deploy 済みイメージ参照の正準導出 API を追加しました。外部 ツールが pocket の内部命名を再実装せずに済みます
• pocket.naming.ecr_repo_name() / ecr_image_tag() (純関数)
• pocket resource image repo / pocket resource image uri --stage <s> (pocket.toml 準拠。uri は {repo_uri}@{digest} を stdout 出力)
• distribution 単位の Basic 認証 [<stage>.cloudfront.<name>].basic_auth を 追加しました。公開前の sandbox/stg サイト全体 (S3/SPA/lambda の全 behavior) を隠す用途で、credential は新 managed secret type basic_auth_credential (username 必須 / password 固定可・省略時ランダム) で生成し、deploy 時に KVS へ書き込みます。Authorization ヘッダを占有するため、ヘッダ認証 (Bearer 等) を使う API とは併用できません (cookie/session 認証は可)

Fixed¶

• pocket destroy / pocket resource neon delete が Neon の root branch で 422 (cannot delete the root branch) になり異常終了していました。root branch は project 内に他 branch がなければ project ごと削除し、他 branch が同居する 場合は巻き添え防止のため警告してスキップします
• [<stage>.awscontainer.envs] の値に二重引用符 (JSON 文字列等) が含まれると CloudFormation テンプレートが YAML ParserError で壊れていました。埋め込みを YAML セーフにし、引用符・バックスラッシュ・改行を含む値を扱えるようにしました
• prefix 付き SPA route (path_pattern = "/admin/*" 等) の fallback URI に glob の * がリテラルで残り (/admin/*/index.html)、SPA が一切配信できません でした。prefix 部分だけを使い /admin/index.html に解決するよう修正しました

0.18.1 - 2026-07-20¶

Fixed¶

• SchedulerExecutionRole に permissions_boundary が反映されていませんでした。 permissions boundary が強制される AWS アカウントでは、scheduler 構成の stack が iam:CreateRole の条件で拒否され作成できなかったため、LambdaRole と同様に boundary を付与するよう修正しました。0.18.0 で pocket.sqs_scheduler を含む scheduler 構成を boundary 強制環境へ deploy する場合はこの版へ更新してください。

0.18.0 - 2026-07-19¶

Added¶

• スケジュール実行の新しい entry 種別 pocket.sqs_scheduler を追加しました。 EventBridge Scheduler が Lambda を直接 invoke する代わりに、handler の SQS queue へ直接 SendMessage します（message が JSON 化されて MessageBody になる）。 定期実行を queue に載せることで、リトライは SQS の visibility timeout / redrive に 一元化され、失敗系の監視は queue の DLQ 1 箇所だけになります。worker handler は SQS event だけを受ければよく、「EventBridge 直接 invoke と SQS event の両受け」を 実装する必要がありません。対象 handler には sqs 設定が必須です（デプロイ前に バリデーションエラーになります）。scheduler の IAM role には対象 queue に絞った sqs:SendMessage が付与され、schedule が全て SQS 型の場合は lambda:InvokeFunction 文は出力されません。
• Rust runtime (magic-pocket-rs) に SQS worker / enqueue ヘルパ (magic_pocket_rs::sqs) を追加しました。
• process_sqs_records(event, handler): SqsEvent を record 単位で dispatch し、 失敗した record だけを partial batch response (batchItemFailures) として集約 します。report_batch_item_failures が既定で有効な pocket の event source mapping では、例外でバッチ全体を落とすと成功済み record まで再配信され二重実行 される（BaseCommandHandler で修正済みの問題と同型）ため、Rust worker でも record 単位の失敗報告を最初から強制する形にしています。
• enqueue_json(queue_key, message) / queue_url(queue_key): runtime が注入する POCKET_<KEY>_QUEUEURL を読んで SendMessage する糖衣。メッセージ本文の形式 （Job enum 等）と dispatch の中身はアプリ側の責務です。
• Rust runtime (magic-pocket-rs) の set_envs() が RDS と CloudFront に対応しました。
• DATABASE_URL = { type = "rds_database_url" } 構成で、Secrets Manager / SSM の 認証情報から DATABASE_URL を実行時に構築します（Python runtime の _set_rds_database_url と対称。パスワードの percent-encode、 ManageMasterUserPassword の secret に host/port/dbname が無い場合の POCKET_RDS_ENDPOINT 等での補完まで含めて同じ結果になります）。 従来 Rust アプリは RDS 構成でも DATABASE_URL が marker 値 (__rds_runtime__) のまま boot し、接続に失敗していました。
• POCKET_CLOUDFRONT_{NAME}_DOMAIN をセットするようになりました。 ドキュメントは以前から Django・Rust 両対応と記載していましたが、 Rust 側は未実装でした。

Changed¶

• context の組み立て（Context.from_toml / from_settings）が AWS API を 呼ばなくなりました。従来は managed secret を宣言していると、SecretsContext の validator が IAM 許可リスト（allowed_sm_resources）の ARN 解決まで行うため、 context を作るだけで Secrets Manager の get_secret_value が走っていました （credential 不在環境では分かりにくい NoCredentialsError、Lambda cold start にも余計な API 呼び出し）。ARN 解決は実際に必要になる時点（テンプレート描画・ serialize）まで遅延されます。これに伴い、managed secret が未作成のときの 「Pocket managed secrets is not ready」警告も context 構築時ではなく初回 ARN 解決時に出るようになります。
• catch-all の S3 route で origin_path = "/"（バケット直下の配信）を指定した場合の エラーメッセージを、意図的な非サポートである旨と理由（pocket は 1 つの S3 バケットを 複数 route で共有するため、バケット直下に向けると OAC のバケットポリシーが バケット全体許可になる）を含むものに変更しました。従来は汎用の origin_path must not ends with / だけで、origin_path 省略を試すと今度は catch-all のエラーに当たり、メッセージ間をループしていました。 非サポートである旨は docs/guide/configuration.md にも明記しています。
• breaking: pocket.toml の全セクションで未知キーをエラーにするようになりました。 従来 [awscontainer], [awscontainer.secrets], [awscontainer.handlers.*], [rds], [dsql], [scheduler], [vpc.efs], [s3.cors] 等は未知キーを黙って 無視していたため、typo や旧スキーマの残骸が「設定したつもりで効いていない」 状態になっていました（例: 0.9.0 でリネームされた [awscontainer.secretsmanager.pocket_secrets] を書き続けても secret 宣言が 丸ごと無視される）。既に [general], [cloudfront], [s3], [ses] 等は 未知キーを拒否していたので、その挙動への統一になります。 未知キーが残っている pocket.toml は起動時に Extra inputs are not permitted で失敗するので、エラーが指すキーを削除するか正しい名前に直してください。
• breaking: [neon] / [tidb] / [upstash] も未知キーをエラーにするように なりました。この 3 つは .env から credential を読むため pydantic 側の extra="forbid" は使えず（.env の無関係なキーまで拒否してしまう）、 toml のキーのみを検証します。.env の扱いは従来どおり変わりません。
• breaking: pocket.django.lambda_handlers の sqs_management_command_report_failuers_handler を、typo を修正した sqs_management_command_report_failures_handler にリネームしました (failuers → failures)。旧名は残していません。pocket.toml の [awscontainer.handlers.*] の command で旧名を指している場合は、新しい名前に 書き換えてください（そのままだと deploy 後の Lambda が handler の解決に失敗します）。

Fixed¶

• SQS handler の部分失敗で、成功済みの job が再実行される問題を修正しました。 pocket.command_handler.BaseCommandHandler は event source mapping に FunctionResponseTypes: ReportBatchItemFailures が付いている (report_batch_item_failures が true = 既定) にもかかわらず batchItemFailures を 返しておらず、バッチ内の 1 record が失敗すると handler 全体が例外で落ちていました。 SQS はこれを「バッチ全件が失敗」と解釈するため、同じバッチで既に完走していた record まで再配信され、冪等でない管理コマンドが二重実行されていました。 record 毎に例外を捕捉し、失敗した record の messageId だけを batchItemFailures で報告するようになったので、再配信されるのは失敗した record だけになります。crash 時の traceback は従来どおり CloudWatch に出力され、 dead_letter_max_receive_count 超過で DLQ に落ちる挙動も変わりません。

Removed¶

• breaking: pocket.django.utils.get_static_storage を削除しました。 get_storages()["staticfiles"] で同じ storage を取得できます。
• breaking: pocket django manage の --handler オプションを削除しました。 このオプションは指定すると即 DeprecationWarning（"Do not use key ..."）を出す 状態で、management command handler は command が pocket.django.lambda_handlers.management_command_handler の handler を 自動選択します。絞り込みが必要なケースは無かったため削除しました。

0.17.0 - 2026-07-12¶

Added¶

• Neon の ensure + 接続 URL 算出を、import 可能な公開 API pocket.provisioning.neon として runtime package (magic-pocket) 側に追加しました。 外部 provisioner（backend 作成時に接続 URL を SSM / Secrets Manager へ焼く側）が、 pocket.toml や pocket_cli を持たない中央実行（Web UI sync 等の Lambda 上 subprocess を含む）からでも、pocket 自身の ensure + URL 導出を再実装せずに import で共有できます。ensure_and_compute_url(project_name=..., branch_name=..., name=..., role_name=..., api_key=...) が branch/role/database を ensure して postgres://...?sslmode=require を返します（NeonContext を直接渡す ensure_url_for_context も公開）。SSM への保存自体は呼び出し側の責務で、正準名は 既存の pocket.naming.stored_user_secret_name で導出できます。これにより pocket.naming（0.15.0）で path を、本 API で ensure+URL 導出を共有でき、 provisioner 側の独自再実装による drift を構造的に防げます。
• 実装は runtime package へ一本化し、HTTP は stdlib urllib で行うため magic-pocket に新規依存は追加していません（requests は magic-pocket-cli 側の依存のまま）。既存の pocket_cli.resources.neon（Neon 等）は本モジュールの re-export として 後方互換を維持します。pocket resource neon store-url も同じ共有ヘルパを 経由するようになり、CLI と公開 API の導出が単一実装に揃います。

0.16.0 - 2026-07-11¶

Added¶

• pocket resource dsql endpoint / pocket resource rds endpoint に --format json オプションを追加しました。装飾なしの JSON を stdout に出力するため、 CI / シェルスクリプトから $(pocket resource dsql endpoint --format json) のように 安全に接続情報を取得できます（診断メッセージは従来通り stderr）。json 指定時は クラスター不在を exit code 1 で伝えます（text は従来通り warning + exit 0）。

0.15.0 - 2026-07-11¶

Added¶

• stored user secret 名の正準導出を公開 API pocket.naming として追加しました。 外部 provisioner（backend の接続 URL を SSM / Secrets Manager に焼く側）が、 pocket の deploy が読む正準パス（/{pocket_key}-user/{type}）を再実装せずに import で共有できます。put する側と read する側（deploy）が同じ導出を使うことで、 パス不一致による ParameterNotFound を構造的に防ぎます。 stored_user_secret_name / user_secret_path / pocket_key と type 定数 （NEON_DATABASE_URL / TIDB_DATABASE_URL / UPSTASH_REDIS_URL）を公開します。 pydantic / boto3 非依存の純粋な文字列導出のため import は軽量です。 import pocket 直下からも参照でき、既存の from pocket.context import user_secret_path は再エクスポートで後方互換を 維持しています。

0.14.0 - 2026-07-10¶

Fixed¶

• DSQL リソース（pocket.toml の [dsql]）の deploy が boto3 パラメータの 大文字小文字の誤りで常に失敗する問題を修正しました。boto3 dsql client の service model は lowerCamel（identifier / resourceArn）ですが、実装が PascalCase（Identifier / ResourceArn）で呼んでおり ParamValidationError になっていました（get_cluster / delete_cluster / list_tags_for_resource）。 ParamValidationError は ClientError ではないため既存の except ClientError で拾えず、初回 deploy は cluster 作成直後の _wait_active で、再 deploy は status 解決時に crash していました。実 service model で casing を検証する Stubber ベースの回帰テストを追加しています。
• CodeBuild builder の source zip 作成（_upload_source）を forge VM 環境で 発生しやすい 2 つの footgun に対して堅牢化しました。(1) 実体の無い壊れた symlink（host 側参照など）を zip に入れようとして FileNotFoundError で deploy 全体が落ちる問題を、当該ファイルを skip + warning するようにしました。 (2) sed -i 編集等で生じた mode 0600 のファイルがそのまま image に入り、 Lambda の非 root 実行ユーザーが読めず起動時に panic する問題を、通常ファイルを 0644 / 実行ファイルを 0755 に正規化して防ぐようにしました。

0.13.0 - 2026-07-07¶

Added¶

• pocket deploy / pocket django deploy 実行時に、解決された DEPLOY_HASH の値と 出所（DEPLOY_HASH 環境変数 / git HEAD）を 1 行表示するようにしました。環境変数の 伝播漏れで意図せず git short hash にフォールバックしていた場合に気づけます。
• pocket migrate secret-paths（および pocket migrate）に、移設で旧パスが削除される ことの事前警告を追加しました。移設後に古い runtime（magic-pocket[django]）が DATABASE_URL を解決できず INIT で落ちる footgun を移設前に明示し、runtime を CLI と 同版へ更新してからの再デプロイを促します。
• Rust クレート magic-pocket-rs が type 基準の user secret （{ type = "neon_database_url" }、name 省略）に対応しました。Python ランタイムと 同じ正準パス導出（store=ssm なら /{pocket_key}-user/{type}）を実装し、name の 手書きが不要になりました。

Fixed¶

• 診断・状態メッセージ（echo）が stdout に出ていたため、 SRC=$(pocket resource neon url --stage prod) のような capture に設定 lint の警告が 混入して URL を汚す問題を修正しました。診断はすべて stderr に出すようにし、stdout は 「機械が読む値」（URL / pocket permissions list の一覧など click.echo 出力）専用に しました。
• 診断メッセージ中の magic-pocket[django] のような角括弧表記が Rich の markup として 解釈されて消えてしまう問題を修正しました。
• S3 route の origin_path 二重 prefix 助言が 1 回の設定ロードで 2 回表示される問題を 修正しました。

0.12.0 - 2026-07-05¶

Changed¶

• stored user secret の保存先を type 基準の正準名に変更しました（破壊的変更）。 従来 type 指定の user secret（stored mode）は、保存先の SSM/SM 名を consumer の env var 名（[awscontainer.secrets.user] の辞書キー）から導出して いました（/{pocket_key}-user/{ENV_KEY}）。このため env var のリネームや backend の付け替えで保存先が動き、backend 移行（neon→tidb 等）で「保存済み URL を引け ない」問題の温床になっていました。これを type 基準（/{pocket_key}-user/{type}、 例 /{pocket_key}-user/neon_database_url）に変更しました:
• 保存 identity が env var 名から独立し、リネームや付け替えで動きません。
• 同一 type の user secret は 1 stage につき 1 個までに制限されます（保存先が 衝突するため。設定ロード時のバリデーションで検出）。
• pocket resource <db> url は、consumer の DATABASE_URL が別 backend を指して いても type 基準でその backend の保存 URL を解決できるようになりました （宣言が無くても正準パスから直接読む）。
• 移行: 0.11 以前で provision 済みの環境は、アップグレード後に pocket migrate secret-paths --stage <stage>（または引数なしの pocket migrate） を実行して旧パス→新パスへ値を移設してください（copy→検証→旧削除、冪等）。 ※ backend の cutover を既に済ませて type 宣言が消えている旧値は自動移設の対象外 です（旧キーを導出できないため）。その場合は store-url の再実行、または旧パスの 値を手動で新パスへ copy してください。
• redirect_from を CloudFront Function 方式に作り替えました。従来は リダイレクト元ドメインごとに「専用 ACM 証明書 + 専用 S3 website バケット （RedirectAllRequestsTo）+ 専用ディストリビューション」を作っていましたが、 これを次の構成に置き換えました:
• リダイレクト元ドメインをメインディストリビューションの Alias に追加し、 証明書もメイン証明書の SAN にまとめる（専用証明書・専用配信を作らない）。
• canonical ドメインへの 301 リダイレクトを viewer-request の CloudFront Function で返す（path・query を保持）。既存の viewer-request Function （API host / SPA fallback / deploy-hash strip 等）には同等の redirect prelude を注入し、Function を持たない behavior にのみ専用の redirect Function を割り当てるため、全 behavior で確実にリダイレクトされます。
• これにより、専用 S3 website バケット作成に起因する IllegalLocationConstraintException（bucket region 不整合）と、 リダイレクト専用証明書の論理名バグの温床が構造的に解消されます。
• 既存環境の更新時、旧実装が残した S3 website バケットは配信更新後に冪等に 削除します（別アカウント所有等で消せない場合は警告のみ）。
• pocket.toml の設定（redirect_from = [{ domain = ... }]）は従来どおりで、 移行のための記述変更は不要です。

Added¶

• pocket migrate をサブコマンド構成に整理しました。
• pocket migrate secret-paths: stored user secret を旧キー基準パスから新 type 基準パスへ移設します（0.11→0.12。copy→検証→旧削除、冪等。--dry-run で確認可）。
• pocket migrate template-hash: 従来の pocket migrate（スタックのテンプレート ハッシュタグ一括付与）です。
• 引数なしの pocket migrate は上記を secret-paths → template-hash の順に冪等実行 します（template-hash がテンプレ差分で中断しても secret-paths は完了済みで、 pocket deploy 後の再実行が安全）。
• 破壊的変更: 従来の bare pocket migrate（テンプレートハッシュ付与）は pocket migrate template-hash へ移動しました。

0.11.0 - 2026-07-05¶

Added¶

• CLI と runtime のバージョン不整合を、分かりやすいエラーで検知するようにしました。 デプロイを叩く pocket CLI（magic-pocket-cli）と Lambda 内 runtime（magic-pocket）は 別パッケージで版が独立に固定されるため、CLI が新機能スキーマの pocket.runtime.toml を 書いても runtime が古いと解釈できず、Lambda の INIT フェーズで Runtime.Unknown として 不透明に失敗していました。
• pocket.runtime.toml の先頭に生成元 CLI 版を TOML コメントとして刻みます。コメント なので古い runtime（tomllib）は無視し、後方互換は壊れません。
• runtime は設定読込時に「生成元版 > 自身の版」を検出したら、Runtime.Unknown の代わりに 対処（uv add 'magic-pocket[django]>=X.Y.Z'）を促す明快な例外を出します（この検査を 含む 0.11.0 以降の runtime で有効）。
• deploy の management ステップが INIT フェーズ失敗（Runtime.Unknown / INIT_REPORT ... Status: error）を検出した場合、「アプリの traceback を確認」ではなく runtime 側（バージョン不整合を含む）を疑う案内に切り替え、切り分けの誤誘導を減らします。
• あわせて deploy ガイド（実行環境）に CLI/runtime の版結合と lock 更新手順を明記しました。

0.10.0 - 2026-07-05¶

Added¶

• pocket resource neon url / pocket resource tidb url を追加しました。指定 stage の backend 接続 URL を 純 URL のみ stdout に出力します（診断・警告は stderr）。backend 移行ツール（Neon→TiDB 等）が接続 URL を app 側で自前解決（SSM パラメータ名のハードコード や neonctl 直叩き）せずに、$(pocket resource neon url --stage prod) で取得できます。
• 解決方式は既定で stored-first（type = "<db>_database_url" の user secret を読む。 副作用が無く、consumer が実際に使う URL と一致）。未 provision の場合のみ provider API での live 算出に fallback します。--live で常に provider API から算出します。
• TiDB は password reveal API が無く URL 算出が root password を rotate するため、既定を stored-first にして rotate を回避しています（--live 指定時のみ rotate。consumer の redeploy が前提）。
• 移行中に [neon] と [tidb] を 併記（dual-declaration）した状態で、resource ごとに neon / tidb を呼び分ければ source/target 双方の URL を解決できます。

0.9.1 - 2026-07-05¶

Fixed¶

• redirect_from の ACM 証明書 CFn 論理名にハイフン等の非英数字が残り deploy が 失敗する不具合を修正しました。RedirectFromContext.yaml_key が domain.split(".")
• capitalize() で論理名を組み立てていたため、ハイフンを含む domain （apex→www の定番 redirect でごく一般的）では CFn 論理 ID に非英数字が残り Template format error: Resource name ... is non alphanumeric で UpdateStack が 失敗していました。RouteContext / _camel と同様に非英数字を境界にして除去する ように揃えました。
• 既存デプロイへの影響なし: 非英数字を含まない domain では旧実装と同一の論理名に なる（挙動不変）ため、影響を受けるのはハイフン等を含む domain のみで、それらは そもそも従来 deploy できていませんでした。

0.9.0 - 2026-07-04¶

Added¶

• S3 route で origin_path を省略できるようにしました（path_pattern が prefix を持つ route のみ）。S3 の key prefix は origin_path + path_pattern で計算されるため、 path_pattern = "/media/*" の route に origin_path = "/media" を付けると S3 実キーが media/media/... の二重階層になっていました。origin_path を省略すると path_pattern 由来の単一 prefix（media/...）になり、aws s3 sync 等でバケットを直接操作する運用で prefix が直感的になります。catch-all（path_pattern = "" / "/*"）は prefix を持たないため origin_path は必須のままです。
• あわせて、S3 prefix 重複検査と OAC バケットポリシーの prefix 計算にも origin_path 省略 route を含めるよう修正しました（含めないと空 origin route のオブジェクトがポリシー範囲外に なり CloudFront が 403 になる不具合を回避）。
• 既存デプロイへの影響: 既存 route から origin_path を外すと S3 key prefix が変わり 既存オブジェクトが参照できなくなるため、単一 prefix へ移行する場合は既存オブジェクトの 移送が必要です（opt-in。既存 toml はそのままなら挙動不変）。

0.8.1 - 2026-07-03¶

Fixed¶

• RDS create() を冪等化しました。途中で失敗した deploy の再実行や、一部リソース だけ先行作成済みのケースで、DB Subnet Group / Security Group / クラスタ / インスタンスが ...AlreadyExists で落ちていたのを、既存を検出して再利用・skip するようにしました。 static パスワードの再生成や password 切替 modify は「新規作成/復元したセッションのみ」 実施するため、再実行で認証情報が作り直されることもありません。
• RDS の snapshot 復元で、modify_db_cluster（master password 切替）の前にインスタンスが available になるまで待つようにしました。従来はクラスタの available のみ待っており、 インスタンスが creating の状態で modify が走って反映されない/失敗する可能性がありました。
• management command（migrate 等）の失敗が「緑」で通っていた（false green）のを修正 しました。ハンドラは非同期 (InvocationType="Event") で invoke され戻り値/例外が CLI に 伝わらないため、成功時のみ出力するセンチネルを導入し、CLI 側 (show_logs) が REPORT までにそれを観測できなければ ManagementCommandFailed で非ゼロ終了するようにしました。 これにより pocket deploy 中の migrate 失敗が握り潰されず deploy が止まります。

0.8.0 - 2026-07-03¶

Changed¶

• RDS の既定 DB 名の順序を {project}_{stage} から {stage}_{project} に変更しました （例 myapp_prod → prod_myapp）。クラスタ識別子や Subnet Group など他の RDS リソース名は すべて {stage}-{project} 順（resource_prefix 由来）だったのに、DB 名だけ project 先頭で 順序が食い違っていたのを揃えるものです。
• 既存の RDS プロジェクトへの影響: 既にデプロイ済みのクラスタは DB 名が旧順序 （{project}_{stage}）のままのため、本バージョンにアップグレードして接続すると FATAL: database "..." does not exist になります。旧 DB 名を維持したい場合は、新設の [rds] database で旧名を明示的に固定してください（下記 Added 参照）。新規プロジェクトは そのまま新順序で作成されます。

Added¶

• [rds] database を追加し、RDS の DB 名を明示的に上書きできるようにしました （managed = true 時のみ）。主用途は snapshot からの復元です。 RestoreDBClusterFromSnapshot は DatabaseName を無視するため、復元後のクラスタには snapshot 元の DB 名がそのまま残ります。元ツールが別命名（例 {project}_{stage}）だった場合、 database で実 DB 名を指すことで復元後の接続失敗を防げます。

0.7.2 - 2026-07-03¶

Fixed¶

• TiDB backend の TLS CA バンドルパスを Debian/Ubuntu 命名 (/etc/ssl/certs/ca-certificates.crt) でハードコードしていたため、Amazon Linux 2023 ベースの Lambda（public.ecr.aws/lambda/python、CA は /etc/pki/tls/certs/ca-bundle.crt） では CA ファイルを開けず、ssl_mode = VERIFY_IDENTITY の DB 接続が deploy 後に失敗する 問題を修正しました。候補パスを順に存在チェックする実装に変更し、AL2023 / RHEL 系と Debian/Ubuntu の双方を吸収します。

Added¶

• TiDB backend で CONN_MAX_AGE = None / CONN_HEALTH_CHECKS = True を標準デフォルト化 しました。Lambda は実行環境（コンテナ）を再利用するため、持続接続で warm リクエストの TLS handshake を省けます。idle 切断された接続は再利用前の health check で検知して 張り直すため安全です。

0.7.1 - 2026-07-03¶

Fixed¶

• Neon の provisioning = "deploy" で、既存ブランチ（Neon プロジェクト作成時に自動生成 される default main を含む）があっても branch を無条件に作成しようとして 409 branch already exists で初回 deploy が失敗する問題を修正しました。既存ブランチが ある場合は作成をスキップし、その上に role / database を ensure します（create() / create_branch() を冪等化）。これにより default ブランチを使う stage の初回 deploy が 409 にならず、既存ブランチへの db/role bootstrap も deploy で完結します。

0.7.0 - 2026-07-02¶

Features¶

• staticfiles の publish を deploy から分離できるようにしました。staticfiles 宣言に publish = "command" を指定すると、pocket django deploy / promote は静的ファイルに 一切触れず、publish は pocket django deploystatic に一任されます（DB/KVS の provisioning = "command" と同じ思想の静的版。大容量資産を out-of-band 管理し、CI は コードのみデプロイする構成に対応。既定は従来どおり publish = "deploy"）。
• pocket django deploystatic に --link を追加しました。collectstatic に --link を 渡し、大容量資産の複製コストを削減します（aws s3 sync は symlink を追うため upload 互換）。

Changed¶

• pocket django deploystatic の S3 上の不要ファイル削除を opt-in にしました （--delete フラグ新設）。従来は aws s3 sync --delete 固定で、旧デプロイのアセットを 参照中のリクエスト（キャッシュ済み HTML / 切替前の Lambda が返すページの hash 付き ファイル名）や過去 commit への rollback を壊す時間窓がありました。pocket django deploy / promote 内の静的アップロードも同様に削除なしになります。不要ファイルの掃除は pocket django deploystatic --delete を明示実行してください。

0.6.0 - 2026-06-28¶

Features¶

• DB / KVS の provisioning を deploy から分離できるようにしました。[neon] / [tidb] / [upstash] に provisioning = "command" を指定すると、deploy は当該リソースに一切触れません （管理 API call ゼロ / credential 不要）。provisioning は新コマンド pocket resource <neon|tidb|upstash> store-url --stage <stage> に分離し、 branch/cluster/role/db (Upstash は database) を ensure して接続 URL を stored user secret （[awscontainer.secrets.user] の type）の正準名へ保存します。これにより「provisioning は 管理 API key を持つ host / 特権 CI」「deploy は credential なし」という custody 分離が 素直に成立します（既定は従来どおり provisioning = "deploy"）。
• user secret の type に upstash_redis_url を追加しました（neon_database_url / tidb_database_url と同様の stored mode）。
• store-url は既存 secret があると no-op で、--force で上書きします。複数候補があるときは --key で対象を指定します。
• TiDB の注意: TiDB Serverless は password の reveal API が無いため、tidb store-url は 実行のたびに root password をローテーションします（Neon / Upstash は冪等）。実行後は consumer の再デプロイが前提です。

Changed / Deprecated¶

• DB / KVS 接続 URL の computed mode（[awscontainer.secrets.managed] に { type = "neon_database_url" / "tidb_database_url" / "upstash_redis_url" }）を deprecated にしました。deploy 時に warning を出します。[<db>] provisioning + stored user secret（[awscontainer.secrets.user] の type）へ移行してください。computed と provisioning = "deploy" は「deploy が ensure し URL を供給する」点で挙動が同じで、差分は 保存先のみ（computed = managed pocket_store、stored = user secret 名）です。

Removed¶

• [neon] / [tidb] / [upstash] の skip_check_existing を削除しました （provisioning = "command" へ置換）。残っていると deploy 前に fail-fast で移行を案内します。
• 実行時フラグ --skip-check-existing を削除しました（pocket deploy / pocket promote / pocket django deploy / pocket django promote）。credential-less deploy は [<db>] provisioning = "command" に一本化されました。
• 移行手順: [<db>] skip_check_existing = true を [<db>] provisioning = "command" に置換し、 接続 URL を [awscontainer.secrets.user] の type で宣言、deploy 前に pocket resource <db> store-url --stage <stage> を一度実行してください。

0.5.0 - 2026-06-28¶

Features¶

• [neon] で使用するブランチを選択できるようにしました。これまで Neon の branch_name は stage 名にハードコードされていましたが、branch_name を省略すると project の default ブランチ (通常 main) を使うようになり、stage = ブランチ名の 暗黙の結合を解消しました。[<stage>.neon] で per-stage に上書きでき、 {stage}/{project}/{namespace} を展開できるので、環境ごとに別ブランチを払い出す 使い方もできます。あわせて parent_branch_name を追加し、ブランチを新規作成する際の 親ブランチを指定できます (省略時は Neon の default ブランチから分岐する従来挙動)。 既存の stage 名ブランチ運用は branch_name = "<stage>" を明示すれば維持できます。

0.4.0 - 2026-06-22¶

Features¶

• DB 接続 URL の stored mode を追加しました。[awscontainer.secrets.user] に DATABASE_URL = { type = "tidb_database_url" } / { type = "neon_database_url" } と 書くと、deploy 時に provider の管理 API を叩いて URL を計算する computed mode (secrets.managed) の代わりに、事前 provision して secret store に保存済みの接続 URL を 参照するだけになります。deploy 環境に cluster を作成・削除できる管理 API key を持ち込まず に済み (least privilege)、deploy が外部 API に依存しません。type 指定時は pocket が secret 名を自動導出し、未 provision のまま deploy すると正準名を示して deploy 時にエラーで 止めます (runtime まで遅延しません)。name と type は排他です。RDS は元々管理 API key 非依存かつパスワードローテーション追従のため対象外です。

0.3.0 - 2026-06-16¶

Features¶

• [cloudfront.<name>].enable_origin_verify を追加しました。CloudFront 配下の origin (lambda / API Gateway) に対し、(1) origin 直叩き防止の secret custom header (X-Pocket-Origin-Verify) を CloudFront → origin に付与しつつ同値を Lambda runtime env に注入、(2) 詐称耐性のある client IP (CloudFront が TCP から取得する event.viewer.ip) を X-Pocket-Viewer-Ip header で origin に転送、(3) 検証 + REMOTE_ADDR 正規化を行う Django middleware (pocket.django.origin_verify.OriginVerifyMiddleware) の同梱、を一括で有効化します。 secret は managed secret (type = "origin_verify_secret") として自動生成・管理され、 利用者は flag を立てて middleware を最前段に置くだけで済みます。 viewer IP 転送自体は flag 非依存で lambda route に常時入ります (キャッシュ無影響・ 純加算のため。origin request policy は AllViewerExceptHostHeader のまま据え置き、 CloudFront Function 経由で付与するので API GW の Host 整合性も壊しません)。

0.2.2 - 2026-06-15¶

Bug Fixes¶

• versioning = "deploy_hash" 構成で 2 回目以降の deploy 時に Lambda の環境変数 DEPLOY_HASH が旧値に固着し、Django が古い hash の static URL を生成して CloudFront 側 (毎 deploy 追従) と乖離 → 静的アセットが全滅 (403) する不具合を 修正しました。pocket の Lambda 更新は update_function_code (コードのみ) で Environment を更新せず、env は CFn stack.update() 経由でしか書き換わらないため、 stack 更新が yaml_synced / wait_status timeout 等でスキップされると env が 古いまま残るのが原因でした。deploy フロー末尾の post-deploy hook (AwsContainer.ensure_post_deploy_state) で、CloudFront の KVS 書き込みと同じ philosophy により Lambda env の DEPLOY_HASH を side-channel で冪等に同期する ようにしています (既存 env / secret は保持)。

Security¶

• Rust crate (magic-pocket-rs) の依存ツリーから legacy TLS スタック (rustls 0.21 / hyper 0.14 系) を除去しました。aws-sdk-* の default feature rustls を無効化し、既定の HTTP client (rustls 0.23 + aws-lc) のみを使用します。 動作は変わりません。git 依存で利用している場合は cargo update magic-pocket-rs で取り込めます。

0.2.1 - 2026-06-10¶

Bug Fixes¶

• pocket version が古いバージョン (0.1.1) を表示する問題を修正しました。 __version__ を手書き定数からパッケージメタデータ由来に変更し、 pyproject.toml との二重管理を廃止しています (同期の回帰テスト付き)。

0.2.0 - 2026-06-10¶

0.1.1 以降の全面的な機能拡張リリースです。runtime ライブラリ (magic-pocket) と deploy CLI (magic-pocket-cli) の 2 パッケージ構成になりました。

Breaking Changes¶

• パッケージを 2 分割しました。 deploy CLI (pocket コマンド) は新パッケージ magic-pocket-cli に移動し、magic-pocket は Lambda runtime ライブラリのみに なりました。デプロイ環境には magic-pocket-cli を、Lambda image には従来どおり magic-pocket をインストールしてください。
• AWS リソース系コマンドを resource group 配下へ再配置しました。 旧トップレベル コマンド pocket awscontainer / neon / tidb / dsql / rds / s3 / vpc / cloudfront 等は廃止され、pocket resource awscontainer ... のように resource を 挟む新 path になりました（旧 path には alias を残していないため No such command で失敗します）。CLI を呼び出すスクリプト・上位ツールは新 path への追従が必要です。 例: pocket awscontainer reload-env → pocket resource awscontainer reload-env。
• pocket.django.lambda_handlers.shell_handler を dangerous_shell_handler に リネームしました。 任意文字列を shell=True で実行する危険な handler である ことを名前で明示する目的です（capability 自体は維持）。pocket.toml の handler に旧名を指定している場合は新名への追従が必要です。SQS 駆動でコマンドを安全に 完走させる用途には新設の BaseCommandHandler を利用してください。
• deploy 時の stage 指定環境変数を POCKET_DEPLOY_STAGE に分離しました。 POCKET_STAGE は Lambda runtime 専用になり、ローカルで runtime helper と deploy CLI の stage 指定が干渉しなくなりました。
• Route の type = "api" を type = "lambda" にリネームしました（旧値は起動時に 分かりやすいエラーで失敗します）。
• is_versioned を廃止し versioning に統一しました（"content_hash" = 旧 is_versioned = true 相当 / "deploy_hash" = git hash を URL prefix に付与する 方式を新設）。
• VPC 設定をトップレベル [vpc] セクションへ移動しました。 外部 VPC 参照 (manage = false) と VPC 共有 (sharable = true + consumer タグ管理) も サポートします。
• Route に origin_path を導入し、storage の location を自動計算するように しました（旧 spa.origin_path_format の設定体系は廃止）。
• CloudFront 専用 S3 バケットを廃止し、プロジェクトの S3 バケットに統合しました。
• Neon の project_name を pocket.toml で必須指定に変更しました。
• secrets セクションを再編しました: [awscontainer.secretsmanager.pocket_secrets] → [awscontainer.secrets.managed]、 [awscontainer.secretsmanager.secrets] → [awscontainer.secrets.user]。 保存先 store として Secrets Manager に加え SSM Parameter Store (store = "ssm") を選択可能になりました。

Features¶

• データベース / キャッシュの選択肢を拡張: Neon に加えて TiDB Serverless ([tidb]) / RDS Aurora Serverless v2 ([rds]、既存クラスター参照可・static パスワード管理対応) / Aurora DSQL ([dsql]、IAM 認証・VPC 不要) / Upstash Redis ([upstash]) をサポート。
• Rust (Loco) 対応: magic-pocket-rs crate を追加し、Django 以外に Loco app を 同じ pocket.toml 体系でデプロイできるようになりました。
• CloudFront 統合を全面拡張: [cloudfront.<name>] で複数ディストリビューション、 routes (S3 / lambda)、SPA ルーティング、署名付き URL (signing_key)、SPA トークン 認証 (require_token + CloudFront Function + KeyValueStore)、WAF IP allowlist (waf)、ステージ別アセット配信 (managed_assets)、deploy_hash versioning に よるキャッシュバスティングをサポート。
• :material-console: build once + commit hash 昇格をサポート。pocket django build で 作業ツリーを一度ビルドして git commit hash（full）タグで ECR へ push し、 pocket promote / pocket django promote --commit-hash <sha> で同一イメージを 再ビルドなしで各ステージへ昇格できます（:<stage> タグの付け替え + Lambda 更新）。 [awscontainer].ecr_name で ECR リポジトリ名を上書きでき、同一アカウント内の ステージ間でリポジトリを共有可能（明示指定したリポジトリは pocket destroy で 削除されません）。通常の pocket django deploy の挙動は不変です。
• SQS 駆動の安全な command worker 基盤 pocket.command_handler.BaseCommandHandler を追加。SQS イベントを別 Lambda invocation の本体として受け、build_argv で固定 した実行ファイルを shell=False の list argv で完走させ、出力 / ステータスを sink hook（on_start / on_output / on_finish / on_crash）に委譲します。long-running job を wsgi tier から worker tier に逃がす定石を共通化し、Lambda の freeze による 「ステータスが running 固着」を構造的に防ぎます。crash 時は try/finally で on_crash を呼んでから例外を re-raise（握りつぶさない）。dangerous_shell_handler の安全な後継です。
• EventBridge Scheduler サポート ([scheduler]): cron / rate での定期実行を CloudFormation 管理で構成。Django management command を呼ぶショートカット entry (pocket.django.management_lambda_scheduler) もあります。
• VPC + EFS サポート: NAT / Internet Gateway 構成、EFS マウント、Django キャッシュの EFS 利用 (store = "efs")。
• デプロイ権限の可視化: pocket permissions list CLI と Python API (pocket.permissions.compute_actions() / action_groups()) で、pocket.toml の 構成に必要な IAM Action 一覧を機械可読に提供。デプロイ用 IAM Role の最小権限 プロビジョニングに使えます。
• ビルドバックエンドの選択: [awscontainer.build] で codebuild（既定）/ docker / depot を選択可能。ローカル Docker なしでデプロイできます。
• IAM Permissions Boundary 対応 ([awscontainer].permissions_boundary)。 Lambda 実行ロールと CodeBuild ロールに適用されます。
• pocket runtime-config: ビルド専用設定を除外した pocket.runtime.toml を 生成し、Lambda image に焼き込む仕組みを導入。
• SES メール送信 ([ses]): Django email backend の自動構成つき。
• pocket waf ip CLI: WAF IPSet の side-channel 即時更新（add / remove / list）。
• pocket resource awscontainer reload-env / status-env: SSM / Secrets Manager の最新値で Lambda 環境変数を即時更新（CFn を介さない）/ 宣言値との drift 表示。
• :material-console: pocket django deploy でインフラデプロイ + ローカル collectstatic + Lambda 上での migrate を対話形式で一括実行。
• :material-console: pocket django resetdbでデータベースの public スキーマをリセット（DROP SCHEMA public CASCADE）
• S3 バケット名のカスタマイズ ([s3].bucket_name_format) とステージ別 [<stage>.general] 上書き（region 等）。

Bug Fixes¶

• pocket permissions list / compute_actions() に deploy が実際に必要とする Action の宣言漏れが 5 件あったのを修正。権限を絞ったデプロイ用ロールで 該当構成を deploy すると AccessDenied になっていた: dsql:*（[dsql] 構成の cluster 操作）/ scheduler:*（[scheduler] 構成の CFn AWS::Scheduler::Schedule 作成）/ tag:TagResources・tag:UntagResources （外部 VPC 参照時の consumer タグ付け外し）/ iam:ListRolePolicies （CodeBuild ロール削除時の inline policy 列挙）/ ssm:GetParameter・ ssm:PutParameter・ssm:DeleteParameter（[rds] の static master password 管理。secrets.store とは独立に必要）。action_groups() に dsql / scheduler / tag グループを追加（キー追加のみの非破壊変更）。
• POCKET_HOSTS 環境変数が複数ホストをセパレータなしで連結していたのを カンマ区切りに修正（Python / Rust 両ランタイム）。apigateway 付き handler を 2 つ以上定義すると、Django の ALLOWED_HOSTS に壊れたホスト名が入り 2 つ目以降のホストが DisallowedHost になっていました（消費側の add_or_append_env は元々カンマ結合を前提としており、handler 1 つの構成では 影響ありません）。
• pocket resource awscontainer reload-env / status-env が Lambda 関数名から namespace（既定 pocket）を取りこぼし、default namespace のデプロイで常に 「Lambda function が見つかりません」で失敗していたのを修正（deploy 側と同じ 正準 function_name を参照）。あわせて status-env の drift 警告が案内する コマンドが旧 path のままだったのを新 path に修正。

Improvements¶

• deploy コードと compute_actions() の同期検証テストを追加 (tests/test_permissions_sync.py)。boto3 呼び出しの AST 静的解析と CloudFormation テンプレートのリソース型解析の 2 系統で、deploy が必要とする Action の宣言漏れを CI で検知する（過去に 3 回再発した「権限を絞った deploy ロールが本番で AccessDenied」の構造的な再発防止。未知の CFn リソース型の 追加時はテストが fail し権限の検討を強制する）。同期方針は docs/permissions/aws.md に記載。
• S3バケットのCORS設定をpocket.tomlで宣言可能に（CloudFrontドメイン自動解決）
• pocket destroyがデフォルトでシークレットも削除するように変更（--without-secretsで残す）
• pocket destroyでCloudFrontスタック削除の完了を待機するように修正
• pocket deploy時にSSM/SMの不要なシークレットを自動クリーンアップ

0.1.1 - 2024-10-16¶

Full Changelog: https://github.com/worgue/magic-pocket/compare/0.1.0...0.1.1

Bug Fixes¶

• spa用のリソース作成時にリダイレクトするためのリソースが作られないバグを修正

0.1.0 - 2024-10-11¶

Dependencies¶

• click>=8.1.7
• tomli>=1.1.0 ; python_version < '3.11'
• mergedeep>=1.3.4
• pydantic>=2.5.3
• pydantic-settings>=2.1.0
• boto3>=1.34.28
• rich>=13.7.0
• deepdiff>=6.7.1
• pyyaml>=6.0.1
• python-on-whales>=0.68.0
• jinja2>=3.1.3
• awslambdaric>=2.0.10
• apig_wsgi>=2.18.0
• django-storages>=1.14.2,!=1.14.3

Features¶

• :material-console: pocket statusで環境の作成状況を確認
• :material-console: pocket deployでデプロイ
  • :material-database: NeonへのDB作成
  • :simple-awssecretsmanager: SecretsManagerへのNeon DBの接続情報登録
  • :simple-amazons3: ストレージ用にS3を作成し権限を設定
  • :simple-docker: コンテナイメージを作成しECRへアップロード
  • :material-language-javascript: フロントエンドSPAのビルドデータをアップロードするS3を作成
  • CF: Lambdaに関わるCloudFormationを登録・更新
    • LambdaのIAM Role, SecurityGroup, Function
    • API Gateway の LogGroup, Api, ApiGatewayManagedOverrides, Route, Integration, lambda Permission, Certificate, DomainName, RecordSet, ApiMapping
    • API Gatewayのhost名のoutput
  • CF: SPAに関わるCloudFormationを登録・更新
    • CloudFrontのOriginAccessControl, Certificate, CloudFrontFunction, Distribution, RecordSet
• :material-language-python: settings.pyでの情報取得
  • :simple-awssecretsmanager: AWS SecretsManagerから情報を取得(1)
  • :simple-toml: pocket.tomlからdjangoのSTORAGES, CACHESを取得
  • CF: CloudFormationのoutputからdjangoのALLOWED_HOSTSを取得
• :simple-toml: デプロイ環境ごとのdjango settings登録
• :material-console: pocket django manage COMMAND ARGS で管理コマンドを実行
• :material-console: pocket django storage upload STORAGE でローカルのFileSystemStorageから対象ステージのS3Boto3Storageへデータをsync
• :material-console: pocket resource awscontainer statusでLambdaの作成状況を確認
• :material-console: pocket resource awscontainer secretsmanager listでSecretsManagerの値を確認
• :material-console: pocket resource awscontainer yamlでCloudFormation用のyaml ファイルを確認
• :material-console: pocket resource awscontainer yaml-diffでCloudFormation用のyamlファイルの差分を確認
• :material-console: pocket resource neon statusでNeonの作成状況を確認
• :material-console: pocket resource s3 statusでS3バケットの作成状況を確認
• :material-console: pocket resource spa statusでspaアップロード先S3バケットの作成状況を確認