FaaSBox
GitHub

Self-hosted · Open source

Lambda without the complexityA lightweight Function-as-a-Service platform
for TypeScript. Zero dependencies.

Write your functions in the browser, then call them over HTTP or put them on a cron schedule. Deploys as a single Docker container: one Go binary, one SQLite file, nothing else to install.

Run it in one command Read the source

MIT licensed · Go · Bun · SQLite

The FaaSBox editor: the function list, the five tabs of a function, its code, and the runner showing a successful run The FaaSBox editor: the function list, the five tabs of a function, its code, and the runner showing a successful run

How it works

Three steps, and it runs.

  1. 1

    Write, install and test in the browser

    • The code. Your function reads JSON on stdin and writes JSON on stdout. No framework, no handler signature to memorise, nothing to import.

      The script tab of a function, with its code The script tab of a function, with its code

    • package.json — optional. List your npm packages and save; the install runs on the server and you watch it from the tab — installing, then ready, or the tail of the failure if npm had something to say. There is nothing else to set up.

      The package.json tab of a function, listing an npm dependency and showing its install state The package.json tab of a function, listing an npm dependency and showing its install state

    • Run — one click executes the function and shows you its result, its output and its duration, without leaving the tab.

      The runner toolbar and its Run button The runner toolbar and its Run button

    • Files — the other tabs show what the database holds; this one shows what the machine has. The folder as it is on disk: your files, the lockfile, and the node_modules the install produced. Read-only, and the place to look when a version is not the one you expected.

      The Files tab of a function, listing its folder on disk The Files tab of a function, listing its folder on disk
  2. 2

    Give it a trigger

    Two ways to start a run, and a function can carry both at once.

    • An HTTP call. POST /invoke/{name} with an API key, created on the API keys page. The request body becomes the function's stdin, and the response carries its result and duration.

      The API keys page, with the form that creates a key and sets its scope The API keys page, with the form that creates a key and sets its scope

    • A cron schedule. Added in the Triggers tab: fifteen ready-made expressions, a free field, and a cap on concurrent runs. Changes take effect immediately — nothing restarts.

      The Triggers tab of a function, showing a schedule and its payload The Triggers tab of a function, showing a schedule and its payload
  3. 3

    Read the log

    Every run records its trigger, status, duration, stdout, stderr, request payload and exit code. Including the runs that never happened: a schedule that came due while the server was down is logged as missed, with the count and the window.

Storage

The database is a single file.

SQLite. Functions, schedules, secrets, keys and logs all live in it. No database server to provision, and backing up the instance means copying one file.

Container
data.db your whole instance

replaced on every deploy

Litestream · optional

every write, as it happens restored before start-up
S3 bucket
data.db the same file, kept in sync

outlives the container

Two reasons to turn it on

The disk underneath is not permanent. A container is replaced on every deploy and takes its filesystem with it. Litestream puts the file back before the server starts, so the container stays disposable and your data doesn't.

Or simply as a backup. Even on a server whose disk does survive, the same mirror is an off-site copy that is always current — no dump to schedule, no window during which the last hour is missing.

Leave it off and nothing else changes: FaaSBox runs from the local file alone, which is what you want on your own machine.

Your dependencies come back on their own, either way. node_modules is not in the file — it is a build artifact, and a heavy one. What is stored is the lockfile, so a fresh container reinstalls exactly the versions the old one ran, before the first call arrives rather than during it.

In the box

Everything you need, nothing you have to wire up.

An editor, not a pipeline

Five tabs per function: script, package.json, triggers, secrets, and the files its folder holds on disk. Run executes what the server holds; Save and run appears only when your screen differs from it.

Two triggers, one engine

An HTTP call and a cron tick take the same path: one Bun subprocess, the same environment, the same ceilings, the same log line. What differs is what happens when the box is busy — HTTP refuses with 429, a cron run waits its turn.

Secrets encrypted at rest

AES-256-GCM. Edit them as key/value pairs in the Environment tab, masked until you reveal them, and they land in the subprocess environment. Saving replaces the whole set — which is why you can see it.

Keys you can scope

Hashed on creation, revealed once, optionally restricted to named functions and given an expiry date. An expiry the server can't read is refused at creation rather than quietly dropped.

Logs that answer questions

Trigger, status, duration, both streams, request payload, exit code, and a flag when something was truncated to fit. Retention is by row count, purged hourly.

Bounded by design

Nothing runs unbounded: 30 seconds per run, 1 MB per request body, 1 MB captured per output stream, four concurrent runs. The sizes and the concurrency are defaults you change with an environment variable; the two timeouts are fixed.

By design

Small enough to hold in your head.

Every decision below takes a moving part out. What is left behaves the same way every time, and you can reason about all of it at once.

  • One boundary to secure. A single superuser administers the instance. No permission matrix to audit, no role that quietly grants more than you meant.
  • Runs are atomic. A call returns a complete result or an error. Nothing to reassemble on the client, no half-written response to detect.
  • Functions stay independent. Each one is written, invoked and tested on its own. When something breaks there is no hidden call graph to unwind first.
  • Nothing fires twice behind your back. A schedule missed during downtime is reported, never replayed — the distinction matters when the function bills a customer or sends mail.
  • One moving part. No control plane, no registry, no broker, no VPC, no serverless.yml. The platform is the container you started, and that is the whole of it.

Get started

One container, one command.

docker 
docker run -d -p 8080:8080 \
  -e SUPERUSER_EMAIL=admin@example.com \
  -e SUPERUSER_PASSWORD='…' \
  -e FAASBOX_ENCRYPTION_KEY=$(openssl rand -hex 32) \
  -v faasbox-data:/app/data/pb_data \
  ghcr.io/antoineviau/faasbox:latest

Then

localhost:8080/ — the editor. Sign in with the address and password from the command above; the account is created on first boot.

localhost:8080/_/ — the PocketBase admin underneath, if you ever want the raw collections.

Working on it locally

Go 1.24+, Bun and Node.js, then bash infra/dev/dev.sh builds the editor and starts the server.

GitHub Getting started