Skip to content
Stackship documentation Svenska

FunctionsUsers

Functions

Run small pieces of code on an HTTP request or on a schedule, grouped in function namespaces that give them a hostname, shared settings and one identity.

A function is a small piece of code that the platform runs when an HTTP request arrives or on a schedule. You write the handler; the platform builds it into a container image, runs it and routes requests to it. A function can sleep while nothing calls it; see Scale to zero for when it does.

Namespaces and functions

  • A function namespace is a resource in a resource group. It gives its functions one hostname, <namespace>.fn.apps.example.com, environment variables they all receive, and one managed identity they all share.
  • A function belongs to exactly one namespace. It has a runtime, a trigger, its code, and settings of its own: environment variables, secret references and authentication.
  • Function names are unique within the resource group, not only within the namespace: two namespaces in the same resource group cannot both have a function called hello.

Triggers

Trigger When the function runs
HTTP When a request arrives at https://<namespace host>/<route>. The portal gives each function the route /<function name>. See Function handler reference.
Timer On a five-field cron schedule, evaluated in UTC. A timer function has no public address. See Timer triggers.

A third trigger type, Queue, exists in the API model, but creating a queue function, or changing a function to one, is refused: nothing delivers queue messages to functions yet.

Runtimes

The portal offers Node.js / TypeScript, .NET and Go; there is no version to choose.

  • Node.js functions run on Node.js 22. The code you write in the portal is saved as one JavaScript file, handler.js, and loaded as an ES module.
  • .NET and Go functions cannot be built from the portal today. The portal saves the code as a single file without the project file the build needs (.csproj or go.mod), so the build fails. Use Node.js.

Where the code comes from

Source How the code gets in
Portal You write the code in the function's Code tab and choose Deploy. The platform builds an image and deploys it. See Create and manage functions.
External With the CLI or the API you point the function at a container image built elsewhere, for example by your own pipeline. See Run an image from your own pipeline.

Building a function from a Git repository is not available: the portal does not offer it and the API has no field for a repository. Functions do not use the boundary's deployment sources.

How a request reaches a function

Every function namespace runs a small proxy of its own, fnproxy-<namespace>. The namespace's hostname points at it, and for each request it:

  1. picks the HTTP function whose route matches the path — the route itself or a path below it, the longest matching route first;
  2. answers 405 Method Not Allowed when the function does not accept the method;
  3. checks the caller's token when the function has authentication on — see Protect a function with a token;
  4. wakes the function if it has scaled to zero, and waits up to 30 seconds for it to start;
  5. forwards the request, with its path and query unchanged.

The same proxy runs the timer schedules and stops idle functions — see Scaling and resources.

Important

Each namespace's proxy works on every function in the resource group, not only on the functions of its own namespace. With more than one function namespace in a resource group:

  • a function of one namespace can also be called on the hostname of every other function namespace in the resource group, and the 404 answer lists the routes of all of them;
  • routes are checked for conflicts only within a namespace. A function of another namespace whose route is longer, for example /hello/admin next to /hello, takes over the paths below it on every hostname, and receives what callers send there, Authorization headers included;
  • every proxy runs every timer schedule, so a timer function runs once per function namespace in the resource group at each scheduled time;
  • every proxy stops functions it has not seen called for their cooldown, so a function can be stopped while it is being called through another namespace's hostname.

Keep function namespaces that must stay apart, and timer functions, in separate resource groups.

Caution

The proxy also answers on /_api/functions, a management interface without any token check. It lists the resource group's functions with their routes and internal addresses, and it can stop and restart them and change the replica counts the proxy keeps in memory. A function stopped there answers 503 {"error": "Function '<name>' is stopped."} on that proxy, and its timer does not run, until it is restarted there, the function's resource changes, or the proxy restarts. For a function built from the portal the resource changes about once a minute, so such a stop lasts about a minute. Workloads in every resource group of the boundary can reach the proxy inside the cluster. On platforms whose ingress is Traefik, /_api is not routed from the namespace's hostname; on other platforms it can be reached from the internet at https://<namespace host>/_api/functions.

What the functions of a namespace share

  • Environment variables set on the namespace reach every function in it; a function's own variable with the same name wins.
  • The managed identity belongs to the namespace. Every function in it runs as that identity, so a role you give the identity is available to all of them — see Secrets and the managed identity.

Pages