Create Serverless Function (FaaS)

This guide shows practical steps and examples for deploying serverless functions — AWS Lambda, Azure Functions, and Google Cloud Functions — using the Fractal SDK.

Functions deploy the same way as every other workload: you publish your code once as an OCI artefact to your registry, the component references that artefact, and the agent deploys it the way the target FaaS needs.

For a conceptual overview of custom workloads and the one-artefact contract, see Dev Experience Invariant and Deploying Custom Workloads with the Fractal SDK.

SDK Availability

Serverless function deployment is supported in the TypeScript SDK.

Cloud provider guides

Provider	Service	Guide
Amazon Web Services	AWS Lambda	Create AWS Lambda
Microsoft Azure	Azure Functions	Create Azure Function
Google Cloud Platform	Cloud Functions (gen2)	Create Google Cloud Function

The sourceArtifact contract

A function references a single parameter that points at its code: sourceArtifact — an OCI artefact reference in your own registry (ECR, ACR, or Artifact Registry), exactly like a container image.

sourceArtifact = <registry-host>/<repository>:<tag>

Examples:

123456789012.dkr.ecr.eu-central-1.amazonaws.com/orders-fn:1.4.0      # AWS ECR
myacr.azurecr.io/orders-fn:1.4.0                                     # Azure ACR
europe-west1-docker.pkg.dev/my-project/functions/orders-fn:1.4.0    # Google Artifact Registry

The artefact is one of two shapes; the agent auto-detects which from the OCI manifest:

Artefact shape	What it is	How the agent deploys it
Container image	A runnable OCI image	AWS Lambda PackageType=Image; Azure Function on a Linux container plan. Not supported on GCP (Cloud Functions gen2 build from source only).
Zip artefact	An OCI artefact whose single layer is your function's deployment zip	AWS Lambda zip (inline or S3-staged); Azure WEBSITE_RUN_FROM_PACKAGE blob; GCP GCS source object.

You never stage code into a provider bucket yourself — the agent owns that. You only publish the artefact and reference it.

Cross-cloud functions

Because GCP can only build from a zip artefact, publish a zip artefact if the same function must run on all three clouds. AWS and Azure accept either shape, so a zip artefact is the portable default. Set packageType ("image" | "zip") only to override the agent's auto-detection.

Prerequisites (Customer Responsibilities)

1. Publish your function code as an OCI artefact to the registry your target cloud can pull from (ECR / ACR / Artifact Registry), from your CI/CD — the same step you already do for container images. The artefact bytes are identical across registries.
2. Registry access for the agent. The Fractal cloud agent pulls the artefact with its own identity:
   • AWS: the agent's ECR access (same account/region as the Lambda).
   • Azure: the Function App's managed identity is granted AcrPull on the ACR.
   • GCP: the fractal-cloud-agent service account reads the Artifact Registry repository.
3. An execution role / identity where the provider requires one (e.g. an AWS Lambda execution role — the agent falls back to the environment-provisioned role when you don't set roleArn).

Deploying with the Fractal SDK

1. Define the function component, referencing the artefact via sourceArtifact (see the provider guides).
2. Add it to your Live System alongside its dependencies.
3. Deploy through the SDK — authentication and reconciliation are handled by the platform.

The agent reconciles idempotently: it inspects the artefact's manifest digest each pass and only redeploys when the artefact has changed, so steady-state reconciles do not restart your function.