DEV Community

Cover image for A sandbox lifetime is a workflow decision: using Never in Lizard
Lizard
Lizard

Posted on

A sandbox lifetime is a workflow decision: using Never in Lizard

A build is still running. An agent is waiting for a review. Your laptop needs to close. These are different events, but a fixed sandbox expiry can turn all three into the same problem: the working environment disappears before the task is finished.

We're the team behind Lizard (lizard.build). Our latest update highlights the Never option for automatic deletion in Lizard Sandboxes. It lets you keep the lifetime of a cloud workspace under your control instead of tying it to a fixed expiration timer.

What Never changes

In the dashboard, choose Never under Delete Sandbox after when creating a sandbox. This disables scheduled expiry. It does not stop running compute charges, and it is not a guarantee against service interruptions or application failures.

With the Lizard CLI, the corresponding creation flag is --timeout 0. For example:

lizard sandbox create --size small --timeout 0
Enter fullscreen mode Exit fullscreen mode

This is a creation-time choice. It is useful to make the lifetime explicit in your setup instructions: the current CLI default is a five-minute lifetime, not an indefinitely running workspace.

If you use a coding agent with the CLI, you can ask it to create a Small sandbox that never expires. Check the resulting lifetime setting rather than assuming the agent selected it.

Expiration, execution and saved state are separate

Consider an illustrative development task: an agent installs dependencies, starts a long build, then waits for a person to review the result. A lifetime policy should account for that wait, not just the expected build time.

Three decisions matter:

  • Lifetime: when should this workspace be automatically deleted?
  • Execution: does the process need to keep running while you are away?
  • Saved state: what needs to survive a pause, interruption or eventual deletion?

Never answers the first question. Closing a laptop does not itself pause a cloud process. If the process keeps running, running compute remains billable.

The update also describes pausing a supported sandbox and resuming it later with memory and files retained. Check compatibility before building a workflow around this: the current CLI guide says the snapshot-based pause/resume workflow does not support attached Persistent Volumes. Keeping a workspace available and exporting important outputs are still separate responsibilities.

Make the running cost visible

At the Small compute rate of $0.009 per hour, continuous execution for a 30-day month works out to:

30 days × 24 hours × $0.009 = $6.48
Enter fullscreen mode Exit fullscreen mode

That is the approximately $6.50 figure in the announcement. It is a compute-only calculation, not an all-inclusive account bill. Plan charges, storage and other resources must be considered separately. Running compute is metered per second.

A practical policy is to use Never for work that spans unpredictable waits, then explicitly review and delete workspaces when the task is finished. A workspace without an expiry timer still needs an owner and a cleanup decision.

Try it on a task with a real wait

Choose a development task that includes both computation and human review. Create the workspace with the lifetime you intend, save a useful artifact, and check whether pausing is supported by that configuration before relying on it.

Read the original announcement or explore Lizard Sandboxes.

Top comments (0)