Diagram: Typical data-processing flow
Choose the right execution pattern
| Pattern | Best for | Core fields |
|---|---|---|
| stdin transform | small/medium JSON payloads | stdin, code, runtime |
| file-based run | CSV/images/multi-file artifacts | files, outputPaths |
| persistent pipeline | multi-step transformations with shared state | mode: "persistent", putFile/getFile or remote sessionId |
Baseline configuration
Pattern 1: stdin transformations
Great for row-wise mapping, filtering, and aggregation where input/output are JSON.- Library
- API
- CLI
Pattern 2: file-based processing and artifact retrieval
Use this when jobs need multiple inputs or non-text outputs (CSV, PNG, parquet, etc.).- Library
- API
CLI
run does not expose full generic files/outputPaths request fields. Use library or API for full file injection/retrieval workflows.Pattern 3: multi-step persistent pipelines
Use persistent mode when later steps must reuse files from earlier ones.Remote pipelines with shared sessions
For distributed workers, use remotesessionId instead of keeping local engine state.
Package strategy for stable throughput
installPackages is powerful but adds latency. For production data workloads:
- move stable dependencies into
isol8.config.jsondependencies.* - run
isol8 setupto pre-build custom images - keep per-request installs for truly dynamic packages only
Parallel batch processing
You can schedule many independent jobs withPromise.all; engine semaphores and maxConcurrent bound active container count.
Returning chart/image artifacts
For visual outputs, write image files into/sandbox and retrieve via outputPaths.
Related pages
Execution guide
Request fields, execution modes, streaming, and output semantics.
Packages and images
Pre-bake dependencies to reduce per-job install latency.
Remote server and client
Run processing jobs on centralized remote infrastructure.
Performance tuning
Tune concurrency, pool behavior, and resource limits.