# StaticBackend core: a Go backend API for web and mobile apps

> StaticBackend is an MIT licensed Go backend server API that bundles authentication, user management, database CRUD with full-text search, websockets, file storage, server-side functions, scheduled jobs and caching into one multi-tenant service, and it can also be imported as a Go package so the same building blocks run inside your own binary. The judgement is that the Go package is the more interesting half, and that the project spent eighteen months archived before development restarted in January 2026.

**staticbackendhq/core** — Backend server API handling user mgmt, database, storage and real-time component

- Repository: https://github.com/staticbackendhq/core
- Website: https://staticbackend.dev
- Stars: 742 · Forks: 71
- Language: Go
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/staticbackendhq-core

## A backend offered as a product, with a gap in its history

StaticBackend is described as a simple backend server API that helps you create web applications, and it handles most of the building blocks you would otherwise need on the backend.

The feature list in the readme is a checklist of eleven items, and it reads like a product page rather than a library description. Authentication, account and user management, database CRUD with queries and full-text search, realtime over websockets, file storage, server-side functions, scheduled jobs, sending mail and SMS, caching, form handling, and resizing images and converting a URL to a PDF.

It is also a multi-tenant platform, so a single instance can host multiple isolated applications, which is the difference between this and a starter kit you fork.

The line in the readme that deserves attention is the note underneath the checklist: the project was archived in June 2024 and active development restarted in January 2026.

That is an unusual thing to publish and an important thing to know before you build on it. The release history matches the story. Version 1.5.0 is from June 2023, version 1.6.3 from February 2026 and version 1.7.0 from May 2026, so the three releases since the restart are the work of the current year, and the last push to the repository was on 2026-08-01.

## One command gives you a running backend with a key

The local development story is unusually short, because the CLI ships with a complete server.

The readme says the CLI includes a fully functional development server and that you do not need to install anything else. Installing it is a global npm install:

```sh
$ npm install -g @staticbackend/cli
```

That installs a program called backend, and the server command starts it:

```sh
$ backend server
```

The command creates a new application and an admin user for you, and you receive a PublicKey and a RootToken. The readme then explains the two roles of those values. All HTTP requests to the API require a public key, and the root token allows you to sign in to the dashboard for the application as its owner.

So the model is a public key that identifies the application, in the same way a key identifies a project, and a root token that is the owner credential for it. The public key is not a secret in the usual sense, since it travels with every request, and the root token is.

For a developer that is the whole onboarding: install the CLI, start the server, and you have a database, an account system and a dashboard to explore. The dashboard is where you create the first application in the first place, since the readme notes that you create your first application before you can start.

## Four ways in, and one of them is not a client at all

The install section is organised by how you intend to build, and the distinction it draws is the useful one.

The frontend client is a JavaScript library, and the readme shows the two lines that matter:

```javascript
import { Backend } from "@staticbackend/js";
const bkn = new Backend("dev_memory_pk", "dev");
```

The first argument is the public key and the second is the region, and the readme names the defaults for local development, dev_memory_pk as the public key and dev as the region or host. There is also a script tag option for people who are not using a module system, loading the same library from a CDN and reaching it through a global namespace.

The backend clients are pre-built libraries for Node, Go and Python, installed with npm, go get and pip respectively, and the readme notes that the Node client has the same API and function names as the JavaScript one, so a server-side and a browser-side call look the same.

The fourth option is different in kind. The Go package can be imported directly into a Go program, and the readme says you can build your application with the same building blocks without hosting the API separately. That is a fundamentally different deployment model, and the next section looks at what that package actually gives you.

## The Go package gives you generics, a cache and a pub/sub bus

The Go package example is the part of the readme that shows the project is more than a hosted service.

The collection API is generic. You declare a struct, pass the authenticated user, the tenant's database and the collection name, and you get back a typed handle:

```go
type Task struct {
    ID string `json:"id"`
    Title string `json:"title"`
}

tasks := backend.Collection[Task](auth, base, "tasks")
newTask, err := tasks.Create(Task{Title: "testing"})
```

The comments explain the three arguments. The auth is the currently authenticated user performing the action, the base is the current tenant's database to execute the action in, and the third is the collection name. The returned object has its unique ID filled in from the database.

Above that sits the cache and the publish path, which is where the real-time side comes from:

```go
backend.Cache.Set("key", "value")

msg := model.Command{Type: "chan_out", Channel: "#lobby", Data: "hello world"}
backend.Cache.Publish(msg)
```

A command with a channel and a payload, published through the cache, is how a message reaches a websocket client subscribed to that channel. So the same cache that stores values is also the transport for realtime events, which is a neat piece of economy.

The Go client library, which talks to a hosted instance over HTTP, is a different thing from this package, and the readme links documentation for both.

## The dependency list is a description of the feature set

The go.mod is long, and it reads as documentation of what the server actually does.

The search engine is Bleve, at version 2.6.0, which is what backs the full-text search feature rather than the database doing it. The server-side functions are run on a JavaScript VM, dop251/goja, which is how a deployment can run its own logic without a language runtime being installed. Converting a URL to a PDF is done with a headless browser, chromedp and its protocol package, which is the honest way to turn a web page into a document.

The rest of the list follows the checklist. go-co-op/gocron for the scheduled jobs, Redis through go-redis for the cache, MinIO through the Go client for object storage, Stripe for payments, the AWS SDK v2 with its SES service for email, markbates/goth for the OAuth providers, a JSON web token library for the tokens themselves, and the MongoDB driver plus a pure Go SQLite driver for the two other storage backends.

There is also a logging library, lumberjack, for rotating log files, and the image and crypto packages of the Go standard library extensions.

The upshot is that this is a service with opinions about its storage. Postgres is the primary database, with Redis for caching, Mongo for documents, SQLite for a single-file mode, and S3 compatible object storage for files.

## Four deployment paths, from a source checkout to a managed platform

The deployment section covers the ways you can get this running, and the spread tells you how the project expects to be used.

Running from the source is three commands:

```sh
$ git clone https://github.com/staticbackendhq/core
$ cd core
$ cp .local.env .env
$ make start
```

The environment file is copied from a template that ships in the repository, and after that you visit the local port and create an application, which the readme puts at 8099.

Docker is supported, and the repository carries four compose files rather than one: a general docker-compose.yml, one for Mongo, one for the unit tests and one for a demo setup. There is a Dockerfile at the root, and the environment templates are visible in the tree as well, with a .local.env for a local run, a .demo.env and separate files for the Postgres and Mongo test environments, which is a good sign for a project that runs its tests against real databases rather than mocks.

Then there are the platform as a service routes. Render is supported through a render.yaml, and Heroku through an app.json, both of which are the declarative files those platforms read.

The repository also carries a devcontainer configuration, a codespaces environment file, an AGENTS.md for coding assistants, a changelog, a code of conduct and a contributing guide. The build badge points at a Go workflow, and the Go Report Card badge and the pkg.go.dev reference for the backend package are both in the header.

## Conclusion

StaticBackend fits a team that wants a hosted backend for a web or mobile application without writing the boring parts, because the service covers accounts, the database, realtime, storage, jobs, mail and forms behind one key, and the same code is available as a Go package for a server that must run inside your own binary. It is the wrong choice if you want a stable, long-lived platform, because the project was archived in June 2024 and only restarted in January 2026, so the release history has an eighteen month hole in it. It is also the wrong choice if you need to pick your own database and your own deployment, since the defaults are Postgres with Redis, Bleve for search, Mongo for documents and S3 compatible storage. Before you adopt it, read the archive note rather than the version number, and decide early whether you want the hosted API or the embedded package, because that choice changes how you deploy everything.

## FAQ

### What is StaticBackend?

It is an MIT licensed Go backend server API that handles most of the building blocks of a web application, including authentication, user management, database CRUD with full-text search, realtime over websockets, file storage, server-side functions, scheduled jobs, mail and SMS, caching and form handling. It is a multi-tenant platform, so one instance can host several isolated applications.

### How do I run StaticBackend locally?

Install the CLI with npm install -g @staticbackend/cli and run backend server. The command creates a new application and an admin user and prints a PublicKey and a RootToken, the public key being required on every API request and the root token letting you sign in to the dashboard as the owner.

### What is the difference between the StaticBackend clients and the Go package?

The clients, for JavaScript, Node, Go and Python, talk to a running instance over HTTP. The Go package, imported with go get github.com/staticbackendhq/core/backend, gives you the same building blocks inside your own binary, so you can build the application without hosting the API separately, with a generic Collection type for typed CRUD and a cache that also carries pub/sub messages.

### Is StaticBackend actively maintained?

The readme notes that the project was archived in June 2024 and active development restarted in January 2026. The releases since then are 1.6.3 on 2026-02-13 and 1.7.0 on 2026-05-16, with the last push to the repository on 2026-08-01.

## Sources

- [License: MIT](https://github.com/staticbackendhq/core/blob/main/LICENSE)
- [Project website](https://staticbackend.dev)
- [README](https://github.com/staticbackendhq/core/blob/main/README.md)
- [Releases](https://github.com/staticbackendhq/core/releases)
- [staticbackendhq/core on GitHub](https://github.com/staticbackendhq/core)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/staticbackendhq-core