1Backend: a self-hosted microservices and microfrontend platform with LLM containers

What 1Backend actually replaces in a small stack

Most teams building a distributed application start by assembling the same five pieces: an identity provider, a service registry, an API gateway, an email sender, and a way to run model inference. 1Backend ships all five as built-in services behind one Go server. The README describes it as a "framework, proxy, and runtime" that handles "auth, user accounts, microservice and microfrontend routing, email, and more", and the repository layout backs that up: server/ holds the daemon, sdk/ holds language clients, cli/ holds the oo command, and examples/go/services/ holds worked service examples.

The audience is narrower than the tagline suggests. This is for a team of a few engineers who want service-to-service calls, per-service credentials and frontend routing without writing a Helm chart. It is not aimed at platform teams who already run a service mesh, and it is not a drop-in for an existing Kubernetes cluster. The registry model assumes services register themselves at a URL, which is a lighter contract than a mesh sidecar but also gives you fewer traffic controls.

Service accounts, instance registration and the routing path

The mechanism has three moving parts. First, every service gets its own user account. The README is explicit that "Each service - just like humans - must have their account and manage their own credentials", and the Go SDK exposes boot.RegisterServiceAccount with an account slug, a display name and a credential store handle. Second, the service registers a reachable address through RegistrySvcAPI.RegisterInstance with a Url field. Third, the server proxies requests to that address under the service slug, so a service registered as your-svc is reachable at http://127.0.0.1:11337/your-svc/your-endpoint.

That is the whole data flow: register identity, register address, call through the proxy. The port 11337 appears in both the README curl example and the docker-compose.yaml port mapping, so it is the single entry point for API traffic. Microfrontends reuse the same idea but keyed on routes rather than slugs; the README shows oo route save --id=yourdomain.com --target=http://your-network-local-frontend-url, and states that automatic SSL is supported through the edge proxy mode documented under OB_EDGE_PROXY.

The design choice worth flagging is that routing is registry-driven and dynamic. Nothing in the README describes health checking, retry policy or circuit breaking for a registered instance. If a service registers a URL and then dies, the README does not say what the proxy does. That is a gap you would need to close at the service level.

Installing 1Backend with Docker Compose and calling a first endpoint

The README gives Docker as the easiest path and points at the repository root. The bundled docker-compose.yaml builds the current code rather than pulling a release image, and its own comment says that for production you should use the compose file under docs-source/docs/start/docker-compose.yaml instead. Run this from the repository root:

docker compose up

The compose file maps port 11337 to the host, mounts /var/run/docker.sock so the backend can start containers, mounts /etc/hostname as a read-only fallback node URL, and persists data in the named volume 1backend-data at /root/.1backend. It also carries a commented-out OB_GPU_PLATFORM=cuda line for NVIDIA GPU acceleration, which you would uncomment before bringing the stack up if you intend to run models on a GPU.

Next, install the CLI. The README notes that Go is currently required to install it:

go install github.com/1backend/1backend/cli/oo@latest

Then confirm the CLI can see the local environment and log in. The README shows oo env ls listing a local environment pointing at http://127.0.0.1:11337 with REACHABLE set to true, followed by oo login 1backend changeme and oo whoami returning a slug, a user id, an app id with host unnamed, and the roles user-svc:user and user-svc:admin. If oo env ls shows REACHABLE as false, the server is not up or the port mapping is wrong; check that first before debugging anything else.

Finally, once a service is registered, the call path is a plain curl against the slug:

curl http://127.0.0.1:11337/your-svc/your-endpoint

The examples/go/services/ directory is where the README sends you for a complete service rather than this conceptual outline.

Where 1Backend is the wrong tool

The most concrete limitation is stated by the project itself: the README says "We have temporarily discontinued the distribution of the desktop version", and directs readers to a page for alternative run methods. If your plan was to hand a desktop build to non-technical users, that plan does not survive contact with the current README.

The second limitation is version churn. The release history jumps from v0.7.0 (edge proxy) in June 2025 to v0.8.0, labelled "Pre apps overhaul release", in September 2025, then v0.9.0 ("Apps & multitenancy") in October 2025, while the README header advertises v0.9.2. An overhaul of the apps model between minor versions means anything you build against the apps or multitenancy API should be pinned and re-read at each bump. There is no long-term support line described.

The third is operational. The compose file mounts the Docker socket into the backend so it can start containers. That is a broad privilege, and it means the daemon's security boundary is effectively the host's. If you are not comfortable giving a web-facing service control of the Docker socket, this architecture is a poor match, and the README does not describe a socketless or remote-runner mode.

Finally, the README does not document rollback, migration paths between app model versions, or what happens to registered instances when the server restarts. It is silent on all three.

1Backend compared with a Kubernetes plus Istio stack

The nearest alternative approach is Kubernetes with a service mesh. There, you write manifests, the scheduler places pods, and the mesh handles mutual TLS, retries and traffic splitting. Service identity comes from the platform, not from an application-level account.

1Backend inverts that. Identity is application-level: a service registers its own account and password through boot.RegisterServiceAccount, then announces its address through RegisterInstance. There is no sidecar and no manifest. Deployment is a URL registration call. The trade is control for speed. You get a working service topology in minutes instead of a cluster and an ingress controller, but you also inherit the gaps: no documented health checking, no documented retry semantics, and no traffic-shifting primitives in the README. If you need canary releases with percentage splits, a mesh gives you that and 1Backend's documented surface does not.

The same contrast applies to microfrontends. 1Backend routes a domain to a frontend URL with oo route save and handles SSL through the edge proxy. A conventional setup would put that in an ingress resource plus cert-manager. Fewer components, fewer knobs.

Licence, maintenance and the cost of staying current

1Backend is licensed under AGPL-3.0, and the repository carries LICENSE, COPYRIGHT and AUTHORS files at the top level. For anyone running it as a network service, the AGPL's network clause is the part that matters: users interacting with the software over a network are entitled to the corresponding source. If your product embeds 1Backend and you do not want to publish your modifications under those terms, this licence is a blocker, and no amount of configuration changes that. This is a description of the licence, not legal advice; get your own counsel for a commercial distribution.

On maintenance, the last push to the default branch was on 2026-05-27. That is roughly four months before the date of writing, so the repository is not archived, but the cadence is not one you should assume will keep pace with your own release schedule. The README header advertises v0.9.2 while the most recent tagged release in the repository is v0.9.0 from 2025-10-12, which suggests unreleased work on main.

Upgrade cost is the practical concern. Because v0.8.0 was an apps overhaul and v0.9.0 changed apps and multitenancy, a major-version-style change landed inside a minor version number. Budget for reading the release notes and re-testing service registration and routing on every bump, and pin the CLI version you install rather than tracking @latest in CI.

Editorial conclusion

Adopt 1Backend if you are a small team that wants service registry, auth, routing and LLM containers from one self-hosted Go server and can tolerate a project whose last push was on 2026-05-27 and whose desktop build is discontinued. Do not adopt it if you need a frozen API contract, a large third-party integration ecosystem, or a permissive licence for a closed product. Before committing, verify three things yourself: whether the v0.9.0 apps and multitenancy model matches how you isolate tenants, whether the AGPL-3.0 network clause is acceptable for your distribution model, and whether the Go SDK surface in sdk/go is stable enough for the version you pin.

Frequently asked questions

Official sources

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