Runtime
The runtime is the language environment your tool runs in. Rival supports Python 3.13, Python 3.13 — Fast, JavaScript (on V8), Node.js, and Lua. The runtime is set when the tool is created and stays with the tool for its lifetime - you can’t switch runtimes after creation.
Each runtime has its own conventions for the handler filename, the entry point, and how you bring in third-party code.
Python 3.13
Python is the most capable runtime on Rival. It gives you the full Python package ecosystem - NumPy, Pandas, Requests, OpenAI, Anthropic, and anything else available on PyPI. If your tool needs data processing, machine learning inference, HTTP clients, or complex logic that benefits from a mature library ecosystem, Python is the right choice.
Pre-loaded: Python 3.13 with the standard library. Common scientific and HTTP libraries can be added via requirements.txt.
Dependencies: declare them in a requirements.txt file alongside your handler. Rival reads that file and installs the listed packages before your code runs.
Filename and handler convention:
- Main file:
cortexone_function.py - Entry function:
cortexone_handler(event, context)
These names are how the runtime locates and calls your code. Stick to them and Rival will route invocations to your handler automatically.
Trade-off: Python tools install dependencies on cold start, so the first run after a quiet period takes a moment longer than JavaScript or Lua. For most tools this doesn’t matter; for ultra-low-latency use cases without outbound HTTP, consider Python 3.13 — Fast.
Pick Python when:
- You need third-party libraries (ML models, data manipulation, API clients)
- Your tool requires outbound HTTP requests
- Capability matters more than the last few hundred milliseconds of latency
- Your team is most productive in Python
- You require multiple files in your editor
GPU compute: Python 3.13 functions can run on a GPU (CUDA 12.4) instead of CPU by setting Compute Type: GPU, with PyTorch, TensorFlow, and the HuggingFace ecosystem pre-installed. See GPU compute for the full package list and resource limits.
Python 3.13 — Fast
Python 3.13 — Fast runs the same language as Python 3.13 but without a container cold start. Execution begins almost immediately, making it the lowest-latency Python option on the platform.
Pre-loaded: Python 3.13 with the full standard library and a set of built-in utilities (hash_digest, btoa/atob, crypto, json_encode/json_decode, text_encode/text_decode, url_parse, structured_clone) available without any import.
Dependencies: declare packages in a requirements.txt. Only pure-Python packages and a curated set of scientific libraries (numpy, pandas, scipy, pillow, and others) are available — packages that require platform-specific native binaries may not be supported.
Secrets: accessed via process["env"] (a dict always in scope), not os.environ.
Filename and handler convention:
- Main file:
cortexone_function.py - Entry function:
cortexone_handler(event, context)
Restrictions: no outbound HTTP (fetch() is not available), no subprocess/multiprocessing, no dangerous os operations. If you need HTTP or a package outside the supported set, use Python 3.13.
Pick Python 3.13 — Fast when:
- You need the lowest possible Python execution latency
- Your logic is self-contained (no outbound HTTP)
- Your dependencies are pure-Python or from the supported package set (numpy, pandas, scipy, etc.)
JavaScript
The JavaScript runtime runs on V8 - the same engine that powers Chrome and Node.js. It starts fast and executes fast, well-suited for tools that need low latency without complex dependencies.
Pre-loaded: the standard JavaScript built-ins (no Node.js APIs, no browser APIs). Your handler runs in a sandboxed V8 instance.
Dependencies: there is no package manager available. JavaScript tools must be self-contained - no import or require from external modules.
Execution model: synchronous only. async/await, Promises, setTimeout, and setInterval are not supported; fetch() is synchronous and returns the response directly. If you need any of these, use Node.js.
Filename and handler convention:
- Main file:
cortexone_function.js - Entry function:
cortexone_handler(event, context)
Pick JavaScript when:
- You need fast, low-latency execution
- Your logic is self-contained and doesn’t need external packages
Node.js
Node.js runs full Node.js 24 in a container. It’s the JavaScript option when you need the npm ecosystem, async code, or more than one file.
Pre-loaded: Node.js 24 with its built-in modules (fs, path, crypto, and the rest) and the standard Promise-based fetch.
Dependencies: declare npm packages in a package.json alongside your handler. Rival installs them on the first run (npm ci when you ship a package-lock.json).
Execution model: asynchronous - the handler may be async, and fetch() returns a Promise. Containers stay warm between calls, so only the first run pays for start-up and the dependency install.
Filename and handler convention:
- Main file:
cortexone_function.js(.mjsand.cjsalso work) - Entry function:
cortexone_handler(event, context), which must be exported withmodule.exports = { cortexone_handler }or an ESMexport
Pick Node.js when:
- You want JavaScript with npm packages
- Your code uses
async/awaitor Promise-based libraries - You need multiple files in your editor
Lua
Lua is the lightest runtime on Rival. It starts almost instantly and has a minimal footprint, ideal for simple transformation, formatting, or rule-based logic.
Pre-loaded: Lua’s standard library, sandboxed.
Dependencies: no package manager. Like JavaScript, Lua tools are single-file and self-contained.
Execution model: synchronous, deterministic.
Filename and handler convention:
- Main file:
cortexone_function.lua - Entry function:
cortexone_handler(event, context)
Pick Lua when:
- Your tool does fast, deterministic computation
- You want the lowest possible startup and execution overhead
- You’re comfortable with Lua’s syntax and standard library
Comparing the runtimes
| Python 3.13 | Python 3.13 — Fast | JavaScript | Node.js | Lua | |
|---|---|---|---|---|---|
| Startup speed | Slower on cold start (dependency install) | Instant — no container | Fast | Slower on cold start (container + npm install), fast when warm | Fastest |
| External packages | Yes, via requirements.txt (full PyPI) | Limited — pure-Python + supported set | No | Yes, via package.json (npm) | No |
| HTTP access | Yes | No | Conditional | Yes | Conditional |
| Async support | Yes | Yes | No | Yes | No |
| Multi-file | Yes | Yes | No | Yes | No |
| Secrets | os.environ | process["env"] | process.env | process.env | process.env |
| Best for | Data, ML, API integrations | Low-latency Python without HTTP | Fast, self-contained logic | JavaScript with npm packages and async code | Lightweight, deterministic tasks |
Why the runtime is locked
Once a tool is created, its runtime doesn’t change. This is intentional: callers who’ve integrated your tool rely on its behavior staying stable across versions, and a runtime swap would silently change everything about how the tool runs. If you need a different runtime, create a new tool - it keeps versioning honest and integrations safe.