Storage and lifecycle
SnapVM machines are useful because their filesystem remains durable while compute can stop or hibernate.
What persists
Section titled “What persists”The persistent filesystem keeps:
- Source code and Git repositories
- Installed packages and language runtimes
- Generated files
- Local configuration
- Databases stored on disk
- Service definitions
This means a machine can feel like a long-lived development computer even when its compute runtime sleeps between sessions.
What does not persist
Section titled “What does not persist”The following should be treated as ephemeral:
- Running processes that are not services
- In-memory caches
- Unsaved editor buffers
- Temporary sockets
- Runtime-local network connections
If a process matters after wake-up, define it as a service. If data matters, write it to disk or a remote backing service.
Wake-up triggers
Section titled “Wake-up triggers”A stopped or hibernating machine can wake when:
- A user opens the terminal in the console
- A browser requests the machine HTTPS URL
- The API receives a start request
- A deployment-specific scheduler or worker starts the machine
Wake time depends on runtime type, region, image size, and service startup cost.
Safe operating model
Section titled “Safe operating model”Use this pattern for low-friction development:
- Keep project files under a predictable workspace directory.
- Commit source code to Git before deleting machines.
- Use services for long-running processes.
- Stop or hibernate when the machine is idle.
- Treat deletion as final.
Troubleshooting lifecycle issues
Section titled “Troubleshooting lifecycle issues”| Symptom | Check |
|---|---|
| Files are present but server is down | The server was probably an interactive process; define a service |
| Machine URL wakes but returns an error | Confirm the service port and logs |
| Terminal cannot connect | Check machine state, agent health, and gateway logs |
| Wake-up feels slow | Inspect service startup cost and image/runtime size |