Show HN: Tilde.run – Agent sandbox with a transactional, versioned filesystem

A new SaaS tool, Tilde.run, offers an AI agent sandbox built on a transactional, versioned filesystem (via lakeFS) that mounts directly into containers, letting agents read and write “local” files while enabling atomic snapshots, rollbacks, and human-in-the-loop approval of changes. Commenters see strong value for long‑running or data‑heavy agents and multi-agent workflows, but question how much it really improves on existing options like Git, S3 versioning, Linux snapshots, or plain VMs—especially for actions that mutate external state such as APIs, databases, or financial trades. The conversation also highlights fatigue with yet another hosted sandbox, concerns about pricing, security, and closed-source control, alongside interest in its scaling properties and fine-grained network egress controls.

Core Idea and Filesystem Design

  • Service provides an agent sandbox whose filesystem is transactional and versioned, built on top of lakeFS.
  • The repo is FUSE-mounted into the sandbox, not copied, so agents read/write “local” files that actually live in an object store (e.g., S3).
  • Each sandbox run branches from a main repo, does work, and produces an atomic commit; rollbacks are done by reverting these snapshots.
  • Versioning performance is proportional to number of objects changed, not size, since objects are immutable and operations are mostly metadata.

Why Not Just Git / S3 / Snapshots?

  • Git is seen as fine for code but not for large binary or high-volume data (parquet, images, millions of small files).
  • S3 versioning is per-object and awkward for understanding or reverting large directory-level changes.
  • Traditional FS snapshots (e.g., btrfs) can solve persistence, but don’t provide built-in workflows like human-in-the-loop approvals or PR-style change review for agents.

Use Cases and Benefits

  • Targeted at agents that need persistent state across runs (like a “computer with the same files” over time).
  • Promises easier review, rollback, and audit of agent changes to files, including large datasets.
  • Can host things like SQLite databases atop the FS to gain transactional rollback at the file level.

Security, Sandboxing, and External Effects

  • Outbound network is controlled via a forward proxy with explicit allowlists (host/path/method).
  • Many commenters note that versioning only protects the managed filesystem; external side effects (trades, DB schema drops, remote APIs, GitHub, S3, etc.) can’t be fully undone.
  • Some argue sandboxing is overkill for most users if they already use Git, backups, and careful manual approvals; others liken sandboxing to seatbelts for when agents eventually “go off the rails.”

Product, UX, and Ecosystem Feedback

  • Positive reactions to the versioned FS concept; several people building similar tools say this was a missing piece.
  • Criticism of the landing page and demo as too vague, focusing on setup instead of compelling use cases.
  • Questions about pricing (currently “free to start” with no concrete numbers), hosting details, OS support, and configurable resources (CPU, RAM, GPU).
  • Some strongly prefer local, open-source sandboxes and are wary of SaaS lock-in; others see value in a hosted, managed solution even if similar primitives exist (OCI, k8s, FS snapshots, S3 Files, etc.).
  • General sense that “agent sandboxes” are a crowded space, with comparisons to various open-source and commercial alternatives.