Security

How your code is isolated, where your files go, and how access and spend are controlled. Everything here describes how the system works today.

Isolation

One session per machine: A host runs one session at a time. While your session runs, no other customer's code is on that machine.
Sandboxed execution: Your code runs inside a gVisor sandbox, which intercepts system calls before they reach the host kernel. GPUs are passed through to the sandbox. A production host will not start without the sandbox.
Network: Sessions can reach the public internet. They cannot reach the host they run on, the cloud metadata service, link-local addresses or private networks.

Where they live: When a session stops, its /workspace is uploaded to object storage and removed from the machine. When it resumes, the workspace is restored onto whichever machine it lands on. Process logs are stored the same way.
Jobs keep less: A job (super job run) keeps only its exit code, its logs and what it writes to a volume you name. Its working files are not saved.
Preemption: Sessions run on machines that can be lost. If a machine is lost, the session comes back on another one with its workspace restored.

Keys per machine: super login signs in through your browser and gives that machine its own API key, named after it. Agents use the key and never see your password.
Payments: Cards are entered on Stripe's hosted checkout. Card details never pass through the CLI or our servers.
Bounded spend: Credit is prepaid. At zero, new work is refused and running sessions are closed, with their files kept. Auto-refill is opt-in and capped per day.

Every session runs inside the sandbox described above. Vulnerability reports go to support@supercomputer.sh.