1Backend: a self-hosted microservices platform that registers services as user accounts

The problem 1Backend targets: infrastructure before the first feature

The pitch in the README is about ordering. 1Backend "lets you build distributed applications fast, without early infrastructure overhead." The overhead it means is concrete: user accounts and auth, a service registry, request routing between services, email, and frontend hosting. Each of those is normally a separate component to choose, deploy and wire together before any product code runs. 1Backend puts them in one server. The intended user is a small team building a distributed application, or an AI application that needs to run and program LLMs inside containers, which the README lists as a capability. The README also mentions an ORM "for development even without a database," which is aimed at the same early stage: get something running, attach a database later. The project describes itself as "a distributed operating system for your applications," and the topics list adds on-premise and self-hosted, so the audience is people who intend to run this on their own hardware rather than consume it as a managed service.

How a service gets on the network: account first, then instance registration

The mechanism is unusual and worth stating plainly. A service is treated like a person. The README says "Each service - just like humans - must have their account and manage their own credentials," and then adds the joke that they must remember their passwords. In the Go SDK, boot.RegisterServiceAccount takes a client, an account slug such as "your-svc", a display name, and a credential store, and returns a token. So the identity layer is the same one used for human users, and a service holds a credential the way a user does. Registration is separate from identity. After the account exists, the service calls RegisterInstance with a Url field pointing at where it actually listens. That two-step split means the account can outlive a particular process or address, which is what you want if instances move. Routing is then by slug: the README shows curl http://127.0.0.1:11337/your-svc/your-endpoint, so the server is both the entry point and the dispatcher. The same registration model extends to frontends. The README states that React, Vue or Angular apps can be deployed as microfrontends and that 1Backend routes requests to them based on routes, with the example command oo route save --id=yourdomain.com --target=http://your-network-local-frontend-url. One registry, two kinds of target.

Getting a server and a CLI running

The documented path is Docker. From the repository root, docker compose up. The README points to a docs page for other launch methods and does not enumerate them. The CLI is installed with Go: go install github.com/1backend/1backend/cli/oo@latest. The README notes that Go is currently required to install it. From there the commands shown are oo env ls, which prints a table with columns ENV NAME, SELECTED, URL, DESCRIPTION and REACHABLE, and oo login 1backend changeme, which is the default-looking credential pair in the example and should not be treated as a production setting. oo whoami returns a slug, a user id, an app block with id and host, and a roles list containing entries like user-svc:user and user-svc:admin. The app block in that output is a reminder that the v0.9.0 release was titled "Apps & multitenancy," and the README's overview says the platform is multitenant, hosting multiple apps or sites on one install. SSL is described as automatic and tied to the edge proxy mode, configured through an environment variable documented as OB_EDGE_PROXY. The README links to that variable's page rather than inlining its accepted values, so the exact setting must be read there.

What the README does not tell you about the registry

The registry is the load-bearing piece, and the documentation here is thin. RegisterInstance is shown with a single Url field, and nothing in the supplied material describes how the registry stores that record, whether it performs health checks, how a stale instance is removed, or what happens when two instances claim the same slug. For a component that sits in the request path of every call, that is a real gap. The proxy is similarly underspecified: the README says routing happens by slug and by saved route, but not how a route and a slug interact when both could match, nor what the failure response looks like when a registered instance is unreachable. The oo env ls output shows a REACHABLE column, which suggests the CLI can probe an environment, but that is a client-side check of the server, not evidence that the registry tracks instance liveness. Anyone evaluating this should read the API docs for RegisterInstance rather than infer behaviour from the SDK snippet, because the snippet only shows the write side.

Pre-1.0 release cadence and what it costs you

The version history is the clearest signal about maintenance cost. v0.7.0 was titled "Edge proxy," v0.8.0 was "Pre apps overhaul release," and v0.9.0 was "Apps & multitenancy." Two consecutive releases changed the application model. The README header itself says v0.9.2 while the most recent tagged release listed is v0.9.0, which means the documented version is ahead of the last release, so a reader following the README is partly reading unreleased behaviour. For an adopter this translates into upgrade work: if the apps concept moved between v0.8.0 and v0.9.0, anything you build on apps should expect to move again before 1.0. The CLI compounds this, since it is installed from @latest and therefore tracks the tip rather than a pinned version. There is no LTS branch or compatibility statement in the material provided. The desktop distribution is also gone: the README states that the desktop version has been "temporarily discontinued," which removes the lowest-friction way to try the platform on a laptop and pushes evaluation toward Docker or a server.

Licence: AGPL-3.0 and what it implies for a self-hosted platform

1Backend is AGPL-3.0. The distinguishing feature of that licence, compared with permissive ones, is the network clause: offering the software to users over a network is treated as distribution for the purposes of source disclosure. That matters more than usual here, because the whole point of 1Backend is to run it as a server that other people reach. A team that modifies the platform and exposes it to external users should assume the licence reaches that modified version, and should get their own legal reading rather than rely on this summary. The SDKs and CLI published from the same repository are covered by the same licence unless stated otherwise, and the supplied material does not carve out exceptions. If your organisation has a policy against AGPL in the request path, that policy will block this project regardless of its technical merits, and it is worth checking before spending time on evaluation.

Where a plain reverse proxy plus a service mesh already covers you

The honest alternative for a team that already runs Kubernetes is the combination of an ingress controller and a service mesh. The difference is in where identity lives. In that stack, a service is identified by a workload identity issued by the cluster, and routing is expressed as ingress rules and mesh policies; the platform does not ask each service to create a user account and store a credential. 1Backend inverts that: identity is an account in the user service, and it is created by the service itself at boot through boot.RegisterServiceAccount. That is simpler if you have no cluster and no identity provider, and it is redundant if you already have both. The other real difference is scope. An ingress plus mesh gives you routing and mTLS and stops there. 1Backend also carries the user-facing account model, email, microfrontend hosting and the ORM, which is why the README calls it a framework, a proxy and a runtime rather than a proxy alone. If you only need the routing half, the cluster-native route is the lower-commitment choice and does not put an AGPL server in front of your traffic.

Editorial conclusion

1Backend suits a small team that wants service accounts, a registry, routing and microfrontend hosting from one self-hosted install, and is comfortable with AGPL-3.0. It does not suit anyone who needs a stable API surface today: the project is pre-1.0, and the v0.8.0 to v0.9.0 releases were an apps overhaul and a multitenancy change. Before adopting, read the RegisterInstance endpoint docs and the OB_EDGE_PROXY environment variable page, and confirm which registry the running daemon actually uses, since the README does not say.

Official sources

1. 1backend/1backend on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases