Nhost API
Nhost is an open-source Firebase alternative built on PostgreSQL, Hasura (GraphQL engine), and a suite of integrated services: authentication (email/password, OAuth, magic links), file storage (S3-compatible), serverless functions, and email. The platform auto-generates a GraphQL API from your PostgreSQL schema via Hasura, with real-time subscriptions and fine-grained row-level permissions. The management REST API (Nhost Cloud) handles project provisioning, configuration, and deployment. Applications interact with the platform primarily via GraphQL for data, REST endpoints for auth and storage, and the Nhost JavaScript/TypeScript SDK that wraps all services.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
Admin secret is a plaintext shared secret with no expiry — it's a significant security risk if leaked and cannot be rotated without downtime on self-hosted instances. JWT-based auth with Hasura claims is the correct security model for production. Row-level security is enforced via Hasura permission rules, not PostgreSQL RLS — this is a single point of failure if Hasura is bypassed via direct database access. Self-hosted deployments must secure the Hasura endpoint independently.
⚡ Reliability
Best When
You want a Firebase-like developer experience (auth, database, storage in one platform) but with PostgreSQL and GraphQL instead of NoSQL, and you want the option to self-host the entire stack.
Avoid When
Your team is not comfortable with GraphQL, you need a non-Postgres database, or you require enterprise-grade SLAs and dedicated infrastructure without the complexity of self-hosting.
Use Cases
- • Bootstrapping a full-stack web or mobile app backend with database, auth, and file storage without managing infrastructure
- • Building real-time applications using Hasura's GraphQL subscriptions over PostgreSQL — chat, dashboards, collaborative tools
- • Implementing social auth (Google, GitHub, Facebook) and JWT-based session management via the auth service without custom implementation
- • Storing and serving user-uploaded files with access control tied to Hasura permission rules
- • Self-hosting the entire Nhost stack via Docker Compose for on-premise or private cloud deployment
Not For
- • Teams needing MySQL, MongoDB, or non-PostgreSQL databases — Nhost is PostgreSQL-only via Hasura
- • High-scale enterprise workloads requiring dedicated infrastructure without managed service overhead
- • Projects that prefer REST-first APIs over GraphQL — Nhost's data layer is GraphQL-primary; REST requires Hasura REST endpoints or custom functions
- • Teams that need multi-region active-active replication — Nhost Cloud is single-region per project
Interface
Authentication
Auth service issues JWTs (access tokens, 15-minute expiry by default) and refresh tokens. Hasura uses JWT claims to enforce row-level permissions — the JWT must contain a hasura namespace with x-hasura-role and x-hasura-user-id. Admin secret (plaintext header x-hasura-admin-secret) bypasses all permission rules — never expose in client-side code. Nhost SDK handles token refresh automatically. Service-level API keys used for management API (project creation, configuration). OAuth providers (Google, GitHub, etc.) supported for user-facing auth flows.
Pricing
The free tier is functional for development and small production apps. Self-hosting via Docker Compose is completely free and provides the same feature set. Cloud pricing is competitive with Firebase and Supabase for small to medium projects.
Agent Metadata
Known Gotchas
- ⚠ GraphQL errors return HTTP 200 — agents that only check HTTP status codes will miss data errors; always inspect the 'errors' field in the response body.
- ⚠ Hasura admin secret bypasses all row-level security — agents using the admin secret for convenience will silently return data that should be restricted; use user-scoped JWTs with proper role claims instead.
- ⚠ JWT access tokens expire in 15 minutes by default — long-running agents must implement token refresh using the refresh token endpoint or the SDK's auto-refresh capability; expired token errors look like permission errors, not auth errors.
- ⚠ Hasura permission rules are Postgres expressions evaluated per row — incorrectly written permission rules can silently return empty results instead of an error, making it hard to distinguish 'no data' from 'permission denied'.
- ⚠ File storage paths are user-controlled strings — agents generating paths must avoid collisions and handle the case where a file already exists at the target path (overwrite vs. error behavior varies by configuration).
- ⚠ Hasura's query depth and node limits are enforced — deeply nested GraphQL queries (common when auto-generating queries) will be rejected; agents must set reasonable query complexity bounds.
- ⚠ Real-time subscriptions via GraphQL require a WebSocket connection — agents cannot use subscriptions over plain HTTP; for server-side change detection, agents must poll or use Hasura event triggers with webhook callbacks.
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for Nhost API.
Scores are editorial opinions as of 2026-03-06.