Long-lived / persistent sessions (continue from desktop)

[nthh]

Summary

Let users run sessions that last longer than 1 hour and seamlessly continue work started locally (e.g., Claude Desktop) in a remolt sandbox, or vice versa.

User stories

• "I started a Claude session on my laptop and want to continue it on remolt when I leave my desk"
• "My connection is slow — I want to run everything on the cloud where it's faster and check back later"
• "I kicked off a long task and want to come back to it tomorrow"
• "I want a persistent dev environment I can always reconnect to"

Features

Configurable session duration

• Let users choose session lifetime at creation: 1h (default), 4h, 12h, 24h
• Or: remove idle timeout for "persistent" sessions, replace with a total max (e.g., 24h)
• Keep-alive heartbeat to distinguish "idle but watching" from "actually gone"
• Ties into Keep-alive / extend session button #7 (keep-alive button) and Session time remaining indicator #6 (idle timer)

Session handoff (local ↔ remolt)

• Import: User provides a git branch or repo state from their local machine, remolt creates a sandbox at that exact state
• Export: One-click "push to branch" before session ends, user pulls locally
• Could leverage claude --continue or session resume if Claude Code supports it

Background sessions

• Sessions that run without a browser tab open
• User kicks off a Claude task, closes the tab, comes back later
• Notification (email/webhook) when task completes or needs input
• Dashboard (Session history dashboard #12) shows running background sessions with status

Persistent workspace (ties into #9)

• User's /home/dev persists across sessions via PVC or snapshots
• "Resume workspace" instead of starting fresh each time
• Installed packages, config files, git state all preserved

Considerations

• Cost: longer sessions = more pod-hours = more compute/bandwidth cost
• Billing model: may need usage-based pricing for persistent sessions
• Resource limits: persistent pods should have lower CPU/memory to reduce cost
• Cleanup: abandoned persistent sessions need a max lifetime or manual cleanup
• activeDeadlineSeconds currently caps pods at 4 hours — would need to increase or remove

[nthh]

Wakeup-on-request mode

A middle ground between ephemeral (destroy on idle) and always-on (expensive). Inspired by Shellbox's "wakeup mode" — sandboxes auto-suspend on idle and auto-resume on incoming request.

How it would work

1. On idle timeout, suspend instead of destroy:

   • Snapshot filesystem to object storage (see Persistent storage across sessions #9 option 4)
   • Scale pod to 0 / destroy pod
   • Keep session metadata + snapshot reference

2. On incoming WebSocket connection or HTTP proxy request:

   • Detect request for a suspended session
   • Claim a warm pool pod
   • Restore snapshot into it
   • Forward the connection

3. Session stays "suspended" until either:

   • User reconnects (auto-resume)
   • Max suspension duration exceeded (e.g., 7 days → destroy + delete snapshot)

Implementation options (K8s)

• Custom controller: Server handles suspend/resume logic directly (simplest, fits single-file architecture)
• KEDA: Kubernetes Event-Driven Autoscaling — scale pods 0↔1 on HTTP trigger (more K8s-native but adds a dependency)

UX

• Browser shows "Session suspended — reconnecting..." instead of "Session ended"
• Resume takes a few seconds (warm pod claim + snapshot extract)
• User's terminal history, workspace, and config all restored

Prerequisites

• Persistent storage across sessions #9 (persistent storage / snapshot mechanism)
• Warm pool infrastructure (already exists)

Cost benefit

• Suspended sessions cost only object storage ($0.02/GB/mo) vs. running pods ($0.05-0.10/hr)
• Enables "persistent workspace" feel without always-on compute

---

Context: Shellbox offers wakeup mode (auto-start on HTTP, stop after 5 min idle). Fly.io Sprites suspend with near-zero idle cost. This brings similar economics to Remolt's K8s backend.