Nhost: a self-hostable Firebase alternative built on Postgres and Hasura

The gap Nhost fills between Firebase and a hand-built backend

Firebase gives you a document store, auth, file storage and functions as one managed product. The trade-off is that the data model is not relational and the query language is not SQL. Nhost takes the opposite position: the README describes it as an open source Firebase alternative with GraphQL, built around PostgreSQL for the database, Hasura for the instant GraphQL API, plus its own auth and storage services and Node.js serverless functions.

The intended user is a frontend or full-stack developer who wants auth, a typed API and file uploads without assembling and operating each piece. The README lists quickstarts for Next.js, React, React Native, SvelteKit and Vue, and a separate Dart and Flutter client, so the frontend choice is not meant to constrain you. If your application is naturally tabular, with foreign keys and joins, this is a closer fit than a document store. If your application is a stream of loosely shaped events, it is not.

Postgres, Hasura metadata and a thin client: how the pieces connect

The architecture is a composition of existing open source projects rather than a new engine. PostgreSQL holds the data. Hasura reads the schema and exposes GraphQL over it. Auth and Storage are separate services in the same repository, under services/auth and services/storage. Serverless functions are Node.js, written in JavaScript or TypeScript. The CLI is what ties local development together: the README says it sets up a local environment that tracks database migrations and Hasura metadata.

That last detail matters more than it looks. Because migrations and Hasura metadata are tracked as files, the schema and the API surface can be versioned together, and a local environment can be rebuilt to match. The client side is deliberately thin. The @nhost/nhost-js package gives you a createClient call and then two namespaces, nhost.auth and nhost.graphql, so sign-in and queries go through the same object. The repository is a monorepo: go.mod at the root shows a Go codebase for the services, while package.json shows a pnpm workspace with turbo driving builds. The root package.json also pins the toolchain, requiring Node 22 or later and pnpm 12.3.4.

Installing the Nhost CLI and running a first query

The README offers three paths: the hosted platform, local development through the CLI, and self-hosting. The local path is the one worth walking first, because it does not require an account decision up front.

On macOS or Linux the CLI installs through Homebrew or a shell script. Nix users get a flake, and JavaScript projects can take it as a dev dependency through npm, pnpm, Yarn or Bun.

brew install nhost/tap/nhost

curl -sSL https://raw.githubusercontent.com/nhost/nhost/main/cli/get.sh | bash

Once the binary is on your PATH, the README's three-step start is login, init and up. The login step authenticates the CLI against your Nhost account, init scaffolds the project directory, and up starts the local stack.

nhost login
nhost init
nhost up

After that, the application side is a single package. The README's example creates a client from a subdomain and region, signs in with email and password, then issues a GraphQL query against a users collection.

import { createClient } from '@nhost/nhost-js'

const nhost = createClient({
  subdomain: 'your-project',
  region: 'eu-central-1'
})

await nhost.auth.signInEmailPassword({
  email: '[email protected]',
  password: '<password>'
})

A successful run leaves you with a local GraphQL endpoint, an auth service and a database you can migrate. The README points to the CLI Quickstart guide at docs.nhost.io for the full walkthrough, and that guide, not the README, is where the environment variables and ports are documented.

Self-hosting Nhost is a docker-compose exercise, not a binary

The README's third option states that since Nhost is 100% open source you can self-host the whole stack, and points to an example docker-compose file in examples/docker-compose. That is the honest shape of the offer: you are running PostgreSQL, Hasura, auth, storage and the function runtime as containers, and you own the upgrades, backups and networking between them.

The README does not document a supported production topology, resource sizing, backup procedure or upgrade path for that compose file. It is presented as an example, and the documentation site is the place it defers to. For a team that already runs Postgres and containers, this is a normal amount of work. For a team that has never operated a database, self-hosting Nhost is a larger commitment than the three-step CLI quickstart suggests, and the hosted platform exists precisely because of that gap.

Where Nhost is the wrong choice

The clearest limitation is the data model itself. Nhost is SQL and GraphQL. Applications built around Firebase's offline-first client SDKs, with local caching and automatic conflict resolution, do not get an equivalent here; the README describes a client that signs in and issues GraphQL requests, not a synchronising local store. Migrating such an application means rewriting the data access layer, not swapping a config value.

A second constraint is operational. The services are separate processes with their own configuration. Local development hides that behind one CLI command, but production does not. If nobody on the team is comfortable with Postgres roles, Hasura metadata and object storage credentials, the hosted option is the realistic path, and then the open source licence is less of a differentiator than it appears.

A third point is that the README is a signpost, not a manual. It links to docs.nhost.io for the complete documentation and does not document rollback, version pinning between services, or what happens when a local environment drifts from a deployed one. Those answers live on the documentation site, and a team evaluating Nhost should read that site rather than the repository front page.

Nhost against Supabase and Appwrite

The obvious comparison is Supabase, which also puts PostgreSQL at the centre. The difference is the API layer. Supabase exposes Postgres through its own generated REST and realtime interfaces. Nhost puts Hasura in front, so the primary interface is GraphQL, with the schema and Hasura metadata tracked as files by the CLI. If your frontend already speaks GraphQL, or you want a single query language across clients, that is a real distinction. If you would rather avoid GraphQL tooling, it is a reason to look elsewhere.

Appwrite takes a third route: it is a backend server with its own database abstraction and SDKs, rather than a wrapper around PostgreSQL and Hasura. That means less SQL and less control over the schema, but fewer moving parts to operate. Nhost's bet is that developers who want a backend-as-a-service still want a relational database they can query directly. That bet is either the reason to choose it or the reason not to, depending on how much of your application logic lives in the database.

Licence, maintenance and what upgrades cost

The repository is MIT licensed, and the README states that this repository and most of the other open source projects are under the MIT license. That is permissive: you can self-host, modify and redistribute. It is worth noting that Nhost is also a commercial hosted product, so the same codebase serves both the open source distribution and the paid platform. MIT does not oblige the maintainers to keep any particular service open, though the licence on existing code cannot be revoked retroactively.

On maintenance, the repository is not archived, and the most recent push recorded is 2026-09-21. Recent releases include [email protected] on 2026-09-18, [email protected] on 2026-09-16 and [email protected] on 2026-09-16. The versioned packages are a practical detail for upgrades: the CLI, the functions runtime and the MCP package move on their own schedules, so pinning versions matters when you self-host. Upgrading a local environment is the CLI's job; upgrading a self-hosted deployment means moving container images and applying any Hasura metadata or migration changes yourself. The README does not describe a supported upgrade procedure for the compose example, so treat that as work to plan rather than work to discover.

Editorial conclusion

Adopt Nhost if your team already thinks in SQL tables and wants a GraphQL layer, auth and file storage without wiring five services together, and verify first that the local CLI workflow (nhost init, nhost up) and the docker-compose example match your deployment target. Do not adopt it if you need Firestore-style offline-first document sync or cannot operate PostgreSQL, Hasura metadata and object storage yourself. Check the docker-compose example in examples/docker-compose before committing, because that file, not the README, defines what self-hosting actually requires.

Frequently asked questions

Official sources

1. License: MIT
2. nhost/nhost on GitHub
3. Project website
4. README
5. Releases