デプロイ URL

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

my-app.me.runlot.app

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

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

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

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

ワイルドカード証明書が対象にできるサブドメインのラベルは 1 つだけです。そのため *.runlot.app の証明書 1 枚では、ラベルが 2 つあるアドレスを扱えませんでした。現在は runlot が組織ごとに *.<組織>.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 プロジェクトが同じ接続アドレスを持つことになります。

プロジェクト名を変更するとこのアドレスも変わります

管理者はプロジェクトの設定タブ、または runlot project rename <現在の名前> <新しい名前> でプロジェクト名を変更できます。既定のアドレスは名前に合わせて移り、証明書を再発行する必要はありません — 組織のワイルドカード証明書が、その下のすべてのプロジェクトラベルをすでに含んでいるからです。

旧アドレスはすぐに応答を停止し、別名は残しません。 両方を残すと 1 つのプロジェクトにアドレスが 2 つできてしまい、どちらが正式なものか言えなくなります。次の項目はご自身で修正してください:

• runlot.json の name
• git remote (runlot repo list が新しいアドレスを表示します)
• 保存しておいた PostgreSQL の接続文字列 (runlot pg connect)

保存されたデータは移動しません。データベース、env.storage のファイル、バックアップ世代、シークレット、リポジトリの内容はすべて名前ではなくプロジェクト id で管理されるため、名前を変更してもコピーや再作成は行われません。カスタムドメインもそのまま接続されたままです。

名前に追従しないものが 1 つあります — すでに有効にしたメールアドレスは旧名のままです。 メールを有効にした時点で固定されます。外部からすでにそのアドレス宛にメールが届いているからです。移したい場合はメールを解除してから再度付与してください。その時点から旧アドレス宛のメールは届かなくなります。

組織のスラッグは別です — 変更できません。ワイルドカード証明書はまさにそのラベルに対して発行されるため、変更するには証明書を再発行し、その間も旧名が解決され続けるようにしておく必要があります。

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