Skip to main content
You can deploy, manage, and delete top-level app functions directly from the Buildfunctions Dashboard or from your code using the Buildfunctions SDK.

Functions vs. Sandboxes

It is important to understand the distinction between Functions and Sandboxes in the Buildfunctions ecosystem:
  • Functions (CPUFunction, GPUFunction): Orchestrate top-level application or agent logic.
  • Sandboxes (CPUSandbox, GPUSandbox): Execute untrusted and dynamic agent actions with full GPU access, automatic model mounting, built-in AI frameworks, runtime dependency installs, and more. They spin up instantly for isolated tasks and can run for up to 24 hours. This guide focuses on Functions—deploying and managing your top-level infrastructure.

Building functions

Below is a high-level overview of how to structure your Buildfunctions handler functions and their responses. The various examples demonstrate a consistent pattern: a main entry point function named handler that returns (or echoes) a response containing at least a body. Beyond that, you can optionally include a status code and headers in the natural syntax the language supports.
  1. The handler function:
  • Naming: Your main function must be named handler. This name is how Buildfunctions identifies which function to invoke when your code runs.
  • Purpose: The handler function is your function’s entry point. It contains the logic you want to run whenever your function is invoked. You can write other helper functions, but only the handler will be called automatically.
  1. The response format:
Your handler function must provide a response that can be returned to the caller. While the exact syntax differs by language, the structure is essentially the same:
string
required
The main content you want to return
number
A numeric HTTP status code (e.g., 200 for success, 500 for a server error)
object
Custom headers, such as Content-Type, can also be included
Cache-related functionality will be available soon

Example Response Structures

Omit constructs like if __name__ == "__main__" in Python or handler() in JavaScript, as the platform will handle invocation.

Supported Runtimes

Buildfunctions supports a variety of modern runtimes for your functions:

CPU Functions

CPU functions are suitable for general-purpose workloads, orchestration, and lightweight tasks.

1. Function Code (Multi-Language Examples)

2. Deploy via SDK

GPU Functions

Deploying a GPU function involves defining the configuration (hardware, runtime) and the code to be executed.

1. Function Code (Streaming Architecture)

This example demonstrates a streaming text generation function using transformers. It includes a requirements block to specify dependencies.
Python

2. Deploy via SDK

Use GPUFunction.create to deploy. You can specify advanced configuration like gpu type, cpu count, and timeout.

Function Configuration

When creating functions, you can configure the following resources:
  • gpu: GPU type (e.g., T4G).
  • memory: RAM allocation (e.g., 512MB, 2GB, 16GB).
  • timeout: Execution timeout in seconds.
  • runtime: Execution environment (e.g., deno, node).
For specific runtimes, you can include dependency instructions:
  • Python: Add a requirements.txt block in your code comments or string.
  • Deno: Add run arguments like deno run --allow-ffi.

Function Management

Find and Delete

You can search for and delete functions using the main client.
JavaScript

Advanced Usage: Nested Orchestration

A powerful pattern in Buildfunctions is using a top-level Function to orchestrate nested Sandboxes. This allows you to combine persistent endpoints with ephemeral, high-performance compute.

Example: GPU Function spawning nested Sandboxes

This example demonstrates a Node.js GPU Function that spins up both a CPU sandbox (for text analysis) and a GPU sandbox (for Python inference).
JavaScript