Sandbox Billing

Sandbox plans are subscribed to a team. Usage appears in the same current-month billing view as apps and add-ons.

Team plans

Plan	Base price	Included root disk	Runtime and quota limits
Basic	Free	10 GiB	24 hour max runtime, 20 concurrent sandboxes, template CPU/RAM shape.
Pro	€150/month	20 GiB	24 hour max runtime, 100 concurrent sandboxes, CPU/RAM overrides, 5 creates/sec.
Enterprise	Custom	Custom	Per-team overrides for disk, runtime, concurrency, CPU, memory, and create rate.

Plan fees and usage are separate. Upgrading a team to Pro raises the team’s sandbox limits; it does not replace per-second runtime billing or retained-storage billing. Cancelling a self-service Pro subscription cancels the Stripe subscription immediately and refunds unused plan time. Runtime and storage usage already consumed remain billed through the normal usage ledger.

What is billed

Line item	What it measures
vCPU runtime	Requested vCPU count multiplied by running seconds.
Memory runtime	Requested GiB RAM multiplied by running seconds.
Stopped disk	Confirmed retained root disk storage after a sandbox stops, fails, or is marked lost, until its retention deadline.
Checkpoint storage	Named checkpoint storage by size and time.
Template storage	Ready template version storage by size and time.

List sandbox limits to see the active resource shape, prices, and quota snapshot:

curl https://api.watasu.io/v1/sandbox_limits \
  -H "Authorization: Bearer $WATASU_API_KEY"

The response includes a quota object for the selected team:

{
  "sandbox_limits": {
    "plan": {
      "slug": "basic",
      "disk_mb": 10240,
      "max_timeout_seconds": 86400
    }
  },
  "quota": {
    "limits": {
      "max_running_instances": 20,
      "max_vcpu_count": 8,
      "max_memory_mb": 8192,
      "max_disk_mb": 10240,
      "create_rate_per_second": 1
    },
    "usage": {
      "running_instances": 2,
      "vcpu_count": 4,
      "memory_mb": 4096,
      "disk_mb": 20480
    },
    "reservation": {
      "instances": 0,
      "vcpu_count": 0,
      "memory_mb": 0,
      "disk_mb": 0
    }
  }
}

Runtime billing

Runtime billing covers confirmed running time (ready). Creating, connecting, restoring, stopping, and destroying do not accrue compute charges.

Runtime billing is based on the resources you request:

Resource	Price
vCPU	€0.000020 per vCPU-second
Memory	€0.000004 per GiB-second

For example, a sandbox using 2 vCPU and 1024 MiB RAM costs:

(2 × €0.000020 + 1 × €0.000004) × running_seconds

That is €0.1584 per hour while it is running.

Resource shape

Template versions define a runtime_baseline. That baseline is the default runtime shape when you start a sandbox. Basic teams use that shape. Pro and Enterprise teams can override CPU and memory within the team’s active plan limits:

{
  "sandbox_template_version": {
    "runtime_baseline": {
      "cpu": 2,
      "memory_mb": 4096
    }
  }
}

When creating a sandbox, choose the template shape with template:

{
  "template": "base",
  "timeout": 3600
}

Root disk size is platform-managed by the team plan: Basic uses a 10 GiB root disk and Pro uses a 20 GiB root disk. It is retained for stopped sandboxes and checkpoints, but it is not a public create-time resource knob.

Self-service sandbox resources use these increments:

• CPU: 1, 2, 4, 6, or 8 vCPU
• memory: 512 MiB to 8192 MiB in 512 MiB increments

Quota checks use the resources you request. If a create or restore request exceeds quota, Watasu returns 422 Unprocessable Entity with error: "sandbox_quota_exceeded" and a quota object that includes the limit, current usage, and requested reservation.

Storage billing

Storage is billed by size and time, prorated the same way as runtime:

Storage	Price
Retained disk (stopped sandbox)	€0.10 per GiB-month
Checkpoint storage	€0.03 per GiB-month
Template storage	€0.03 per GiB-month

For example, a stopped sandbox holding a 10 GiB root disk has a €1.00 monthly storage rate, prorated until it resumes, is destroyed, or reaches its retention deadline. A 4 GiB checkpoint has a €0.12 monthly rate until it expires.

A paused sandbox also retains a machine-state image alongside its root disk. The retained-disk meter uses the root disk size; the machine-state image is not separately metered. Destruction removes both.

Retained disk billing

When a sandbox is stopped, Watasu keeps the root disk so the sandbox can be inspected, reconnected, restored, or cleaned up deliberately. That retained disk is billed as storage by size and time.

Inactive sandbox disks expire after seven days. This includes paused, stopped, failed, and lost sandboxes. The API exposes retained_storage_expires_at; resume before that deadline to keep using the sandbox. Resuming ends that retention window, and a later stop starts a new one. The normal runtime timeout can destroy a sandbox sooner when on_timeout is kill.

Existing retained disks receive a fresh seven-day grace period when the policy is first applied. Expired or destroyed sandboxes do not accrue retained-disk charges, and delayed physical cleanup does not extend the billing deadline. Once destruction is requested, a cleanup failure does not restart storage charges. Named persistent volumes and reusable template versions are separate resources and are not subject to this inactive-sandbox expiry.

Checkpoint billing

Ready checkpoints are billed by stored size and time until they expire or are removed by lifecycle cleanup.

Checkpoint expiry defaults to 24 hours after creation when expires_at is omitted. Cleanup runs automatically and retries failures on the owning node.

Use explicit checkpoint expiry times that match the job:

{
  "sandbox_checkpoint": {
    "name": "after-index",
    "expires_at": "2026-06-02T12:00:00Z"
  }
}

Template billing

Ready template versions are billed as template storage. This lets you keep reusable environments available for fast sandbox starts.

Suspended billing

When a team’s billing account is suspended, Watasu blocks new sandbox runtime spend and returns 402 Payment Required with error: "team_billing_suspended". The response includes the team and account balance fields needed to guide the user back to billing.

Blocked actions include sandbox create, restore, resume/connect, streaming process starts/signals, file writes/moves/deletes, directory create/delete, checkpoint create, and customer template builds. Pause/stop and destroy remain available so you can release resources and clean up retained disks.

Rate limits

Sandbox create and runtime mutation endpoints are rate-limited per authenticated user and remote address. When a request is limited, Watasu returns 429 Too Many Requests, error: "rate_limited", and a Retry-After header.

Avoiding surprise spend

• Set timeout on every sandbox.
• Destroy sandboxes when a job is complete.
• Use checkpoint expiry times instead of keeping temporary checkpoints indefinitely.
• Reuse template versions instead of building duplicate templates for the same environment.
• Review the team’s current-month billing view after adding new automation.