Cloud infrastructure / Sakura Internet Cloud alternative

Sakura Internet Cloud alternative for Linux agents

Sakura Internet’s Japanese cloud separates server compute from OS/data disks and provides full virtual machines. It already supports keeping disks while server compute is stopped. Compare Japanese-zone tariffs, disk-copy/partition operations and the runtime API needed for a returning agent.

Reviewed 2026-10-19 · Published by the Sandbox0 team

When Sakura Internet Cloud fits

Choose Sakura Cloud for Japan-region infrastructure, VM control and its wider cloud networking and services. Normal, dedicated-core, confidential and dedicated-host options have distinct scope and billing.

When to consider Sandbox0

Consider Sandbox0 for compatible Linux agents whose whole durable RootFS grows online and supports file operations with guest compute paused. Validate region, latency and gVisor compatibility while retaining required Sakura integrations.

Capabilities

Sakura Internet Cloud and Sandbox0: what persists?

Feature comparison with documentation and verification status
Environment and runtime lifetimeSakura Internet CloudNot established in this reviewSandbox0ttl and hard_ttl default to 0 (disabled). Configure idle pause and deletion policies for the same persistent sandbox identity; an idle running sandbox still accrues compute charges.Read documentation →
Persistent filesSakura Internet CloudOS/data disks have separate creation, attachment and copy lifecycles.View evidence ↗Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFSSakura Internet CloudA boot disk from an OS archive can retain the complete installed filesystem.View evidence ↗Sandbox0Persistence extends beyond /workspace to paths such as /usr/local, /etc, and /home. Runtime tmpfs and virtual filesystems are excluded.Read documentation →
Release compute, keep stateSakura Internet CloudOrdinary server stop/start can retain separate disks without running-compute charges; RAM continuity is unestablished.View evidence ↗Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process stateSakura Internet CloudDisk/archive copies do not establish arbitrary running-memory checkpoint recovery.View evidence ↗Sandbox0Experimental memory checkpoints can preserve compatible process state. Use memory: true on both pause and resume on a compatible deployment. A filesystem checkpoint alone does not preserve running processes.Read documentation →

Online RootFS growth

On growth-enabled images, Sandbox0 automatically expands the writable RootFS as free space runs low, within a configured sparse logical ceiling up to 64 TiB. Agent processes keep running. Growth is enabled in the qualified Cloud region; confirm activation for other regions. Existing images and snapshots retain their captured storage geometry. The ceiling is logical capacity, not preallocated host disk.

Sakura already retains complete OS disks independently of ordinary server compute. Larger-disk copy and partition expansion have explicit stopped/detached workflows, unlike integrated low-free-space online growth of Sandbox0’s whole durable RootFS.

Files while compute is paused

Sandbox0's Files API reads persistent files without resuming compute. Filesystem-only pauses also permit edits; retained-memory pauses are read-only and reject mutations with 409. SSH, SFTP, file watching, and runtime-only mounts require running compute.

A disk can remain without an active original server, but mounting, restore and guest file tools use other compute. That differs from supported direct file operations throughout a paused RootFS without booting a guest.

See paused file operations →

Server compute and stored disks have different clocks

Sakura introduced nonbilling periods for stopped ordinary servers; retained disks remain separate resources. Billing generally distinguishes started-to-stopped usage from created-to-deleted resources. Hours round up, with daily and monthly charging thresholds; dedicated-host and other product terms must be checked separately.

Changing CPU/RAM plan stops the server

Plan changes require the server to be stopped. Internally the operation creates a new plan resource, transfers settings and deletes the old one, with a new resource ID and charging period. Repeated changes within a billing unit can therefore increase costs.

Disk expansion uses disk and partition workflows

Disks can be separately attached, detached or created from disks/archives. Copying into a larger disk and using the partition-expansion feature is a documented path. That partition operation requires the server stopped or the disk detached; it is not automatic online low-space RootFS growth.

Pricing

Compare billing models, then price your workload

CPU allocation, memory, billing minimums, disk, plan fees, and supported workload differ. These meters are not equal-performance machine quotes. Confirm region, resource units, and included allowances before estimating a total.

Sakura Internet Cloud

Pricing reviewed 2026-10-19

Normal 1-core / 1 GB server reference
¥7/hour; ¥77/day; ¥1,540/month
Normal-plan reference, tax included; select exact zone. Disk is separate.
Rate source ↗
20 GB SSD disk reference
¥2/hour; ¥22/day; ¥440/month
SSD reference, tax included; storage remains a separate resource.
Rate source ↗
Usage rounding and thresholds
Partial hours round up
Daily/monthly thresholds and resource lifecycle affect the total; not a second-metered VM quote.
Rate source ↗

References use JPY and include tax; they are not USD quotes. Check selected zone/family, CPU/RAM, boot/data disk, IP/network, licenses and discounts. Server and storage figures are separate components, not a complete interchangeable sandbox machine.

Check current Sakura Internet Cloud pricing ↗

Sandbox0

$0.015/GiB-hour compute (billed by the second at approximately $0.000004167/GiB-second), plus $0.02/GiB-month of retained incremental RootFS and memory checkpoint data. Shared base images and platform recovery retention are excluded; paused sandboxes accrue storage charges only.

Compute / GiB-hour
$0.015
Retained data / GiB-month
$0.02
Paused compute
$0.00

A 4 GiB agent, 100 running hours

$6.00 compute

4 GiB × 100 hours, billed by the second. Keeping 20 GiB of billable incremental data for a full billing month adds $0.40. CPU is derived from memory by the platform; choose a tier that fits your workload.

Understand storage billing →

Before migrating from Sakura Internet Cloud

  1. Inventory zone, normal versus dedicated product, separate server/disks, charging thresholds and retained licenses/network resources.
  2. Export consistent complete system/user data and configure compatible tools on Sandbox0 while retaining required Japan-region services.
  3. Test installed tools, online growth, paused files, latency and total compute, retained disks, IP and network costs.

Common questions

Is Sandbox0 a drop-in Sakura Internet Cloud replacement?

Evaluate API compatibility and product scope. These products serve different core workflows, so a change may require a different architecture.

Does keeping files also keep a running agent?

Filesystem state and volatile process state are separate. Sandbox0 requires explicit compatible memory checkpoints to preserve running processes; its default filesystem resume starts fresh processes.

Sources and review scope

The Boat team's Battleships directory is the discovery source. References below describe the product and plan discussed on this page. Check current availability, regional terms and billing units before migrating. Where the cited material does not establish a capability or price, the comparison identifies that uncertainty.

Related comparisons