VirtualFileSystem to back the sandbox with any storage layer — a database, S3, a zip archive, or anything else. Sandboxed code uses fs, require, and other Node APIs as normal, and your implementation handles the actual I/O.
The interface
Your class must implementVirtualFileSystem from secure-exec-core:
Example: read-only Map filesystem
A minimal filesystem backed by aMap<string, string>. Useful when you have a fixed set of files (e.g. loaded from a database) and want to make them available to sandboxed code.
Using it
More examples
Full, tested implementations for common storage backends:S3 / MinIO
Store sandbox files as S3 objects. Works with any S3-compatible store (AWS, MinIO, R2). Includes Docker Compose for local testing with MinIO.
SQLite
Store sandbox files as rows in a SQLite database (via sql.js / WASM). Snapshot and restore entire filesystems. No external services needed.
VirtualFileSystem:
- Git-backed storage — store files in a bare Git repo, with each sandbox session as a commit
- Encrypted filesystem — wrap another VFS and encrypt/decrypt content transparently
- Union / overlay filesystem — layer a writable VFS on top of a read-only base (e.g. template files + user modifications)
- Remote filesystem — proxy file operations to a remote server via HTTP or gRPC
Tips
- Throw Node-style errors. Sandboxed code expects errors like
ENOENT,EACCES, andEISDIR. Match the error message prefix sofserror handling works naturally. - Normalize paths. All paths are absolute POSIX paths (forward slashes, rooted at
/). Normalize before lookup to avoid mismatches. - No-op what you don’t need. Operations like
chmod,chown, andutimescan be no-ops if your storage layer doesn’t support them. ThrowENOSYSfor operations that genuinely can’t work (like symlinks on a flat key-value store). - Use
createInMemoryFileSystem()as a reference. The built-in in-memory filesystem is a complete implementation you can study or extend.