アドレスとプロトコル

デフォルトのアドレス

どのアプリにも https://<app name>-<project>.glac.run があります。<project> はプロジェクト ID の 6 文字です。アプリは作成された時点からこのアドレスを持ち、アプリの名前を変えるとアドレスも変わります。glac cube get とアプリの url で確認できます。

このアドレスへのリクエストは、プラットフォームの前段にあるプロキシを通ります。プロキシは TLS を処理し、大量のトラフィック（DDoS）を防ぎます。プロキシには独自の制限があり、リクエストボディは最大 100 MB、レスポンスの無通信時間は最大 125 秒です。それを超えるなら、アプリに direct: true を設定します（glac cube update api --direct true）。するとアプリは direct.glac.run の下の direct_url でも応答するようになります。こちらはプロキシを通らず、前段にあるのはプラットフォーム自身の制限だけです。プロキシの制限と各製品のダイレクトな名前は、アドレスにまとめて記載しています。

すべてのアプリとサンドボックスのリンクは、glac.run の下に専用の名前を持ちます。glac.run が Public Suffix List に載るまでは、そのどれかの下にあるページが glac.run 全体に対する Cookie を設定でき、ほかの顧客のページがそれを読めます。アプリの Cookie は自身の名前に限定し（Domain 属性を付けない）、ドメイン全体を対象とする Cookie は信用しないでください。

独自ドメイン

{"domain": "api.example.com", "app": "api"} を付けた POST /v1/domains で、独自の名前をアプリに向けます（サンドボックスのポートに向けるなら {domain, sandbox, port}）。レスポンスには、その名前の所有を証明する DNS レコードが示されます。

• プロキシ経由（デフォルト、proxied: true）：独自の名前から <token>.glac.run への CNAME。プロキシが名前を確認し、証明書を発行します。
• ダイレクト（proxied: false）：<token>.direct.glac.run への CNAME。CNAME を持てないドメインの頂点の名前では、トークンを入れた _sandbox-domain.<your name> の TXT レコードと、レスポンスが示すアドレスに向けた、名前の A レコードと AAAA レコード。

証明書の発行と更新は自動で行われます。名前のアドレスはすべてプラットフォームを指している必要があり、ダイレクトな名前の前段にほかのプロキシや CDN を置くことはできません。名前が使えるようになった後もレコードを DNS に残してください。なければ証明書は更新されません。

glac domains create api.example.com --app api でも同じことができ、レコードが表示されます。残りの操作は glac domains ls、get、update、rm で行います。SDK（Python では glac.domains）と MCP サーバーの domain_* ツールでも同じことができます。

ドメインの status は pending_verification、pending_certificate、active、detached（アプリかサンドボックスが削除された）のいずれかです。デプロイやロールバックでドメインを変更する必要はなく、ドメインはアプリに追従します。1 つのプロジェクトのドメインは最大 100 個です（403 domain_limit_reached）。ドメインの登録、変更、削除には admin スコープを持つキーが必要です。

インターネット上のアドレスを持たないアプリ

public: false（--public false）のアプリには、デフォルトのアドレスがありません。プロジェクトのほかのサービスとサンドボックスは、プロジェクトのプライベートネットワーク上で <app name>.internal からアクセスし、アプリに向けたドメインはそのまま使えます。サービスと Compose を参照してください。

プロトコル

クライアントは HTTP/1.1、HTTP/2、HTTP/3 でアプリにアクセスします。HTTP/2 か HTTP/3 で届いたリクエストは、サービスが TLS なしの HTTP/2（h2c）に対応していればそれで、対応していなければ HTTP/1.1 でサービスに届きます。設定は不要で、プラットフォームがポートに一度問い合わせます。HTTP/1.1 で届いたリクエストは HTTP/1.1 で届きます。

• gRPC は、サービスが TLS なしの HTTP/2 に対応していれば動作します。通常のポートで動く gRPC サーバー（gRPC-Go、tonic、grpc-js、grpcio）は対応しています。単項呼び出し、片方向・双方向のストリーム、メタデータ、トレーラー、ステータスコードはそのまま通過します。アプリのアドレスのポート 443 に TLS で呼び出してください。
• 呼び出しやストリームは 1 つのリクエストとして数えられます。開いている時間の長さや、流れるメッセージの数は関係ありません。開いている間、インスタンスは稼働中で、稼働中として計測されるため、長いストリームには期限を設けてください。
• **トレースヘッダー。**リクエストの traceparent と tracestate（W3C Trace Context）は、HTTP/1.1 でも HTTP/2 でも、クライアントが送ったとおりにサービスに届きます。ただし、アプリのリクエストのトレースにプラットフォームを参加させている場合（アプリの traces）は、サービスにはプラットフォーム自身の traceparent が届き、そのスパンがサービスのスパンの親になります。クライアントの tracestate が届くのは、アプリがクライアントのトレースを引き継ぐ場合だけです。トレースを参照してください。
• WebSocket は HTTP/1.1 で届きます。インスタンスがスリープしている間も開いたままで、新しいデータが届くとインスタンスが復帰します。
• **サービスへの接続は共有されます。**応答の後、プラットフォームはインスタンスのポートへの接続を少しの間（キーのないインスタンスでは 1 秒、キー別インスタンスやサンドボックスでは 200 ミリ秒）開いたままにし、次のリクエストをその接続で送ります。それはほかのクライアントのリクエストかもしれません。HTTP/2 では、もともと 1 つの接続がすべてのクライアントのリクエストを運びます。そのため、NTLM のようにログインを TCP 接続に結び付けるサービスは、これらのアドレスの背後に置けません。このように保たれた接続は、インスタンスを稼働させ続けません。