EXECUTIONS

Run code in the cloud.
Directly from your application.

Integrate code execution into your product through an SDK or API. Process files and tasks in isolated virtual machines, with resources defined for each execution.

I want to integrate execution View pricing and estimate usage ↗

One virtual machine
for each Execution.

Each Execution starts a virtual machine to run your code. Generate PDFs, transform data, or process files sent by your application.

When the Execution ends, the machine shuts down. Collected results and files remain available for you to retrieve.

How to use Executions.

Run from the terminal, use the dashboard, or integrate with your application.

Use the CLI.

Start an execution and check its status from the terminal. Use the same commands in scripts to automate recurring Executions.

Use the dashboard.

Create and monitor executions in the runvibe_ dashboard. Choose the code and resources, then check status, logs, and generated files.

Integrate your application with the SDK.

Start Executions from your application code with the SDK. Track the run and use its result in the next processing step.

Execution inside your product.

Your application submits a task, tracks execution, and uses the result in the next step. runvibe_ checks permissions and configuration before starting.

An AI application can submit a file for processing and retrieve the collected results to continue the task.

Connect your AI tools.

Connect an MCP-compatible tool, such as Codex, Claude Code, or Cursor, to start Executions and retrieve results.

Configure reusable
executions.

TOML manifests.

Describe what to run and its required resources in a TOML file. Include variables, volumes, network rules, and a time limit. Reuse the manifest to start executions with the same configuration.

Packages in the manifest.

Specify which Package to use, the entry file, and its arguments. The Execution starts that file; calls to specific functions belong in the code itself.

For uses that require review, the exact Package content must be approved. Approval does not replace execution permissions and policies.

Explore the approval workflow ↗

Volumes with input data.

Make volume files available at the path expected by your script or container. The Execution preserves the source volume; writable copies in containers are temporary.

Environment variables.

Declare the configuration values the process needs in the manifest. For container Executions, define variables for each container.

Credentials with Secrets.

Store tokens, passwords, and API keys in the Secrets vault. In the Execution configuration, map a Secret reference to the environment variable your application expects. The process receives the value at runtime, without writing it into code or the manifest.

Network controls.

No external access.

Disable outbound networking for Executions that only process the data provided.

Allowed destinations.

Restrict outbound traffic by IP, range, or domain, with defined protocols and ports.

Host-enforced policy.

The host enforces the rules and blocks access to private networks, local addresses, and infrastructure metadata, including in public mode.

Separate image download and execution.

For containers, configure one policy for downloading images and another for running code. Allowing a registry during download does not allow access to it during the Execution.

Choose the format
for your execution.

Send a script, a Package, or a container configuration. Scripts and Packages can use a prepared image in supported runtimes.

Python and Node.js scripts.

Send Python or JavaScript code directly and choose a runtime. The script starts in its working directory with the variables and volumes you configured.

Use this format for one-off automation, data transformation, or AI-generated code. Direct uploads do not require packaging the project in a ZIP.

Images with a prepared environment.

Use an image with tools and dependencies already installed. You can prepare it in a Workspace. Scripts and Packages use this environment in supported runtimes.

Each execution receives a writable copy of the image. Installs and changes stay in that copy, preserving the published image for future Executions.

Containers from OCI images.

Specify an OCI image, command, and environment variables. Add supporting services when your Execution needs them. Containers in the same Execution share CPU, memory, and network.

Use this format for applications already packaged in containers. Exit codes and logs for each container are available after collection.

Reusable Packages.

Bundle project code and files in a ZIP to upload them together. Use Packages when processing depends on multiple files, such as Python modules and report templates.

Reuse a Package in new Executions without uploading the files again.

Retrieve results
and download files.

After collection, use the Execution ID to retrieve results and files through the API, CLI, or MCP. Write structured results to result.json and files to outputs/.

Structured results through the API.

Write data to result.json. Retrieve the JSON result through the API and use it in your application.

Files generated by the Execution.

Save reports, documents, and other files in outputs/. Retrieve artifacts through the API and request the file you need. Availability follows platform limits and retention periods.

Use the CLI or AI tool.

Use the CLI to retrieve results and download artifacts with the Execution ID. With an AI tool connected through MCP, ask it to retrieve results or generated files and continue working with them.

Execution logs and metrics.

Review standard output and errors in stdout and stderr. Track status, duration, and resource metrics. Container logs are available after collection at the end of the run.

Isolation and controls
for each execution.

Dedicated kernel

The Execution runs in a virtual machine with a kernel separate from the host and other executions. Containers in the same Execution share that machine's kernel.

Forward ports for local access

Forward ports through the CLI for active container or Package Executions configured without a duration limit. Direct scripts do not support this access. Forwarding ends with the Execution.

Set resources

Choose CPU and memory for each execution based on the work it needs to do.

Timeout and cancellation

Set a time limit for the Execution and request cancellation when you need to stop it.

Pay for the time
your code runs.

In the runvibe_ cloud, processing consumes your plan balance according to resources and runtime.

Execution charges end with the task; subscription and storage charges follow your plan’s rules.

Estimate my usage ↗

Start the Execution

Code, inputs, and configuration are set

Run in the cloud

Usage depends on selected resources and runtime

Retrieve results

Execution ended · compute environment released

Frequently asked questions.

Do I need to create a Workspace first?

No. Start an Execution with Python or Node.js code, a Package, or containers. Use a Workspace when you want to prepare and test an environment image for reuse.

How do a Package and manifest work together?

A Package contains the code and files; the manifest defines how to run them and which resources to use. View configuration ↗

How do I receive results in my application?

Write data to result.json and files to outputs/. Retrieve them after collection with the Execution ID. View results and files ↗

Can I use an image prepared in a Workspace?

Yes, in runtimes that support prepared images. This lets you reuse an environment with installed dependencies. Container Executions use OCI images and their own configuration.

Where can I check errors and resource usage?

In the execution details, check status, stdout, stderr, and recorded metrics. Container logs are collected at the end of an Execution.

When should I choose Execution or Workspace?

Use Execution for processing with a defined start and end, integrated into your application or automation. Choose Workspace to develop, test your application, and resume work in the same environment.

Request access
to use Executions.

I want to integrate execution

Explore plans ↗