Application platforms / Specific Application Platform alternative

A Specific.dev alternative for the agent’s own execution state

Specific lets coding agents define application infrastructure and deploy services, Postgres, object storage and workflows. Its persistent service volumes survive deployments and restart, and previews get copy-on-write volume clones. Those are real application-data capabilities, distinct from retaining an agent’s entire mutable operating system.

Start buildingCompare capabilities ↓

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

When Specific Application Platform fits

Specific fits teams building and deploying applications with agent-authored infrastructure, local development, databases, S3-compatible storage and managed workflows. Keep those product services where required.

When to consider Sandbox0

Choose Sandbox0 for compatible Linux agents that need their own complete durable writable RootFS, automatic online expansion and supported paused-file operations. Retain or recreate required application databases, storage and workflow services separately.

Capabilities

Specific Application Platform and Sandbox0: what persists?

Feature comparison with documentation and verification status
Environment and runtime lifetimeSpecific Application PlatformNot 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 filesSpecific Application PlatformService volume directories survive deploys and restarts, with copy-on-write volume clones for previews.View evidence ↗Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFSSpecific Application PlatformSelected persistent service volumes do not establish retention of arbitrary runtime changes across the complete service OS root.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 stateSpecific Application PlatformPostgres scale-to-zero and application scaling do not establish durable general-machine pause/resume.View evidence ↗Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process stateSpecific Application PlatformCopy-on-write preview volumes retain disk data, not documented guest RAM or process state.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.

Specific supports explicit persistent-volume resizing from the service Scale tab. That is different from automatic free-space-triggered online growth of the complete durable agent RootFS; database bottomless storage is a separate managed service.

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.

Specific provides independent S3-compatible object access, and retained volumes can outlive services. These application-data interfaces do not establish direct operations against every stopped service root path. Sandbox0 supports its paused durable RootFS with mutations only for filesystem-only generations and reads for retained-memory generations.

See paused file operations →

Persistent directories already support preview data clones

A production volume mounts at /volumes/{name} and survives deploys and restarts. Preview environments receive instant copy-on-write clones, with isolated writes. This retains selected directories; it does not establish that every runtime tool or configuration change elsewhere in the service container becomes a durable agent OS.

Source 1 ↗

Removing application configuration can leave billable data resources

When a deployment removes a resource block, databases, storage buckets, workflow namespaces, volumes, secrets and configs can remain orphaned with their data intact. They stay provisioned and billed until explicitly deleted. Removing a service with volumes also keeps those volumes, so deployment cleanup is not automatically storage cleanup.

Source 1 ↗

Volume storage and object storage use separate meters

Service volumes cost $0.15 per GB-month, while S3-compatible object storage has its own capacity and request prices and free egress. The changelog also documents explicit persistent-volume resizing. Database scale-to-zero and bottomless storage are database features, not full guest-machine pause or automatic agent RootFS growth.

Source 1 ↗Source 2 ↗Source 3 ↗

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.

Specific Application Platform

Pricing reviewed 2026-10-19

Small application service
$0.025 per service-hour
1 vCPU and 2 GB memory; separate from plan and storage meters.
Rate source ↗
Pro plan
$25/month with $25 usage credits
Rate source ↗
Scale plan
$299/month with $299 usage credits
Rate source ↗
Service volume storage
$0.15 per GB-month
Rate source ↗
S3-compatible object capacity
$0.03 per GB-month
Request charges are separate; object-storage egress is free.
Rate source ↗

Free local development and the limited hosted Free plan are separate from paid service usage. Pro and Scale include the stated credits rather than an additional identical credit fee. Database compute/storage, workflow actions/history, volumes, object requests and service egress have separate meters. Plan log/metric/workflow-history retention is not an application-file expiry period.

Check current Specific Application Platform 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 Specific Application Platform

  1. Map app services, volume mount paths, preview clones, Postgres, object buckets, workflows and orphaned resources.
  2. Keep required app infrastructure and export compatible Linux agent tools and files, including any state outside persistent mounts.
  3. Verify application behavior separately from agent system retention, growth, paused files and all distinct resource meters.

Common questions

Is Sandbox0 a drop-in Specific Application Platform 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.

Battleships research record ↗docs.specific.dev/guides/volumes ↗docs.specific.dev/concepts/deployments ↗specific.dev/pricing ↗docs.specific.dev/guides/storage ↗specific.dev/changelog ↗Sandbox0 RootFS capacity →

Related comparisons

Aptible vs Sandbox0 →Azure Container Apps vs Sandbox0 →Clever Cloud vs Sandbox0 →Dockup vs Sandbox0 →Fly.io Machines vs Sandbox0 →Google Cloud Run vs Sandbox0 →