Nubase: a self-hostable backend that coding agents drive over MCP

The gap Nubase is aimed at: a demo with no backend behind it

A coding agent can produce a working front end and a plausible schema in one session. What it cannot produce is a database with row level security, a token issuer, a bucket for uploads, and somewhere to host the result. The README frames this directly: without a backend layer, quote, every AI coding session produces another demo that still needs weeks of infrastructure work. Nubase is the attempt to collapse those weeks into one container.

The audience is narrower than the tagline suggests. It is not aimed at a product team that already has a platform group. It is aimed at people who are already driving Claude Code or Codex and want the agent to have a real target to write against, and at self-hosters who want several isolated projects on one box. The README states the contrast with Supabase plainly: the open-source self-hosted Supabase stack is designed around a single project, while Nubase is built for one Studio, one backend service, and many isolated project databases.

Eight modules behind one port, with a Studio control plane on top

The architecture is a single backend service that serves both the API and the Studio UI on the same port. The Docker image bundles PostgreSQL, Redis, the backend, and Studio together, so the default deployment has no external service dependency. Studio runs at /studio on port 9999, and the API sits at the root of the same port.

Isolation is per project, not per user. The README states that each project gets its own PostgreSQL database, its own JWT secret, its own roles, and its own schema cache. Provisioning a project is an explicit step in Studio: you create an account, create a project, then click Provision to initialize its database. That control plane is what makes the multi-project claim concrete rather than marketing.

The data API is PostgREST-compatible at /rest/v1, supporting select, filter, order, paginate, insert, update, upsert, and delete. Row Level Security works against JWT claims, and each project issues its own 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. Assets is the piece that closes the loop: per-project static files served under /assets/v1/** with Cache-Control, ETag, and 304 handling, plus a per-project default cache policy and an optional custom CDN domain. Functions and cron cover backend logic and recurring work. The AI Gateway is listed among the eight modules but the supplied README excerpt does not describe its configuration, so treat its surface as undocumented here.

Memory as a table, not a sidecar vector store

The design choice that separates Nubase from a generic Postgres-plus-REST stack is memory. The README describes it as a first-class primitive with durable memory, entity extraction, history, and hybrid retrieval built in, and the topic list includes pgvector. That combination suggests memory rows live in the same per-project Postgres instance that holds application data, which means a single backup and a single connection string cover both.

The practical consequence is that an agent can write a memory and then read it back through the same REST surface it uses for application tables, rather than through a separate vector service with its own credentials and its own consistency story. The README's own example prompt does exactly this: 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.

What the material does not specify is how hybrid retrieval is weighted, what embedding model is assumed, or how entity extraction is triggered. Those are the questions to ask before trusting memory with anything you would miss, and the README excerpt does not answer them.

Getting an agent connected: install-skills and the MCP handshake

The agent side is one command run from your project folder:

npx -y nubase_cli@latest install-skills

According to the README, that command installs the Nubase skills for both Claude Code and Codex, wires up the MCP server config, and opens a browser to authorize and pick a project. For Claude Code you restart it in the folder, run /mcp, and confirm nubase is connected. For Codex the README states the entry is added to ~/.codex/config.toml, and you start Codex.

Pointing the CLI at a specific instance uses two flags:

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

The split between studio-url and nubase-url is worth noting: authorization happens against Studio, while tool calls go to the API. If you put Nubase behind a reverse proxy, both hostnames need to resolve correctly, and the README does not describe what happens when they diverge.

Running your own instance, and the secrets decision on first boot

The self-host path is a single docker run with no compose file. The quick version maps port 9999 for Studio and the API and port 5432 for Postgres, and mounts a named volume at /data:

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

The README notes that first-boot secrets are generated into the /data volume, and that keeping the volume retains your projects. That is fine for a trial. It is not fine for anything you intend to keep, because the production form pins two values explicitly:

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's stated reason is that stable secrets let encrypted project credentials survive restarts. Read that as a warning about the default path: if you start with auto-generated secrets and later need to move the volume or recreate the container, the keys that encrypt stored project credentials are tied to that first boot. Decide which mode you are in before you provision anything you care about. Everything else (Postgres, Redis, S3 or R2, SMTP, OAuth, LLM providers) is environment variables, with the full list in docs/docker-all-in-one.md, which also carries a multi-architecture note covering amd64 and arm64.

Where Nubase is the wrong tool

The project is at v0.1.4, with v0.1.2, v0.1.3, and v0.1.4 all released between June 15 and June 16, 2026. Three releases in roughly two days is a normal early cadence, and it also means the REST surface, the MCP tool names, and the Studio flows have not had time to settle. Pin the image tag rather than tracking latest if you deploy this anywhere real.

The second limitation is structural. The README's own framing is that Nubase is for AI teams and self-hosters who want many isolated AI projects on their own infrastructure. That is a different shape from a multi-tenant product backend. If you are building a SaaS where each customer is a tenant inside one application, the per-project database model is the wrong axis: you would be provisioning a project per customer and paying for it in Postgres instances, when what you want is one database with a tenant column and RLS policies. Nubase gives you RLS, but the isolation unit it optimizes for is the project, not the customer.

The third limitation is the single-container default. Bundling Postgres and Redis into the same image is what makes the one-line start work, and it also means you cannot scale the database independently of the API, and you cannot point the backend at a managed Postgres without leaving the documented path. The README says everything else is configured via environment variables, so an external database is presumably reachable, but the supplied material does not walk through that configuration. Treat it as unverified until you read docs/docker-all-in-one.md.

Against Supabase: same primitives, different unit of isolation

The obvious comparison is Supabase, and the README makes it explicitly rather than dodging it. Both give you Postgres, a REST layer, JWTs, RLS, object storage, and a Studio dashboard. The README calls Supabase excellent and then names the difference: the self-hosted Supabase stack is designed around a single project.

That is the whole argument. If you self-host Supabase, you get one project's worth of backend, and a second project means a second stack or a hosted account. Nubase adds a control plane that provisions and routes to multiple isolated project databases behind one Studio and one service. If you only ever run one project, that control plane is overhead you are carrying for nothing, and Supabase's larger ecosystem is the better trade. If you are spinning up a backend per agent session or per prototype, the provisioning step is the feature.

The second difference is memory. In Supabase, retrieval means adding pgvector and writing your own ingestion and query path, or reaching for an external service. Nubase ships entity extraction, history, and hybrid retrieval as part of the product. Whether that built-in version is good enough for your retrieval quality bar is the thing to test, and the README does not give numbers to test against.

Licence, upgrade cost, and what to check before you commit

Nubase is Apache-2.0, which permits commercial use and modification with the usual attribution and notice requirements, and includes a patent grant. The README excerpt does not mention any separate enterprise edition, hosted-only feature, or contributor licence agreement, so there is nothing in the supplied material suggesting a feature split between the open-source and hosted versions. That is a reading of the documentation, not legal advice; if you are embedding Nubase in a product, have counsel confirm the notice obligations.

Upgrade cost is the real question at this version. The image is distributed on Docker Hub under ottermind/nubase and the CLI on npm as nubase_cli, so both move independently of the repository tags. Because the MCP config is written into ~/.codex/config.toml and into Claude Code's MCP settings, a CLI upgrade can change the tool surface your agent sees, and the README does not describe a versioned compatibility contract between the CLI, the MCP server, and the backend. Re-running install-skills after an upgrade is the documented way to refresh the wiring, and the --studio-url and --nubase-url flags are what you re-supply if the instance moved.

Three things to verify on your own before adopting. First, that the image pulls and Studio answers at http://localhost:9999/studio on your architecture (the README notes both amd64 and arm64). Second, that a provisioned project's /rest/v1 endpoint enforces the RLS policies you wrote, with the project's own JWT secret rather than a shared one. Third, that memory written through an agent tool call is readable from a plain SQL client against that project's database, which is the claim that makes the memory primitive worth having.

Editorial conclusion

Adopt Nubase if you are running an agent-driven workflow and want the generated app to land on infrastructure you control, with memory as a table you can query rather than a vector store you maintain separately. Do not adopt it if you need a multi-tenant SaaS backend for human customers, or if you cannot pin the two secret environment variables before first boot, because the README states that first-boot secrets are generated into the /data volume. Before committing, verify two things yourself: that docker run -d --name nubase -p 9999:9999 -p 5432:5432 -v nubase_data:/data produces a reachable Studio at http://localhost:9999/studio, and that the MCP entry appears in ~/.codex/config.toml after npx -y nubase_cli@latest install-skills. The project is at v0.1.4 with three releases inside four days in June 2026, so treat the API surface as moving.

Official sources

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