For OS-level memory isolation, use the worker threads adapter. This provides stronger isolation than the default VM context by running code in separate Node.js worker threads.Documentation Index
Fetch the complete documentation index at: https://docs.agentfront.dev/llms.txt
Use this file to discover all available pages before exploring further.
Basic Usage
Worker Pool Features
- Pool management - Auto-scaling with min/max workers
- Memory monitoring - Workers recycled when exceeding limits
- Hard halt - Force terminate via
worker.terminate() - Rate limiting - Message flood protection
- Dual-layer sandbox - Worker thread + VM context isolation
Worker Pool Presets
| Setting | STRICT | SECURE | STANDARD | PERMISSIVE |
|---|---|---|---|---|
| maxWorkers | 4 | 8 | 16 | 32 |
| memoryLimitPerWorker | 64MB | 128MB | 256MB | 512MB |
| maxExecutionsPerWorker | 100 | 500 | 1,000 | 5,000 |
| maxQueueSize | 20 | 50 | 100 | 500 |
| maxMessagesPerSecond | 100 | 500 | 1,000 | 5,000 |
Using Presets
Configuration Options
Memory Isolation Benefits
Worker threads provide stronger isolation than VM contexts alone:- Separate V8 heap - Each worker has its own memory space
- Hard memory limits - OS-level enforcement via
--max-old-space-size - Process-like isolation - Worker crash doesn’t affect main process
- Clean termination -
worker.terminate()guarantees cleanup
When to Use Worker Pool
Use the worker pool adapter when:- Running code from completely untrusted sources
- Memory isolation is critical
- You need hard termination guarantees
- Processing many concurrent executions
- Memory isolation is less critical
- You need lower latency
- Running trusted or semi-trusted code
- Simpler deployment is preferred
Dual-Layer Sandbox
The worker pool provides two layers of isolation:- Worker Thread - OS-level process isolation
- VM Context - JavaScript-level sandboxing
Monitoring Worker Health
Related
- Security Levels - Security presets
- Double VM - Additional security layer
- Configuration - All configuration options