Storage
Rival tools are stateless by design. Understanding what that means for storage - and what options you have for data that needs to persist - will save you from surprises when building.
Execution storage is ephemeral
Every tool execution runs in an isolated environment that is discarded when the execution completes. Any files written to the local filesystem during an execution do not survive to the next call. There is no shared disk, no persistent working directory, and no way for one execution to read files left behind by a previous one.
This is a feature, not a limitation. Stateless executions are predictable, safe to run in parallel, and easy to reason about - each call is fully independent.
For persistent files: Digital Assets
If your tool needs to read a file that should persist between executions - a dataset, a configuration file, a topic taxonomy for a Storm tool, or any other resource - the answer is Digital Assets.
Digital Assets is Rival’s built-in cloud file storage. You upload files in Dashboard, and each file gets a stable path that you can reference inside your tool handler code. The file is there every time your tool runs, regardless of when or how often it is called.
Files and folders up to 500 MB are supported. Assets can be marked Public (accessible to anyone with the path) or Private (accessible only within your organization).
See Digital Assets for a full walkthrough of uploading files and referencing them in your handler.
For persistent state: use an external database
Digital Assets is great for files, but it is not a database. If your tool needs to store and query structured data that changes at runtime - user records, counters, session state, generated content - you need to connect to an external database.
Rival does not provide a built-in database. Your handler can connect to any external data store over the network: Postgres, MongoDB, Redis, Supabase, PlanetScale, or any other service your use case calls for. Store the connection credentials as environment variables in your workspace settings and read them in your handler at runtime.
This approach keeps your tool portable and lets you choose the right database for the job.
Summary
| Need | Solution |
|---|---|
| Read a file at runtime | Upload to Digital Assets, reference the path in your handler |
| Store structured data between executions | Connect to an external database |
| Temporary computation during an execution | Use in-memory variables - they are fine within a single execution |
| Share state between concurrent executions | Use an external store; the execution environment has no shared memory |