Skip to main content

​
Infrastructure tiers

Every organization and personal account has an infrastructure tier. The tier limits how many containers and sandboxes can run at once and how much storage their volumes can use: Every account is on at least Tier 1. The tier rises automatically with your lifetime paid total, which counts paid API usage invoices, paid credit purchases, and paid infrastructure invoices. Organizations with GPU access for containers are on Tier 3. Tinfoil can also raise an account’s limits. To see your tier, limits, current usage, and the paid total each tier requires, open Limits in the dashboard under Organization (or Account for a personal account), then select Containers or Sandboxes. Personal accounts have no Containers tab because only organizations run containers.
Need more than Tier 3 allows? Contact us to discuss your requirements.

​
What counts toward the limits

  • Containers and sandboxes are counted separately. A container or sandbox counts unless it is Stopped or Failed, so deploying a Stopped or Failed container, or starting a stopped or failed sandbox, counts against the limit again. The Monitor that your sandboxes connect through counts toward neither limit.
  • Storage is one pool shared by container volumes and sandbox workspaces. Every volume counts at its full size until it is deleted, including detached volumes and the workspaces of deleted sandboxes.
Storage sizes use decimal units: 1 GB is 1,000,000,000 bytes and 1 TB is 1,000 GB.

​
Sandbox workspaces

Each sandbox stores its files on a workspace volume. Choose its size when you create the sandbox: 2, 4, 8, 16, 32, or 64 GB, with 16 GB as the default. Use the Workspace size selector in the dashboard, the --workspace-size flag of tinfoil sandbox create, or the workspace_size_gb field of an API create request. A workspace can’t be resized after creation, and reusing an existing workspace (--workspace) keeps its size. To create a workspace volume ahead of time, run tinfoil volume create NAME --sandbox --size 16GB. Sandboxes must be enabled for your organization or personal account. Contact us to request access.

​
When you reach a limit

A request that would go over a limit fails with an error message that explains how to free capacity or get a higher limit. The dashboard links to the matching Limits tab, and the CLI points to your account limits. To free capacity, stop or delete containers and sandboxes you no longer need, and delete unused volumes.

​
Resource options

Each container specifies its CPU, memory, and GPU requirements in tinfoil-config.yml. These values are measured and published with the release; create, deploy, and update requests cannot override them. Available options:

CPU

Memory

Public resource shapes are CPU-only, gpus: 1, or gpus: 8. GPU access must be enabled for your organization.
Start with the smallest size that works for your workload and scale up if you see high CPU utilization or slow response times. Over-provisioning wastes resources and you can always resize by updating to a release with a changed tinfoil-config.yml.

​
Choosing the right size

Pick resources based on what your application actually needs, not what you think it might need. A few rules of thumb:
  • Compiled languages (Go, Rust, C++) are memory-efficient; 8 GB is often enough.
  • Interpreted runtimes (Python, Node.js, Ruby) typically need 16 GB+ for production workloads.
  • CPU cores should match your concurrency model. A single-threaded app won’t benefit from 32 cores. A multi-process web server (e.g. Gunicorn with workers) should have roughly one core per worker.
  • Measure first. Run your app locally with resource limits to understand its actual footprint before deploying.