Würfel
Würfel
Jedes Container-Image, bei jeder Anfrage wach
Dein Image als App unter eigener Adresse. Ihre Instanzen wachen bei Anfragen auf, schlafen ein, sobald keine mehr kommen, und machen dort weiter, wo sie aufgehört haben.
Würfel in Zahlen
In drei Schritten
Dieselben Aufrufe über die Kommandozeile, die API, die SDKs und den MCP-Server.
Bevor du anfängst
Speichere deinen API-Schlüssel in GLAC_API_KEY.
curl -fsSL https://glac.ai/install.sh | sh
export GLAC_API_KEY=ak_...API=https://api.glac.ai/v1
AUTH="Authorization: Bearer $GLAC_API_KEY"from glac import Glac
glac = Glac()import { Glac } from "glac";
const glac = new Glac();# give your agent the tools (Claude Code here)
claude mcp add glac -e GLAC_API_KEY=ak_... -- npx glac-mcpEin Image deployen
Daraus wird eine Version, die den Traffic übernimmt, sobald sie bereit ist, unter einer eigenen Adresse.
glac deploy ghcr.io/acme/api:1.4 \ --name api --port 8080curl $API/apps -H "$AUTH" --json '{"name": "api", "image": "ghcr.io/acme/api:1.4", "port": 8080}'app = glac.cube.deploy("ghcr.io/acme/api:1.4", name="api", port=8080)const app = await glac.cube.deploy("ghcr.io/acme/api:1.4", { name: "api", port: 8080 });cube_deploy {"app": "api", "image": "ghcr.io/acme/api:1.4", "port": 8080}Aufrufen
Die erste Anfrage weckt eine Instanz.
curl https://api-‹project›.glac.run/curl https://api-‹project›.glac.run/import urllib.request print(urllib.request.urlopen(app.url).status)console.log((await fetch(app.url)).status);# from a sandbox made for the one command sandbox_run {"command": "curl -s https://api-‹project›.glac.run/"}Beobachten
Eine Zeile pro Anfrage: ob sie eine Instanz geweckt hat und wie lange das gedauert hat.
glac cube logs api -fcurl -N "$API/apps/api/logs?follow=true" -H "$AUTH"for line in app.logs(follow=True): print(line)for await (const line of app.logs({ follow: true })) console.log(line);cube_logs {"app": "api", "kinds": ["requests"]}
‹project› steht für sechs Zeichen der ID deines Projekts. In der API heißt ein Würfel „App“.
Funktionen
Schläft, sobald keine Anfragen mehr kommen, und ist für die nächste in 3.5 ms wach.1
Jedes Deployment ist eine Version: Der Traffic wechselt, sobald sie bereit ist, und mit einem Aufruf wieder zurück.
Eine Instanz für jeden Schlüssel, erstellt bei seiner ersten Anfrage, mit eigenem Arbeitsspeicher und eigener Festplatte.
Skalierung in jeder Region: Instanzen starten, wenn Anfragen kommen, bis zur Höchstzahl, die du erlaubst.
Deine eigene Domain, mit einem Zertifikat, das wir für dich ausstellen und erneuern.
Deine Compose-Datei wird zu einem Würfel pro Dienst, jeder über seinen Namen erreichbar.
Beispielhafte Vorschauen
Im Vergleich
Verglichen mit den zwei üblichen Arten, einen Dienst zu betreiben.
| Server im Dauerbetrieb | Container mit Scale-to-Zero | Würfel | |
|---|---|---|---|
| Die erste Anfrage nach einer ruhigen Phase | Sofort beantwortet | Wartet, während er neu aus seinem Image startet | Weckt ihn in 3.5 ms1 |
| Arbeitsspeicher und Prozesse im Leerlauf | Erhalten | Verloren | Erhalten, solange er schläft: eine Stunde lang oder, bei Instanzen mit Schlüssel, so lange sie bestehen |
| Was du im Leerlauf zahlst | Den vollen Preis | Nichts | Keine CPU-Zeit; nur, was er behält |
| Von anderen isoliert durch | Eine virtuelle Maschine | Meist ein geteilter Kernel | Eine eigene microVM |
Einsatzbereiche
APIs und Web-Apps
Die CPU wird pro aktiver Millisekunde abgerechnet, zwischen Anfragen schläft die App.
glac deploy ghcr.io/acme/web:2.0 \ --name web --port 3000 curl https://web-‹project›.glac.run/Ein Backend pro Nutzer oder Agent
Eine Instanz pro Schlüssel, jede mit eigenem Arbeitsspeicher und eigener Festplatte.
glac.cube.deploy( "ghcr.io/acme/agent:3", name="agent", port=8080, keys={"from": {"header": "User"}})Jobs
Ein Image, das bis zum Ende läuft und dann stoppt.
glac deploy ghcr.io/acme/report:1 \ --name report --kind job glac cube logs report -f
Preise und Limits
Abgerechnet nach den Würfel-Ressourcen, die es nutzt, wie jedes Produkt. Alle Preise und Tarife
| Was gezählt wird | Zählweise | Preis |
|---|---|---|
| CPU | Aktive CPU-Zeit, auf die Millisekunde genau | $0.01 / Million CPU-Millisekunden$0.00001 / CPU-Sekunde$0.036 / CPU-Stunde$26.28 / CPU-Monat |
| Arbeitsspeicher | Belegt, auf die Millisekunde genau, in Schritten von 128 MiB | $0.00222 / Million GiB-Millisekunden$0.00000222 / GiB-Sekunde$0.008 / GiB-Stunde$5.84 / GiB-Monat |
| Anfragen | Pro Anfrage an einen Würfel oder über einen Sandbox-Link | $0.30 / Million |
| Ausgehender TrafficNA · EU | Pro GB aus Nordamerika und Europa | $0.004 / GB |
| Ausgehender TrafficAPAC | Pro GB aus Asien-Pazifik | $0.01 / GB |
| Gespeicherter Zustand3 | Was schlafende Instanzen behalten, sowie Snapshots | $0.00000761 / Million GB-Millisekunden$0.00000000761 / GB-Sekunde$0.0000274 / GB-Stunde$0.02 / GB-Monat |
| Logs3 | Aufbewahrte Ausgaben von Würfeln, nach ausgegebener Größe | $0.00000761 / Million GB-Millisekunden$0.00000000761 / GB-Sekunde$0.0000274 / GB-Stunde$0.02 / GB-Monat |
Monatskosten schätzen
Ein echter Workload und was ein Monat davon im Bezahltarif und im Gratistarif kostet.
JSON rein, JSON raus, ein, zwei Datenbankaufrufe.
Serverseitig gerenderte Seiten, mit Anmeldung.
Jede Anfrage wartet auf die Antwort eines Modells.
Ereignisse anderer Dienste und geplante Aufgaben.
Eine Instanz ist im Schnitt 23.8 Stunden am Tag wach und weitere 0.21 Stunden im Arbeitsspeicher pausiert. Zur eigenen CPU-Zeit jeder Anfrage kommen 0.61 ms pro Anfrage hinzu: für die Wachzeit zwischen den Anfragen und für jedes Anhalten und Aufwachen.
Ein Monat mit 30 Tagen, nur dieser Workload auf dem Konto. Quellen
Ein Monat im Bezahltarif
$0.39 pro Million Anfragen
- CPU11 Mio. CPU-ms$0.11
- Arbeitsspeicher90 GiB-h$0.72
- Anfragen10 Mio. Anfragen$3.00
- Gespeicherte Daten$0.00
- NVMe-Cache$0.00
- Ausgehender Traffic6 GB$0.02
- Nutzung zu Listenpreisen
- $3.85
- Im Bezahltarif enthalten
- −$3.85
- Gebühr des Bezahltarifs
- $5.00
Über den Grenzen des Gratistarifs: Anfragen.
Glac$3.85
Nach Größe
Was die Tarife erlauben
Alle Limits aller Tarife| Gratistarif | Bezahltarif | |
|---|---|---|
| Würfelpro Konto | 10 | 500 |
| Instanzen eines Würfelsin jeder Region, höchstens | 5 | 500 |
| Gleichzeitig wachInstanzen und Sandboxen | 5 | 500 |
| Größte Instanz | 2 vCPUs, 4 GiB | 8 vCPUs, 16 GiB |
| Variablen und Secretspro Würfel | 64 | 128 |
| Aufbewahrte Logs | 3 Tage | 30 Tage |
Abgeschottet
Eine virtuelle Maschine für jede Instanz; alles, was sie speichert, ist mit dem Schlüssel deines Projekts versiegelt.
SicherheitEine eigene microVM
Eine Firecracker-microVM mit eigenem Kernel, gebootet aus deinem Image.
Ein Jail um sie herum
Ein leeres Root-Dateisystem, ein Nutzer ohne Rechte, eigene Limits.
Erreichbar über die API
Befehle und Dateien laufen über einen Agenten in ihr, nicht über ihr Netzwerk.
Das Netzwerk, das du erlaubst
Ein privates Netzwerk pro Projekt; Regeln dafür, welche Hosts eine Instanz erreichen darf.
Mit deinem Schlüssel versiegelt
Festplatten, schlafender Arbeitsspeicher, Snapshots und Logs, bevor sie die Maschine verlassen.
Schlüssel, die nur öffnen, wofür sie gelten
Ein API-Schlüssel öffnet ein Projekt, so weit seine Scopes es erlauben; ein Audit-Log zeichnet auf, was er tut.
Weiterlesen
- WürfelAdressen, Versionen, Instanzen und wann sie schlafen, Protokolle, Instanzen pro Schlüssel.
- Dienste und ComposeDas private Netzwerk, gemeinsame Variablen, mehrere Dienste deployen, Compose-Dateien.
- Logs und ExportDas Log eines Würfels, seine Metriken und wie du beides an jeden OpenTelemetry-Empfänger sendest.
- Die API-ReferenzJeder Aufruf für Apps, Versionen, Instanzen und Domains.
Die Plattform
Würfel
Verwaltete Anwendungen
- SandboxEin eigener Computer für jeden Agenten
- BaldBrowserEchte Browser, per Code gesteuert
- BaldServerless PostgresPostgres, das im Leerlauf schläft und bei einer Verbindung aufwacht
- BaldApps von DrittanbieternOpen-Source-Projekte, von uns für dich betrieben, später ein Marktplatz