Cube

這個頁面還沒有翻譯成繁體中文：以下是英文版。

Cube runs an image as a service, called a Cube, and in the API an app. You give it an image and a port. It gets an address under glac.run, and it can have your own domains too. When a request comes, the platform starts an instance of it in milliseconds. When no requests come, the instances sleep and cost nothing but what they keep. Each deploy is a new version: it takes the traffic once it is ready, and you can send the traffic back to an earlier one.

The names

Cube is the product’s name, and each service it runs is a Cube. The API’s calls for it are /v1/apps: an app, its versions and its instances. The SDKs’ objects (App) and the command line’s options use the same word, and so do these pages.

The commands are glac cube …, and glac deploy for short. The SDKs’ namespace is glac.cube (client.Cube in Go, cube() in Rust and Java), the MCP server’s tools are cube_*, and the console’s page is Cube, under Compute. workers is another name for each of them (glac workers …, glac.workers, the tools worker_*), kept for code written with it; the SDKs mark it deprecated.

When to use Cube

• A web service or an API that should answer at its own address and cost nothing while nobody calls it.
• Many small services of one project that find each other on a private network, such as a web app, a background worker and a database. A Compose file can be imported as they are. See services and Compose.
• One instance per user, session or tenant, picked by a key in the request, each with its own memory and disk. See keyed instances.

To run code that a program or an AI agent sends at run time, with commands, files and terminals, use Sandbox. Both run on the same machines, at the same prices.

How it works

1. Deploy. glac deploy IMAGE (or POST /v1/apps) makes the app and its first version. The platform pulls the image, starts it once on the machines of each region the app runs in, waits until it is ready, and saves it as a template.
2. Serve. A request at the app’s address goes to a machine in the region it comes in at. An instance that is awake answers it. Otherwise one is woken, or made from the template, which takes milliseconds because the service is already running in the template.
3. Sleep. An instance sleeps a while after its last request ends: how long is picked from the app’s traffic, so that it stays awake through gaps a sleep would cost more than, and sleeps at once when requests are far apart (sleep_after_ms, three seconds unless you say, is the most). An instance that stays asleep for an hour is deleted; the next request makes a new one.

What it costs

Cube and Sandbox have the same prices. An instance pays for the CPU it uses and the memory it holds while it is awake. Asleep, it uses no CPU: one held paused in the machine’s memory still pays for that memory, and one whose memory is saved pays only for what it keeps, by the GB-month. An instance that is deleted keeps nothing.

On Free, what an instance uses comes out of the day’s quotas; Paid includes a quantity of each meter every month, and past it usage is paid from the balance at these prices. See pricing and plans.

Limits of each plan

The awake instances, their vCPUs and their memory are counted for the whole account: sandboxes and instances of every project together. Every limit is on the limits page.

Next

• Quickstart: deploy an image, change it, roll it back, with the command line, Python or the console.
• Deploys and versions: what makes a version, what happens when one fails, rollbacks.
• Instances and scaling: when instances start, sleep and are deleted, how many there are, regions.
• Keyed instances: one instance per key, kept with its memory and disk.
• Addresses and protocols: the default domain, your own domains, private apps, HTTP/2, gRPC and WebSockets.
• Services and Compose: several services of one project, their private network, shared variables, a service with a Drive.