Functions

A function is a project-scoped, named handler: an OCI image plus a simple wire contract (an HTTP server listening on a port). You deploy it once, then invoke it whenever you need it. Unlike a sandbox — a machine you hold and interact with — a function is code you call. Daytona owns the whole machine lifecycle: it starts managed microVM instances to serve invocations and scales them to zero when idle, so there is nothing to keep running and nothing to shut down.

Functions are billed per invocation duration — the wall-clock time of each invocation — at the provisioned CPU and memory shape of the function's version. Idle warm capacity and instance startup are Daytona's cost, not yours. This makes functions a good fit for on-demand jobs, webhooks, batch fan-out, scheduled tasks, and agent tools: anything you would rather call than SSH into.

Function vs. sandbox

Both run as isolated managed microVMs, but they solve different problems. Reach for a sandbox when you need an interactive, stateful machine you drive over time (a shell, a dev environment, a long-lived agent workspace). Reach for a function when you have a unit of work you want to invoke and get a result back from, with the platform handling scaling and teardown.

The wire contract

A function handler is an ordinary HTTP server. On each invocation Daytona forwards your request body to the handler as POST / on the function's port (default 8080) and returns the handler's HTTP response body back to the caller. JSON in / JSON out is the common shape, but the body is forwarded verbatim, so any content type works.

Two environment variables tell the handler how to run. The instance always receives RLP_FN_PORT — the port to listen on — and, when you deploy with a custom handler argv, RLP_FN_HANDLER. A minimal handler reads RLP_FN_PORT and serves POST /:

import os
from http.server import BaseHTTPRequestHandler, HTTPServer
 
class Handler(BaseHTTPRequestHandler):
    def do_POST(self):
        body = self.rfile.read(int(self.headers.get("Content-Length", 0)))
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        self.wfile.write(body)  # echo the request back
 
port = int(os.environ.get("RLP_FN_PORT", "8080"))
HTTPServer(("0.0.0.0", port), Handler).serve_forever()

Lifecycle at a glance

Deploying a function creates an immutable version and points "current" at it; redeploying the same name rolls forward to a new version. Invoking resolves the current version and runs your payload against a warm instance (or a freshly started one on a cold start). You never provision or scale instances yourself — creation is fast enough that scaling is demand-driven.

• Deploying — package a handler, deploy it, and manage versions.
• Invoking — synchronous invoke, async spawn, and map fan-out.
• Scaling — concurrency, spend guards, and cold starts.
• Scheduling — run a function on a cron cadence.
• Public endpoints — expose a function as a public web URL for webhooks.

SDK and API access

Functions are managed through daytona.fn in the SDKs (a FunctionService), the /fns REST routes, and the dashboard. See the Python SDK reference, the TypeScript SDK reference, and the Functions API reference for full details.

from rlp import Daytona
 
daytona = Daytona()
 
daytona.fn.deploy("echo", image="ghcr.io/acme/echo:latest")
result = daytona.fn.invoke("echo", {"hello": "world"})

import { Daytona } from '@rlp/sdk'
 
const daytona = new Daytona()
 
await daytona.fn.deploy({ name: 'echo', image: 'ghcr.io/acme/echo:latest' })
const result = await daytona.fn.invoke('echo', { hello: 'world' })