# Nubase: an AI-native backend that gives coding agents a real target

> Nubase bundles Postgres, Auth, Storage, Functions, Assets, Memory and cron into one self-hostable Java service that agents drive over MCP. It is built for people whose agents keep producing demos that never reach production.

**OtterMind/Nubase** — 🔥🔥🔥 Turn AI-written code into real apps. Nubase is an open-source, AI-native backend platform for AI Coding, agentic applications, and modern product teams: Memory, Database, Storage, and Auth in one self-hostable service.

- Repository: https://github.com/OtterMind/Nubase
- Website: https://nubase.ai
- Stars: 623 · Forks: 74
- Language: Java
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/ottermind-nubase

## The gap Nubase is aimed at

An agent can write a working frontend and a plausible schema in one session. What it cannot do, unless something gives it the credentials and the API surface, is create the database, wire authentication, store files, publish the frontend to a URL, and schedule the recurring job. That last mile is where generated code usually stops being an app.

Nubase's stated target is exactly that gap. The README frames the problem as: "Without that backend layer, every AI coding session produces another demo that still needs weeks of infrastructure work." The intended user is a product team or solo builder running a coding agent who wants the agent to finish the deployment, not just the source tree.

There is a second audience. The README says Supabase's open-source self-hosted stack is designed around a single project, and positions Nubase for self-hosters who want "one Studio, one backend service, and many isolated AI projects" on their own hardware. Those are two different buyers, and the project serves both with the same binary.

## Eight modules, one port, one Postgres per project

The architecture is a single Java service that owns the control plane and routes to per-project databases. The README lists eight modules: Database, Auth, Storage, Assets, Functions, AI Gateway, Memory and cron.

The Database module gives each project its own isolated PostgreSQL instance and exposes a PostgREST-compatible `/rest/v1` API supporting select, filter, order, paginate, insert, update, upsert and delete. Each project carries its own JWT secret, roles and schema cache, and Row Level Security is enforced against JWT claims. Auth follows the Supabase shape: signup and login, refresh-token rotation, MFA/TOTP, OTP and magic links, anonymous sign-in, OAuth through Google, GitHub or WeChat, SAML SSO, and per-project `anon`, `authenticated` and `service_role` tokens.

Storage is S3-compatible (Cloudflare R2, AWS S3 or MinIO) with public and private buckets, signed URLs, and size and MIME controls, plus optional S3 Vectors for large document workloads. Assets is a static CDN: per-project public files served under `/assets/v1/**` with Cache-Control, ETag and 304 semantics, a per-project default cache policy and a custom CDN domain option.

The interesting design choice is Memory. The README calls it "a first-class primitive": durable memory, entity extraction, history and hybrid retrieval are built into the service rather than left to a separate vector-store script. That is the module that distinguishes Nubase from a generic Postgres-plus-REST stack, and it is the one the repository topics echo with pgvector and rag.

The build itself is conventional. The Dockerfile is a two-stage Maven build on `maven:3.9-eclipse-temurin-17`, producing a JAR that runs on `eclipse-temurin:17-jre-alpine` as a non-root user, exposing port 9999 with a health check against `/health`.

## Installing Nubase and getting an agent to use it

There are two installs: the server, and the agent wiring. The server is one Docker command. The README's all-in-one image bundles PostgreSQL, Redis, the backend and Studio.

```bash
docker run -d --name nubase \
  -p 9999:9999 -p 5432:5432 \
  -v nubase_data:/data \
  <your-namespace>/nubase:latest
```

Replace `<your-namespace>` with the Docker Hub namespace the image is published under, as the README instructs. After it starts, Studio is at http://localhost:9999/studio and the API is on the same port, since the Studio UI is bundled into the backend. In Studio you create an account, create a project, and click Provision to initialize that project's database.

For anything beyond a trial, the README gives a second form that pins the secrets so encrypted project credentials survive a restart:

```bash
docker run -d --name nubase -p 9999:9999 -p 5432:5432 \
  -v nubase_data:/data \
  -e PGRST_ENCRYPTION_MASTER_KEY="$(openssl rand -base64 32)" \
  -e METADATA_SERVICE_ROLE_KEY="$(openssl rand -base64 48)" \
  <your-namespace>/nubase:latest
```

The README notes the image is multi-architecture, `amd64` plus `arm64`, and that everything else (Postgres, Redis, S3/R2 storage, SMTP, OAuth, LLM providers) is set through environment variables documented in `docs/docker-all-in-one.md`.

Agent wiring is one command from your project folder:

```bash
npx -y nubase_cli@latest install-skills
```

According to the README, that installs the Nubase skills for both Claude Code and Codex, writes the MCP server config, and opens a browser to authorize and pick a project. In Claude Code you then restart, run `/mcp`, and confirm `nubase` is connected; Codex picks it up from `~/.codex/config.toml`. To point at a non-default instance:

```bash
npx -y nubase_cli@latest install-skills \
  --studio-url https://studio.example.com \
  --nubase-url https://api.example.com
```

The README's own first exercise is worth copying because it exercises four modules at once: ask the agent to create a `todos` table with RLS, deploy an edge function that returns the open count, publish a one-page UI to Assets that calls it, and remember the deployment. If the agent completes that without you touching a dashboard, the integration is working.

## Where Nubase is the wrong tool

The self-hosting story is one container, which is also the deployment model. The README describes an all-in-one image bundling PostgreSQL, Redis, the backend and Studio, and a production variant that differs only by pinning two environment variables. There is no documented path for running the backend against an external managed Postgres, splitting Studio from the API, or scaling the backend horizontally. If your infrastructure standards require a managed database, a separate control plane, or independent scaling of the API tier, this design is a mismatch, and the README does not describe how to work around it.

The project is also young. The releases list stops at v0.1.4, published on 2026-06-16, and the last push to the repository was on 2026-08-18. That is a pre-1.0 version number with a short release history. Nothing in the README describes a migration path between versions, a compatibility policy, or how a project database provisioned by v0.1.2 behaves after an upgrade. Anyone running this for real data should assume they are testing that question themselves.

One more boundary: the README's own comparison is against Supabase, and it concedes Supabase is "excellent". If you are not using a coding agent as part of your build loop, the MCP surface and the Memory primitive are capabilities you are paying for without using, and a plain Supabase deployment is the more conservative choice.

## Nubase against Supabase, and why the difference is project count

The obvious alternative is Supabase, and the README names it directly. The claimed difference is not features. It is tenancy.

The README states that Supabase's open-source self-hosted stack is designed around a single project, while Nubase is built for "one Studio, one backend service, and many isolated AI projects" on your own infrastructure. In practice that means a control plane that provisions and routes to multiple isolated project databases, each with its own JWT secret, roles and schema cache. If you self-host Supabase and want ten projects, you are running ten stacks or accepting shared state. Nubase's answer is one stack, many databases.

The second difference is Memory. In Supabase, retrieval is something you assemble: a vector extension, an embedding pipeline, a table, and a query. Nubase ships durable memory, entity extraction, history and hybrid retrieval as a module with its own API surface. Whether that is better depends on whether you want the retrieval design decided for you. It is a real trade-off, not a free win: a built-in memory module is harder to replace than a table you wrote.

The third difference is the agent surface. Nubase's README describes agents creating tables, calling REST APIs, writing memory, deploying functions, publishing to the CDN and scheduling cron through MCP tools, with no separate hosting account. Supabase has an MCP server of its own, but the README's framing is that Nubase was designed around the agent as the primary client rather than adding one later. That claim is the project's, not an independently verified one.

## Licence, upgrade cost and what maintenance looks like

Nubase is Apache-2.0. That is a permissive licence: you can run it commercially, modify it, and redistribute it, with the usual requirements around preserving notices and stating changes, and no patent grant withdrawal. This is not legal advice; read the LICENSE file for the actual terms.

The practical licence question for a self-hoster is not the code but the dependencies you run alongside it. The all-in-one image bundles PostgreSQL and Redis, and Storage can be pointed at Cloudflare R2, AWS S3 or MinIO. Each has its own licence and its own operational cost, and the README does not discuss them.

On maintenance: the repository is not archived, and the last push was on 2026-08-18, which is recent. The release cadence visible in the repository is three releases in two days (v0.1.2, v0.1.3 and v0.1.4 on 2026-06-15 and 2026-06-16), then a gap to the last push in August. That pattern suggests bursts of work rather than a steady release train, and it means upgrade guidance is thin. The README documents no rollback procedure and no version compatibility matrix. If you deploy this, pin the image tag rather than tracking `latest`, and keep the `/data` volume, because the README states first-boot secrets are generated into it and that keeping the volume is what retains your projects.

## Conclusion

Adopt Nubase if you already drive Claude Code or Codex and want a backend target your agent can provision itself, or if you self-host and need many isolated project databases behind one control plane. Do not adopt it if you want a mature, widely deployed platform with years of production hardening, or if your stack is not Postgres-shaped. Before committing, verify two things: that a container restart with the same /data volume still decrypts your project credentials, and that the MCP surface exposes every operation your workflow needs, since the README documents Memory, Database, Storage, Auth, Functions, Assets and cron but not their full tool list.

## FAQ

### What is Nubase used for?

Nubase is an open-source, AI-native backend and deploy layer for AI coding agents and agentic applications. It bundles Database, Auth, Storage, Assets, Functions, AI Gateway, Memory and cron into one self-hostable service that an agent drives over MCP tools.

### How do I install Nubase?

Run the all-in-one Docker image, which bundles PostgreSQL, Redis, the backend and Studio, with port 9999 and 5432 published and a volume mounted at /data. Studio then runs at http://localhost:9999/studio, where you create an account, create a project and click Provision.

### How do I connect Claude Code or Codex to Nubase?

From your project folder, run npx -y nubase_cli@latest install-skills. The README states this installs the Nubase skills for both Claude Code and Codex, writes the MCP server config, and opens a browser to authorize and pick a project.

### Can I self-host Nubase, and does it support multiple projects?

Yes. The README describes a single all-in-one Docker image with no compose file and no external services, and says Nubase is built for one Studio, one backend service and many isolated AI projects, each with its own PostgreSQL database and JWT secret.

### What licence is Nubase released under?

Nubase is licensed under Apache-2.0, according to the repository and the licence badge in the README. That permits commercial use and modification under the terms of that licence.

## Sources

- [License: Apache-2.0](https://github.com/OtterMind/Nubase/blob/main/LICENSE)
- [OtterMind/Nubase on GitHub](https://github.com/OtterMind/Nubase)
- [Project website](https://nubase.ai)
- [README](https://github.com/OtterMind/Nubase/blob/main/README.md)
- [Releases](https://github.com/OtterMind/Nubase/releases)

---

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