Functions overview

This page explains what a function is on the Crusoe Agent Platform, when to pick one over an agent or a serverless container, and how functions compare to AWS Lambda, Google Cloud Run functions, and Azure Functions.

What a function is

A function is the smallest thing you can deploy: one file with one handler. You write a handle(event) function, run one command, and the platform gives you back an HTTPS endpoint that scales to zero — when nobody is calling it, it runs zero copies and uses none of your project's capacity. The first request after idle starts a copy (a "cold start", usually a few seconds), and requests after that are fast.

Four runtimes are supported. A runtime is the language environment your handler runs in:

Runtime	Handler file	Handler symbol
python (default)	handler.py	def handle(event)
nodejs	handler.js	exports.handle
go	handler.go	func Handle (compiled, standard library only)
ruby	handler.rb	def handle

Each runtime's exact contract, with a complete working example, is on the runtimes page.

The 30-second mental model

Your handler never touches HTTP directly. The platform wraps it in a small web server called a shim that speaks one shared contract for all four languages: it turns an incoming request into an event dictionary, calls your handler, and turns your return value into the JSON response.

• GET requests call your handler with an empty {} event.
• POST requests parse the JSON body into the event (capped at 8 MiB).
• Return {"statusCode": 404, ...} to control the HTTP status; the default is 200.
• Event deliveries in the CloudEvents format are acknowledged with an empty 204 — see HTTP and events.

Functions ride the agents surface

Here is an honest implementation detail that pays off in practice: functions are not a separate product with its own API. A function is deployed through the same endpoint as agents — POST /v1/agents — with two extra form fields: framework=function and a runtime. That means everything you already know about agents applies to functions too:

• Same CLI verbs: platformctl list, status, invoke, logs, delete.
• Same name rules: lowercase DNS labels, up to 63 characters, sharing one flat namespace per project with agents (a function and an agent cannot have the same name).
• Same async deploy flow: the API answers 202 with a build_id, then you poll status through building, deploying, ready.
• Same management-plane authentication and the same invoke path.

The only functions-specific pieces are the runtime field, the handler contract, and one sharp edge: the agent "redeploy" shortcut is disabled for functions, because it would rebuild your code as an agent. To ship a new version, run platformctl functions deploy again — each deploy replaces the whole source tree. Details in troubleshooting.

When to use a function

Use a function when:

• The job is one request in, one response out: webhooks, small APIs, glue code, event handlers.
• You want the least possible ceremony — one file, no Dockerfile, no framework.

Use an agent instead when you need an LLM-powered workload with sessions, memory, and tools. Use a serverless container service when you already have a container image, or when you need knobs functions do not expose: traffic splitting between revisions, min-instance settings, or non-HTTP triggers (schedules, object-storage events, Pub/Sub). On this platform today, those trigger types belong to the Serverless surface, not to functions.

How it compares

The big clouds split "give me an HTTPS endpoint from a bit of code" across several products (Lambda vs. App Runner vs. Fargate; Cloud Run vs. Cloud Run functions; Azure Functions vs. Container Apps). Here, there is one path. An honest comparison:

	Crusoe Agent Platform Functions	AWS Lambda	GCP Cloud Run functions	Azure Functions
Programming model	handle(event) in one file	lambda_handler(event, context)	HTTP function entry point	Triggers and bindings
Runtimes	4 (Python, Node.js, Go, Ruby)	Many, plus custom runtimes	7+	Many, plus custom handlers
Public HTTPS URL	Built in — no gateway product to configure	Function URLs or API Gateway (separate setup)	Built in	Built in
Event triggers	HTTP and CloudEvents; other trigger types live on the Serverless surface	Very large trigger catalog	Eventarc catalog	Large bindings catalog
Regions, SLAs, free tier	Alpha platform: no multi-region, no SLA	Global regions, SLA, free tier	Global regions, SLA, free tier	Global regions, SLA, free tier

If you are coming from Lambda: our handle(event) is the direct analogue of your handler, but the HTTPS endpoint comes with the deploy — there is no separate API Gateway resource to wire up, and no IAM execution role to create first.

Alpha honesty

This platform is in alpha. The big clouds have more runtimes, more trigger types, more regions, and SLAs. What we offer is one product, one command, scale-to-zero by default, and documentation that shows you real commands with real output.

Next steps

• Quickstart — deploy, invoke, and delete a Python function in a few minutes.
• Runtimes — the exact handler contract per language.
• HTTP and events — GET vs. POST, the 8 MiB cap, and CloudEvents.
• Troubleshooting — real failure modes with real error messages.