アプリの各インスタンスは、バージョンのテンプレートから作られたサンドボックスなので、作成された時点で中のサービスはすでに動いています。インスタンスはプロジェクトのサンドボックスの一覧に app ラベル付きで載り、ほかのサンドボックスと同じく計測され、中でコマンドを実行することもできます（glac sandboxes exec）。
インスタンスがスリープするタイミング
インスタンスを稼働させ続けるのは、次の 3 つだけです。
- 応答中のリクエスト（gRPC の呼び出しのような、開いている HTTP/2 ストリームは、終わるまで 1 つのリクエスト）
- インスタンスを使う API 呼び出し（中で実行するコマンドなど）
- インスタンス自身のプログラムがかけるホールド（下記）
CPU の使用、パケット、開いている接続、タイマーでは稼働し続けません。これらのうち最後のものが終わると、しばらく待ってスリープします。待つ時間はアプリ自身のトラフィックから決まります。リクエストの間隔がスリープと復帰に見合うより短ければ、合間も稼働したまま待ち、間隔が長ければ、応答し終えるとすぐにスリープします。待つ時間の最長は scale.sleep_after_ms です（指定しなければ 3 秒、最大 600,000。0 なら常にすぐスリープ）。アプリへのリクエストがまだ少ないうちと、インスタンスが WebSocket を開いている間は、sleep_after_ms を設定していればその時間いっぱい、設定していなければ 100 ミリ秒待ちます。応答後に行う処理は、次のリクエストで復帰するまで一時停止します。WebSocket はインスタンスがスリープしている間も開いたままで、新しいデータが届くと復帰します。
応答後の処理
応答後にまだ処理が残るハンドラー（ほかのプラットフォームの ctx.waitUntil() のようなもの）は、応答する前にインスタンス内の Unix ソケット /run/sbx/awake でホールドをかけ、処理が終わったら解除します。インスタンスはリクエストの後と同じように待ってから停止します。ホールドのかけ方はコード付きでスリープと復帰にあります。
scale.sleep_hold_max_msは、アイドル時間が尽きた後に、ホールドでインスタンスを稼働させ続けられる時間の上限です。指定しなければ 30,000 ミリ秒、最大 900,000 で、0ならホールドを無視します。scale.sleep_notice_msを設定すると、停止のその時間前に、プログラムにsleep <ms>が通知されます（指定しなければなし、最大 60,000）。- ホールドされている間、インスタンスは稼働中として計測されます。
インスタンスが削除されるタイミング
scale.delete_after_ms の間、何によっても稼働させられなかったインスタンスは削除されます。指定しなければ 1 時間で、それより短くする場合は 1 秒以上を指定します。次のリクエストで、テンプレートから新しいインスタンスがミリ秒で作られます。削除されたインスタンスは何も保持しないため、データを保持しなければならないサービスは、ドライブか、削除されないキー別インスタンスを使います。
インスタンスの数
| 設定 | 内容 |
|---|---|
scale.min_instances |
リクエストの有無にかかわらず、各リージョンで稼働させ続けるインスタンスの数（指定しなければ 0）。稼働中として計測される |
scale.max_instances |
1 つのリージョンでのインスタンスの最大数。指定しなければ、指定のないアプリに対するプランの数値（下記） |
scale.concurrency |
1 つのインスタンスが同時に抱えるリクエストの最大数（1〜1,000）。指定しなければ、CPU かメモリが埋まった時点でインスタンスは満杯とみなされ、プラットフォームが別のインスタンスを起動する。一度に 1 つのリクエストしか処理しないサービスは 1 を指定すること |
glac cube update api --min-instances 1 --max-instances 20 --concurrency 50 --sleep-after-ms 2000これらはすぐに反映され、バージョンは作られません。プランの数値を超えるデプロイや更新は拒否されます（403 plan_cap_reached、param は app_instances）。
| 無料プラン | 有料プラン | |
|---|---|---|
1 アプリの 1 リージョンあたりのインスタンス数：max_instances 未指定時 / 上限 |
2 / 5 | 50 / 500 |
| インスタンスの同時稼働数 | 5 | 500 |
| それらの vCPU の合計 | 10 | 500 |
| それらのメモリの合計 | 10 GiB | 1,000 GiB |
稼働中のインスタンス、vCPU、メモリは、サンドボックスと合わせてアカウント全体で数えられます。複数のリージョンで動くアプリは、アカウントの残りをリージョン間で分け合います。各リージョンの取り分は、最近稼働していたインスタンスの数に応じて決まり、取り分以上を必要とするリージョンには、ほかのリージョンが使っていない分が数秒以内に回されます（その間、リクエストは別のリージョンにあるアプリのマシンへ送られます）。これらの制限はクォータであり、予約ではありません。リージョンのマシンが満杯なら、制限内でも新しいインスタンスが拒否されることがあります。
動く場所
アプリは、指定したリージョン（regions：na、eu、ap。指定しなければ 3 つすべて）で動きます。リクエストには、届いたリージョンで、そこでアプリを処理するマシンが応答します。別のリージョンが引き受けるのは、そこにあるどのマシンも応答できない場合だけです。min_instances と max_instances はリージョンごとに数えます。リージョンを参照してください。
サイズ
size は {vcpus, memory_bytes} です。最小で 1 vCPU と 128 MiB、メモリは偶数の MiB（マシンのメモリを読み込む単位である 2 MiB ページの整数倍。それ以外は 400 invalid_field で拒否）、最大でプランのインスタンスの最大サイズ（無料プランでは 2 vCPU と 4 GiB、有料プランでは 8 vCPU と 16 GiB）です。指定しなければ 2 vCPU と 4 GiB です。コマンドラインでは --vcpus 4 --memory-bytes 8GiB です。サイズはバージョンの一部なので、変更すると新しいバージョンがデプロイされます。