Self-driving infrastructure - ship sandboxes onto the infrastructure you already run
Execution model
Use the capacity you own first. Add the cloud when it earns its keep.
Platform features
Many more things
Self-hosted clustering
Group your own hosts into self-hosted clusters and place sandboxes by host, traits, tags, and runtime health.
Blueprint supply chain
Oops!... you did it again
Import an OCI image, capture the process defaults, activate the blueprint, then launch sandboxes from the same named artifact every time. Blueprint records keep the source image and artifact reference visible so teams can reason about what is running.
OCI source
ghcr.io/acme/dev:sha256...
Blueprint
node-dev / active
Registry
built-in or connected private registry
Sandbox
repeatable rootfs + process defaults
Registry options
Use the built-in registry for GlobalStacks-managed blueprint artifacts, or connect Docker Hub, GHCR, ECR, self-hosted registries, and other private OCI registries with stored credentials.
Brokered authentication
A whole new meaning to arm's length.
GlobalStacks keeps durable credentials in the trusted control plane and uses connected agents to broker the narrow operation a sandbox needs. The sandbox gets network reachability, injected headers, or a typed stream, not a pile of reusable cloud tokens.
Control-plane tokens stay outside
OAuth sessions and source-control credentials remain in the control plane or brokered secret store instead of being copied into sandbox files, logs, command arguments, or environment variables.
Access brokers outbound headers
Access policies can inject approved HTTP headers from write-only secrets through the agent-managed egress path, so application code does not need to hold the long-lived credential.
Secure network access is mediated
HTTPS egress can be opaque or explicitly intercepted for header injection, while source SSH uses a typed sandbox-agent to host-agent to control-plane stream without forwarding private keys.
Short-lived operational tokens
Sandbox ssh gateway, terminal, port-forward, registry, and agent stream paths use scoped short-lived credentials or hashed session tokens for the specific operation.
Data plane
A data plane that works with you.
GlobalStacks separates where work runs from where durable state lives. Cluster storage, S3-compatible object stores, Cloudflare R2, and RustFS extensions give sandboxes portable files without turning provider credentials into sandbox secrets.
Cluster-aware storage
Attach durable storage to the cluster that owns the workload, then let agents mount the right volume backend when a sandbox starts.
S3 and R2 backed volumes
Cluster storage can use S3-compatible backends such as Cloudflare R2, with per-volume prefixes for chunks, metadata, and backups.
RustFS runtime extension
Run RustFS as a first-party data-plane object store on selected hosts through declared extension operations and typed broker calls.
Sync without credential sprawl
Agents receive scoped storage credentials for the operation they perform, while sandboxes consume mounted filesystems instead of provider keys.
Extensibility
Extend the console without trusting every extension.
GlobalStacks extensions are manifest-driven. The trusted console owns placement, rendering, consent, and operation authorization, while extension code runs in sandboxed UI and runtime boundaries.
Supported source control
Source control connections
Connect GitHub or Gitea repositories for Git-backed blueprint builds, extension runtime builds, and sandbox bootstrap flows.
Extension UI library
Author views with the GlobalStacks SDK and component contracts for forms, tables, data grids, status, progress, actions, and root views.
Sandboxed runtime protocol
Extensions declare a manifest, run in an isolated runtime, receive JSON operation input, and return JSON results through the broker.
Write your own extensions
Ship private or published extensions with declared permissions, egress, viewports, operations, commands, and runtime artifacts.
What can be extended
One control plane.
Any infrastructure.
GlobalStacks abstracts away the vendor-specific complexity. Whether it's a Proxmox node in your basement or an EC2 instance in us-east-1, the sandbox execution experience is identical.
- Unified sandbox management
- Distributed sandbox volumes
- Cross-agent Tailscale-compatible mesh
- Self-hosted clusters
- Linux ARM64 and Apple silicon agents
- Free self-hosted runtime
- Centralized logging & metrics
- Infrastructure-agnostic APIs
target:
type: proxmox-lxc
node: 'pve-01'
sandbox:
name: 'agent-runner'
image: 'node:20-alpine'
resources:
cpu: 2
memory: 2048