Skip to content

~tilde.run docs

Versioned object storage with sandboxed compute. AI agents and pipelines read, transform, and write data inside isolated sessions, then commit atomically with a full audit trail and human-in-the-loop approval.

Quickstart → Python SDK → API Reference →

Three layers, isolated by default

Tilde isolates the three resources every data workflow touches: storage, compute, and network. Each gets its own boundary, its own audit trail, and its own access controls — so you can run autonomous code (agents, pipelines, untrusted scripts) against real data without giving up safety, reproducibility, or oversight.

The combination is what matters. Versioned storage gives you reversibility, sandboxed compute gives you containment, and a mediated network gives you a complete picture of what a workload actually did. Every commit, every command, and every outbound request is recorded against the same identity model.

Storage — versioned and transactional

Every object in Tilde is versioned. Writes happen inside sessions: transactional workspaces where you stage changes, review diffs, and commit atomically. Nothing reaches production until you say so, and nothing is ever silently overwritten.

  • Atomic commits — stage any number of changes and apply them as a single unit, or roll the whole session back
  • Full history — every commit records who changed what, when, and why; revert any commit at any time
  • Mounted into sandboxes — your repository appears as a regular filesystem at /sandbox, no SDK calls required
  • External connectors — import data from S3, GCS, Git, or Google Drive into your repository
  • Optional approval — require human review before agent commits are applied

Filesystem isolation

Compute — isolated and scalable

Sandboxes run your code in fresh, isolated containers with Linux capabilities dropped and your repository mounted as a versioned volume. Spin one up for an interactive REPL, fan out hundreds for a batch job, or wire them to fire automatically on commit.

  • Hard isolation — each run gets its own container, its own session, and its own network namespace
  • Interactive or one-shot — repo.shell() for multi-command sessions, repo.execute() for single commands, with streaming output
  • Bring your own image — any container image works: Python, Node.js, R, or custom builds
  • Triggers — fire sandboxes automatically when matching files change, enabling event-driven pipelines
  • Delegation — run as an agent or role with scoped permissions, never your full user access
  • Secrets — encrypted secrets are injected as environment variables and never appear in API responses

Sandboxes guide

Network — fully audited

Every outbound request from a sandbox passes through a proxy sidecar that enforces network policies and records every connection. Cloud metadata endpoints, private networks, and link-local addresses are blocked by default — no configuration required.

  • Zero setup — safe defaults block common exfiltration paths (RFC1918, link-local, cloud metadata) from day one
  • Granular control — allow specific hostnames, methods, or paths per agent, role, or repository, written in the same policy DSL as RBAC
  • Complete audit log — every request, allowed or denied, is captured with the proxy decision and upstream response metadata
  • TLS-aware — the proxy terminates HTTPS so policies can match the actual destination, not just an IP

Network isolation

Better together

Each layer is useful on its own. Combined, they let you treat any workload — including code you didn't write — as a transactional, auditable unit:

  1. A trigger fires when raw data lands in the repo through a connector — S3, Google Cloud Storage, Google Drive, GitHub, or one of the other supported sources.
  2. A sandbox spins up with the new data mounted at /sandbox, runs your validation and transformation, and writes the cleaned output back.
  3. The proxy logs every external API the script touched along the way, and the network policy stops anything off-limits before it leaves the box.
  4. On clean exit, all writes commit as a single versioned snapshot tied to the agent that produced them. On failure, nothing changes and you keep the full log for debugging.

The same model serves ad-hoc analysis, scheduled jobs, and autonomous AI agents — because the boundaries are the product, not something you bolt on later.

Getting Started

  • Quickstart

    Sign up, create your first repository, and start versioning data in minutes.

    Quickstart

  • Sandboxes

    Run code against your data in isolated containers, with automatic triggers for event-driven pipelines.

    Sandboxes

  • CLI

    The tilde command-line tool for authentication, repository management, and data transfer.

    CLI

  • Python SDK

    Install the official Python SDK and start versioning data in a few lines of code.

    Python SDK