Home

Push Node.js, Go or static source and get a URL. Your app starts on the first request and idles back to zero.

Xeonr Functions runs Node.js, Go and static sites without a Dockerfile. You give it source — from a repository, an uploaded archive, or the browser editor — and it gives you a URL. Container functions start when the first request arrives and idle back to zero when traffic stops; static sites never run a container at all.

Everything the console does is also in the public API. From TypeScript or CI, reach for the SDK and CLI rather than the protocol directly.

https://<name>.fns.xnr.app          production
https://<name>.stage.fns.xnr.app    stage

	Console	Function domain
Production	functions.xeonr.io	`fns.xnr.app`
Stage	functions.xeonr.dev	`stage.fns.xnr.app`

Guides

Quickstart

Create a function, edit it in the browser, and deploy it.

Runtimes

What Node.js, Go and static functions expect from your source tree.

Configuration

Build settings, environment variables, secrets and scaling.

Deployments

Versions, promotion, rollback and build logs.

Git integration

Connect GitHub or GitLab and deploy on every push.

Teams and access

Team ownership, roles, members and API tokens.

Observability

Traffic, latency, cold starts and build output.

SDK and CLI

@xeonr/functions — deploy from a script or from CI.

Using the API

Base URLs, authentication, error codes and the role each call requires.

API Reference

Functions

Functions, versions, deploys, workspace files and repository connections. Reachable with a team API token.

Teams

Teams, membership, API tokens and the activity feed. Requires a signed-in user; API tokens are refused here.

Hostnames are assigned, not chosen

Every function gets a generated hostname label — wandering-otter-4f2a — and you cannot pick it. All functions share one registrable domain and run untrusted code, so a chosen name would be a phishing primitive: whoever claimed login-xeonr would serve a convincing credential page on a hostname that looks official.

What you do choose is a display name. It has no uniqueness rules, nothing routes on it, and it is what the console shows everywhere.

Custom domains are not available yet. Until they are, the assigned hostname is the only way to reach a function.

How it works

Functions is a product built on top of container-platform. It owns source, versions, buildpacks, git integration, routing and the console. The platform owns image builds, instance lifecycle, cold start, isolation and durable storage.

git push / archive upload / console edit
        │
        ▼
   Functions api ──── workspace + snapshot ────► durable file storage
        │
        │           buildpack recipe ─────────► image build
        │
        │           one App per function ─────► instance lifecycle
        ▼
   *.fns.xnr.app
        │
   Functions edge ── static?    serve from storage, no pod, no cold start
        └────────── container? hold the request through the cold start, then proxy

Two ideas carry most of the behaviour you will notice:

A function is durable; a version is immutable. Every change produces a new version rather than mutating an existing one. That is what makes a rollback instant — promoting an older version rebuilds nothing — and what makes the deploy list a usable history.

Static functions never run a container. No image, no pod, no cold start: the edge serves files straight from an immutable snapshot. This is why environment variables, ports and system packages are refused on a static function rather than quietly stored.

What you never write

There are no Dockerfiles. Build recipes come from fixed per-language templates, and the only build input you control is a list of Debian package names — no version pins, no apt options, no shell. If your app needs ffmpeg, you declare ffmpeg; you do not get to run a command inside the shared builder.