デプロイ URL

デプロイが完了すると、プロジェクトの既定のアドレスが生成されます。

my-app.me.runlot.app

<プロジェクト>.<組織>.runlot.app という形式です。

以前の -- のアドレスは廃止しました

以前はプロジェクト名と組織名を 1 つのラベルにまとめ、my-app--me.runlot.app という形にしていました。この形式はもう登録されません。デプロイは 2 ラベルの名前だけを登録し、変更前にデプロイしたプロジェクトも新しいアドレスへ移しました。以前のアドレスをどこかで共有している場合は更新してください。そのアドレスはもう解決されません。

ラベルを分けられるようになった理由

ワイルドカード証明書はサブドメインのラベル 1 つだけを覆います。そのため *.runlot.app の証明書 1 枚では、ラベルが 2 つあるアドレスを扱えませんでした。現在は組織ごとに *.<組織>.runlot.app のワイルドカード証明書を ACME DNS-01 で自ら発行しています。主となる認証局は Google Trust Services で、失敗した場合は Let's Encrypt に切り替えます。これにより、プロジェクトと組織がそれぞれ自分のラベルを持てます。

名前のルール

組織 slug とプロジェクト名は、次のルールに従う必要があります。

• ^[a-z0-9](-?[a-z0-9])*$
• 最大 30 文字 (DNS ラベルの 63 文字制限をもとに算出)
• 名前にハイフン 2 つ (--) を使用できません

既定のアドレスは -- を使わなくなりましたが、このルールは維持します。PostgreSQL の直接接続アドレスは今も 2 つの名前を -- でつなぎ (my-app--me.wire.runlot.app)、このルールがないと a--b 組織の c プロジェクトと a 組織の b--c プロジェクトが同じ接続アドレスを持つことになります。

TLS

このアドレスの TLS 証明書は、フロントで自動的に管理します。別途設定する必要はなく、http:// のリクエストは https:// にリダイレクトします。

保有しているドメインを接続する場合は、カスタムドメインを参照してください。

ワーカーが受け取るヘッダー

フロントは現在の配置情報をリクエストヘッダーに追加します。このヘッダーは問題を調査するときに役立ちます。

request.headers.get("Runlot-Project-Id");
request.headers.get("Runlot-Epoch");
request.headers.get("Runlot-Node");
request.headers.get("Runlot-Slot");

クライアントが送信した Runlot-* ヘッダーは、フロントですべて取り除いたうえで、信頼できる値として付け直します。そのため、クライアントがこれらのヘッダーの値を偽装することはできません。