Copy page

Use Cases

Serverless Functions

Serverless functions let you deploy small pieces of business logic without managing servers or runtimes. They're ideal for event-driven pipelines, API backends, and dynamic code execution—but traditional function-as-a-service platforms often suffer from cold-start penalties and opaque sandboxing.

With Unikraft Cloud, you can run serverless functions inside microVMs: instant availability, VM-level isolation, and true scale-to-zero economics. The ROM (Read-Only Memory) model goes one step further—package your function code independently of the runtime image, and swap it in at instance creation time.

Why run serverless functions on Unikraft Cloud

⚡ Millisecond cold starts with instance templates

Unikraft Cloud's instance templates pre-initialize a runtime once, then stamp out new instances from that snapshot. Combined with stateful scale-to-zero, instances resume from a warm snapshot rather than booting from scratch:

• Single-digit-millisecond wake-ups, even under burst traffic.
• No re-execution of startup logic between requests.

🔒 Strong isolation per function

Every function instance runs in its own microVM. No shared kernel, no noisy-neighbour risk, and no container escape surface. Sensitive business logic stays protected even when other tenants share the same platform.

💸 Pay only for execution

Functions are inherently bursty. Scale-to-zero means an idle function costs nothing. The ROM model makes this even leaner: you package the base runtime image once, and only the lightweight function ROM changes per deployment.

🔄 Decouple runtime from function code

ROMs separate the runtime image (Node.js, Python, etc.) from the function payload:

• Update function code by pushing a new ROM—no runtime rebuild required.
• Run many specialised functions from a single base image.
• Instant rollback by pointing an instance at a previous ROM version.

Getting started

This guide uses the node-code-execution example. It deploys a Node.js runtime as the base image, then attaches JavaScript or TypeScript function ROMs to instances of that runtime.

Prerequisites

1. Install the CLI. Use the unikraft CLI or the legacy kraft CLI. You need a BuildKit builder. The easiest way to get one is via Docker. You can also set up and use BuildKit directly; see the quick start.

   The unikraft CLI is the current standard, while kraft is the legacy version. Choose one of the CLIs below and only run the commands associated with it for the rest of this guide.

2. Clone the examples repository and cd into the examples/node-code-execution directory:

   Code
   git clone https://github.com/unikraft-cloud/examples
   cd examples/node-code-execution/

Make sure to log into Unikraft Cloud and pick a metro close to you. This guide uses fra (Frankfurt, 🇩🇪):

Step 1: Package and push the base runtime image

The base image contains a Node.js server (server.ts) that loads a function from the attached ROM and executes it on each HTTP request. Right before starting the server, it writes 1 to /uk/libukp/template_instance, which triggers Unikraft Cloud to convert the running instance into a template.

Step 2: Create a template from the base image

Boot a short-lived instance from the base image without any ROM attached. The instance self-converts into a template and exits:

The output shows the instance details:

This instance is short-lived, since right before the server starts, it triggers a conversion into a template. To confirm the template is ready:

Step 3: Package and push the function ROMs

ROMs package only the function source files—no runtime needed. Package both example functions:

Step 4: Create instances from the template with ROMs attached

Stamp out instances from the template, each with a different ROM. New instances skip the cold-start initialization phase because they restore from the template snapshot.

Create the first instance with the JavaScript ROM attached:

Create the second instance with the TypeScript ROM attached:

Both instances run the same base Node.js runtime but execute different function code—without any rebuild of the runtime image.

List the instances and note their FQDN values:

Test both instances using the FQDNs from the listing:

Code
curl https://sparkling-dawn-syowlbtj.fra.unikraft.app
curl https://nameless-wood-gw7pbnls.fra.unikraft.app

Code
Bye, World!
Auf Wiedersehen!

How it works

The ROM deployment model has three layers:

1. Base runtime image: A generic Node.js server that loads and executes code from a well-known path (/rom/rom.js or /rom/rom.ts). Push it once; it changes infrequently.

2. Function ROM: A read-only filesystem image containing only the function source file. Lightweight, fast to build and push. Attached to an instance at creation time and mounted at /rom.

3. Instance template: A pre-initialized snapshot of the runtime, created automatically when the base image boots without a ROM. New instances boot from this snapshot, skipping initialization and reducing cold-start latency to milliseconds.

Cleanup

Learn more

Use the --help option for detailed information on using Unikraft Cloud:

Or visit the CLI Reference or the legacy CLI reference.

For more on the ROM and template features:

• Instance templates
• ROMs
• node-code-execution example