Sandbox Defaults

Sandbox defaults are the policy that governs how new Onumia sandboxes are created and how far they can grow. They set the baseline lifetime of a sandbox, how many a single user may keep open, how much data Onumia will copy when it clones your database, and how long finished sandboxes are retained. Administrators manage these values in Settings, under Sandbox defaults.

The settings

There are four defaults. Each ships with a sensible product value that you can change to fit your site and hosting.

Setting	Default	What it controls
Default sandbox TTL	3600 seconds	The lifetime applied when a sandbox is created without an explicit TTL.
Max active sandboxes per user	50	The most active sandboxes one user may own at the same time.
Max local clone DB size	250 MB	The largest estimated database payload Onumia will copy when cloning for a new sandbox.
Inactive sandbox retention	30 days	How long promoted or discarded sandboxes are retained for cleanup.

Default sandbox TTL

The default TTL determines how long a new sandbox lives when the request that creates it does not specify one. An agent may ask for a particular TTL while calling create_sandbox; the default is what applies when none is given.

Max active sandboxes per user

Before creating a sandbox, Onumia counts how many active sandboxes the requesting user already owns. If that count has reached the configured maximum, creation is refused. This is a guard against unbounded sandbox generation, whether from a misbehaving agent or an enthusiastic one, while still leaving plenty of headroom for genuine parallel work when you raise the limit.

Max local clone DB size

Provisioning a sandbox involves cloning your WordPress tables under a new prefix, and large databases make that expensive. Onumia estimates the payload it would copy and, if the estimate exceeds this limit, fails creation before any clone side effects occur, so you never end up with a partially cloned sandbox.

The limit is measured against actual copied row data, so it stays focused on the data that genuinely drives clone cost.

Inactive sandbox retention

Once a sandbox has been promoted or discarded it is no longer active, but its record can be kept for a window afterward. This setting expresses how long that window is. It is a retention policy value that cleanup workflows and future retention automation read; it tells Onumia how long finished sandboxes should stick around before they are eligible for removal.

Saved, default, and effective values

Onumia distinguishes three views of every setting, and it is worth knowing which one runtime behavior actually uses.

• Defaults are the built-in product values shown in the table above.
• Settings are the values an administrator has saved.
• Effective values are the saved settings after WordPress filters have been applied.

Runtime behavior always uses the effective value. That means a filter can override what an administrator saved, which is the mechanism described next.

Overriding with filters

Each default can be adjusted in code with a WordPress filter. This is useful for environment-specific policy, for example a higher clone ceiling on a powerful host or a shorter TTL on a shared one, without touching the saved settings.

add_filter( 'onumia/sandbox/default_ttl_seconds', fn ( int $seconds ): int => 7200 );
add_filter( 'onumia/sandbox/max_active_per_user', fn ( int $count ): int => 25 );
add_filter( 'onumia/database/local_clone_max_bytes', fn ( int $bytes ): int => 500 * 1024 * 1024 );
add_filter( 'onumia/sandbox/inactive_retention_days', fn ( int $days ): int => 14 );

Filters must return positive integers; invalid values are ignored, so a malformed override cannot disable a limit.