Backend functions
Server-side code for work that must not happen in the browser: what a function is, when you need one, who may call it, secrets and outbound calls, testing, enabling and running as the app.
Last updated September 17, 2026
On this page
Most of an app runs in the visitor's browser, which is simple, fast and free. Some work must not: calling another service with your own key, a job that runs at night, a step a visitor must never be able to see or tamper with. That work runs as a backend function, a small piece of JavaScript executed on the server in an isolated runtime.
When you need one
- Talking to an outside service with a key you hold: a payment provider, a mapping service, a mailing tool.
- Anything that runs on a schedule or when data changes. See Automations.
- Receiving a webhook from another company. See Receiving webhooks.
- Work across many rows that a visitor should not drive from their browser.
You rarely ask for a function by name. You describe the feature (take card payments, email me a summary every night) and the builder decides it needs one, writes it, tests it and switches it on.
How a function is shaped
A function receives an event (whatever the caller sent) and a ctx with everything it may reach: your app's tables, email, AI, stored secrets, outbound web requests and a log. Whatever it returns goes back to the caller.
// Body of an async function: `event` and `ctx` are already in scope.
const key = ctx.secrets.get("POSTCODE_API_KEY");
const res = await ctx.fetch("https://api.example.com/lookup?code=" + encodeURIComponent(event.postcode),
{ headers: { Authorization: "Bearer " + key } });
const data = await res.json();
ctx.log("looked up", event.postcode);
return { valid: data.ok, area: data.area };A page calls it with fn.invoke("check_postcode", { postcode }). The full surface is in the backend function reference.
Who may call it
| Visibility | Who can call the function |
|---|---|
| Public | Anyone, including signed-out visitors. For a marketing-page lookup, a sign-up step, a webhook. |
| Users | Signed-in users of your app. The default. |
| Admin | Signed-in admins only. |
| Internal | Nobody from outside. Only automations and other functions. |
Allowlists
A function declares which outside hosts it may call and which stored secrets it may read. The runtime refuses anything not on the list, so a function only ever reaches what it was written to reach.
Secrets
A secret stored under Secrets can be read by a function with ctx.secrets.get("NAME") and by nothing else. Page code cannot reach it. That is why a feature that needs your key is always a function plus a page that calls it. See Secrets.
Testing, enabling, running as the app
- Testing: the builder runs a function with a test event and reads back the result, its log lines and how long it took, before it relies on it.
- Enabling: a new function starts switched off and the builder switches it on once it works. A call to a function that is off is refused.
- Running as the app: an automation has no signed-in caller. A function that must read or write rows no visitor could is granted the app's own identity, which the builder does for a function it wrote and tested. Your dashboard shows which functions run as the app.
Runs and logs
Every run is recorded with its status, duration, log lines and result. See them under Automations for scheduled runs, and under Logs for calls from pages and the API.
What a run costs
Running a function is not itself charged. A run costs only the platform services it asks for, such as the emails it sends or the AI it calls, in the same credits those cost anywhere else.