# Cloud workspace lifecycle

Foxora creates one cloud machine for the signed-in user and stores projects as folders inside it. The machine starts or resumes only when the web task needs cloud execution, then uses suspension and backup policies to control cost without treating the machine as the only durable copy.

![Cloud workspace lifecycle in Foxora v5.0.3](/docs/images/v5.0.3/web-cloud/projects.webp)

## Current v5.0.3 lifecycle

1. **Warm or provision.** Foxora begins warming the user’s cloud machine after the web task connects. First use creates it when no machine exists.
2. **Run.** File tools, the editor, terminal, and task commands resolve under the Foxora Cloud workspace root.
3. **Back up changes.** File operations, completed turns, clones, and terminal activity schedule a coalesced project snapshot instead of uploading after every keystroke.
4. **Suspend when idle.** The cloud machine can auto-stop after approximately 15 minutes of inactivity. Suspension preserves the machine and is expected behavior.
5. **Resume on demand.** A later operation refreshes stale provider state and starts a stopped machine before accessing files or the terminal.
6. **Recreate when required.** When durable backup is enabled, a machine may be removed after a longer idle period and recreated later. Foxora restores the project snapshot into the replacement.

Task and memory records for the web surface live in managed storage. Project files and Git history are backed up separately from the cloud machine’s local disk.

## What a project backup contains

The project snapshot includes source files and Git metadata. Large or derived directories such as `node_modules`, build output, caches, Rust `target`, and Python bytecode are excluded because they can be rebuilt from source and manifests.

After a restore, reinstall dependencies and rerun the project’s build or tests before relying on previously generated output.

## What users should do

- Keep source and dependency manifests inside the project folder.
- Commit important milestones to Git.
- Download irreplaceable deliverables before deleting a task or project.
- Do not store secrets in ordinary project files unless the task truly requires them.
- Expect a cold resume to take longer than a warm command; do not create duplicate tasks merely because the first cloud operation is starting.

The correct continuity test is not whether the machine kept the same internal identifier. Reopen the task, open the project, read a known source file, and run the smallest project-specific verification.