labring/laf: a self-hostable cloud development platform for cloud functions, database and storage

What laf actually replaces

Laf is a cloud development platform: a single product that hands you cloud functions, a cloud database, cloud storage, a WebIDE, website hosting and WebSocket support. The README lists those six capabilities directly. The problem it addresses is the setup work that sits between an idea and a running backend, and the target reader is named in the README's own audience section: frontend developers who want to write backend code without changing language, backend developers who are tired of provisioning databases and configuring nginx for every project, and teams currently locked into a closed cloud development vendor.

That last group is the interesting one. The README argues that with an open source platform you can deliver source code to a client and let them run the whole stack themselves, which a closed backend-as-a-service cannot offer. Whether that argument matters to you depends on whether you sell software or operate it. If you operate it, laf is mostly a convenience layer. If you hand software over, it changes what you can promise.

The pieces: functions, database, storage, WebIDE

The repository is a monorepo. Lerna coordinates the build across packages, and the top level separates server, services, web, cli, runtimes, deploy, docs and e2e. The runtime side is TypeScript: the root package.json declares typescript 5.0.4 as a dev dependency and the project's primary language is TypeScript. Cloud functions are written in JavaScript or TypeScript, which is what makes the frontend-to-fullstack pitch coherent: the same language on both sides of the call.

The client story runs through laf-client-sdk, which the README says works in any JavaScript runtime. The README also states that SDKs for other clients such as Flutter, Android and iOS are planned rather than shipped, so treat the JavaScript path as the one that exists today. On the infrastructure side the topics list names Kubernetes, MinIO and MongoDB, which tells you what a self-hosted install is actually composed of: a Kubernetes cluster, an S3-compatible object store, and MongoDB behind the database feature. The WebIDE is the part that gives the project its slogan about writing functions like writing a blog post: you edit and publish from the browser, and the README says you can read function logs on the web without connecting to a server.

Installing laf and publishing a first function

The README does not give a copy-paste install sequence. It points at two things instead: a hosted experience at sealos.run, and a Deployment document under deploy/README.md for running it yourself. The README is explicit about what local deployment requires: you configure your own domain, certificates and gateway, and you need to be comfortable with Kubernetes operations. So the honest first step is not a command, it is a decision about which path you are on.

The repository layout shows a cli/ directory alongside server/ and services/, and the root package.json exposes Lerna-based scripts for building the monorepo. If you are building from source rather than pulling images, the documented entry points are these scripts.

npm run install
npm run build

The install script runs lerna exec npm install --parallel across packages, and build runs lerna run build --parallel. Both are parallel across the monorepo, so expect them to be heavy on CPU and disk. A lint script exists as well if you want to check a change before building.

Once a server is reachable, the documented workflow is browser-based rather than command-line: you create a function in the WebIDE, write it in JavaScript or TypeScript, publish it, and read its logs from the web interface. The README's quick-start links describe building a small Todo List and a ChatGPT-style app this way. For the frontend side, the SDK path is laf-client-sdk, which the README says is usable from any JavaScript runtime.

Where self-hosting laf gets expensive

The README's own deployment note is the strongest limitation here: local deployment means configuring a domain, certificates and a gateway, and being familiar with Kubernetes operations. That is not a footnote. A frontend developer who picks laf precisely to avoid server work has, in the self-hosted case, taken on cluster work instead. The hosted option at sealos.run sidesteps this, but then you are back to depending on somebody else's operation of the platform, which weakens the vendor-lock-in argument that motivates the self-hosted path in the first place.

There is a second, quieter issue: versioning. The newest release listed is v1.0.0-beta.14, published on 2023-12-19, and the two before it are also beta. The root package.json reports version 1.0.0-beta.4. Anyone planning a production deployment should assume they are tracking a beta line and decide in advance how they will pin and upgrade it, because the README does not describe a stable channel. The README also does not document rollback, backup or restore procedures for the database and storage layers.

Finally, laf is the wrong tool if your workload is not request-shaped. It is a functions, database and storage platform with WebSocket support; if you need long-running processes, custom kernel-level networking, or a language runtime outside the JavaScript and TypeScript family the project ships, the platform's model works against you rather than for you.

laf against Supabase and Firebase

The repository's own keywords place laf next to firebase, supabase, appwrite and cloudbase, so the comparison is fair game. Firebase is a managed Google service: you consume it, you do not run it, and its database is a document store with its own query model and client libraries. Supabase pairs a Postgres database with generated APIs, auth and storage, and is open source and self-hostable, but its centre of gravity is the relational database and the SQL you write against it.

Laf's centre of gravity is the function. The README's framing is that you write functions the way you write blog posts, publish them from a WebIDE, and read their logs in the browser. The database and storage are resources the functions use, not the thing you design around first. That difference matters in practice: if your product is mostly queries over relational data with row-level rules, Supabase's model fits more directly. If your product is mostly small pieces of server logic that a frontend calls, laf's model removes more ceremony. Both are open source, but laf's licence is specifically Apache-2.0, which is worth checking against your own distribution plans.

Maintenance, licence and the upgrade bill

The repository is not archived, and the last push was on 2026-07-30, which is recent enough that the codebase is moving. That said, movement in the repository and movement in releases are different signals: the newest release listed is v1.0.0-beta.14 from 2023-12-19, so the tagged, downloadable artifacts are considerably older than the last commit. If you deploy from tags, plan around that gap.

The licence is Apache-2.0. That generally permits commercial use and modification and requires that you preserve licence and notice information, but it is not legal advice and the terms that matter to you depend on how you distribute. The README's pitch about delivering source to a customer is exactly the scenario where you should read the LICENSE file and the notices your build produces rather than assume.

Upgrade cost is dominated by the Kubernetes layer, not by laf itself. Because deployment expects you to own the domain, certificates and gateway, a laf upgrade is coupled to your cluster's ingress and certificate lifecycle. Budget for that, and note that the README does not describe a migration path between laf versions or a supported rollback.

Editorial conclusion

Adopt laf if your team writes JavaScript or TypeScript and wants a backend platform it can deploy on its own infrastructure, or if you need to hand a customer runnable source instead of a hosted service. Do not adopt it if nobody on the team operates Kubernetes, or if you need a stable tagged release rather than a beta line. Before committing, read deploy/README.md to confirm the Kubernetes, domain, certificate and gateway work it expects, check whether the laf-client-sdk covers your runtime, and decide how you would pin a version given that the newest release listed is v1.0.0-beta.14 from 2023-12-19.

Frequently asked questions

Official sources

1. labring/laf on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases