Docker Sandbox
Every code execution node in NodeLoom runs inside an isolated Docker container with strict resource limits and security policies. This sandbox cannot be disabled from the frontend -- it is enforced at the server level.
Server-enforced isolation
Affected Nodes
The following node types are executed inside the Docker sandbox. Any workflow that includes one of these nodes will automatically spin up an isolated container for each execution.
| Node Type | Description |
|---|---|
| Code | General-purpose code execution supporting multiple languages. |
| JavaScript | Runs JavaScript/Node.js code snippets. |
| Python | Runs Python scripts with access to common libraries. |
| Bash | Executes Bash shell scripts. |
| Shell | Executes shell commands in a POSIX-compatible shell. |
| Execute Command | Runs arbitrary system commands. |
Container Hardening
Each sandbox container is launched with a comprehensive set of security constraints. These are applied at the Docker level and cannot be overridden by user code.
Resource Limits
| Constraint | Value | Purpose |
|---|---|---|
| CPU | Configurable limit | Prevents a single execution from monopolizing CPU resources. |
| Memory | Configurable limit | Hard cap on memory usage. Exceeding this kills the container. |
| Swap | Disabled (0) | No swap space is available, preventing memory overcommit. |
| PID limit | 100 | Caps the number of processes to prevent fork bombs. |
| Open files (ulimit) | 1024 | Limits the number of file descriptors. |
| Processes (ulimit) | 64 | Limits the number of processes the user can spawn. |
| File size (ulimit) | 10 MB | Prevents writing excessively large files to disk. |
Security Policies
Each container runs with hardened security policies including privilege escalation prevention, restricted filesystem access, network isolation, and non-root execution. These policies are enforced at the Docker level and cannot be overridden by user code.
Output Truncation
Container output (stdout and stderr combined) is truncated at 1 MB. Any output beyond this limit is discarded to prevent memory exhaustion in the execution engine. If your code produces large output, write it to the tmpfs volume and read it back selectively.
SSH/SFTP Host Key Verification
When workflows connect to remote servers via SSH or SFTP, NodeLoom uses a Trust On First Use (TOFU) model for host key verification. The first time a connection is made to a host, its public key is recorded. Subsequent connections verify the key against the stored fingerprint.
If the host key changes (potentially indicating a man-in-the-middle attack), the connection is rejected and an error is logged. You can clear stored host keys from the credential management interface to re-establish trust.
If the host key changes, the connection is rejected with a verification error. You can clear stored host keys from the credential management interface to re-establish trust.
TOFU model