Nhost Cloud vs self-hosted Nhost: which fits your team
Choose Nhost Cloud if you want the vendor to operate the Postgres, Hasura, auth, storage and functions stack, with hosted backups and the compliance coverage of the Team plan. Choose self-hosted Nhost if data location rules, an existing platform engineering team or a need to control upgrades matter more than the operating load. Nhost is MIT-licensed, so the self-hosted route carries no software license fee, and you start from the Docker Compose example, then adapt, harden and keep it current. The two routes differ less in features than in who carries the operational duties.
The decision starts with who patches and backs up Postgres. PostgreSQL is released under the PostgreSQL License, and each major version receives support for 5 years after its initial release, so your team must plan major upgrades on that cycle. Minor releases replace executables and require a restart, while major upgrades use dump and restore, pg_upgrade or logical replication, which the upgrading documentation says can limit downtime to several seconds. High availability is also yours to build: PostgreSQL supports hot standbys and synchronous or asynchronous replication, but it does not detect a failed primary, so automatic failover needs external tooling. Point-in-time recovery depends on continuous archiving that you configure and test.
Two other questions settle the rest. First, ask Nhost in writing which SOC 2 report the Team plan covers, for which period, and which services it includes, then check whether that scope matches the systems your auditor will examine. A self-hosted deployment does not inherit that report, so you would need your own evidence for the controls you operate. Second, define the recovery time and recovery point your business can accept, ask Nhost what its hosted backups and restores provide, and run a restore drill on your self-hosted stack to measure your own timing. Confirm any hosted service commitments in the contract, since this section does not state specific service levels.
Nhost Cloud vs self-hosted Nhost by scenario
This table matches common situations to the option that usually fits better, Nhost Cloud or the self-hosted Nhost stack from its Docker Compose example. Read each row against your own constraints, since the right choice depends on who will operate Postgres, Hasura, auth, storage and functions day to day.
| Scenario | Better fit | Why and when it matters |
|---|---|---|
| Small product team with no platform engineers | Nhost Cloud | Operating Postgres, Hasura, auth, storage and functions yourself adds recurring patching, upgrades and on-call work. This matters most when no one on the team owns infrastructure outside the application. |
| Regulated company that must keep customer data in its own cloud account | Self-hosted Nhost | Running the stack in your own account keeps database and file locations under your control. Confirm with your compliance lead which data residency terms apply and whether the hosted plan's data location meets them. |
| Team that needs Postgres point-in-time recovery it can test itself | Self-hosted Nhost, with a tested restore plan | Hosted backup features do not automatically transfer. You must set up WAL archiving and restore drills yourself, using PostgreSQL's continuous archiving documentation. Confirm what Nhost Cloud's plan includes before deciding. |
| Team that already runs managed Postgres and Kubernetes | Self-hosted Nhost | Existing managed Postgres, backup tooling and cluster operations can absorb the stack without a new operating model. Check how Hasura and the other services map to your deployment standards before committing. |
| Organization that needs compliance evidence it can show auditors for its own environment | Self-hosted Nhost, if you own the controls | Evidence from your own logs, access reviews and change records belongs to your environment. Nhost Cloud's SOC 2 coverage applies to the hosted service, so confirm its scope with Nhost and its auditor before relying on it. |
| Team with a hard budget ceiling for hosting | Depends on staff time | Self-hosting shifts spend from plan fees to servers, managed services and engineering hours. Compare total cost of ownership, including the people time to run the stack, before concluding that self-hosting costs less. |
Nhost Cloud vs self-hosted Nhost side by side
This table compares who runs each layer of the Nhost stack under Nhost Cloud and under a self-hosted Nhost deployment built from its Docker Compose example. Read each row as a question to put to Nhost and to your own platform team, because several Nhost-specific details must be confirmed rather than assumed. The main takeaway is that the Postgres layer is well documented in general, but operational duties such as backups, upgrades and availability move to your team when you self-host.
| Capability | Nhost Cloud | Self-hosted Nhost |
|---|---|---|
| Postgres hosting | Hosted by Nhost; confirm the Postgres major version and region options in your plan | You run the Postgres container or external instance; PostgreSQL 14 support ends November 12, 2026, so choose a supported major version |
| Hasura GraphQL | Managed by Nhost; confirm the Hasura version and how metadata changes are deployed | You deploy and upgrade Hasura yourself and apply metadata and migrations from your repository |
| Authentication and provider setup | Provider and client URL settings are changed in the Nhost dashboard; confirm which providers your plan enables | Provider credentials and redirect URLs live in your environment configuration; you own secret rotation |
| Storage | Hosted file storage with plan-based limits; confirm quotas, egress terms and overage rules | Files live on the storage backend you configure; you size disks, back them up and manage access policies |
| Functions | Hosted serverless functions deployed through Nhost; confirm runtime and concurrency limits | Functions run on your own compute; you own scaling, logging and runtime updates |
| Backups and point-in-time recovery | Backup and recovery features depend on plan; confirm retention window and restore procedure in writing | You build and test backups; PostgreSQL point-in-time recovery needs continuous WAL archiving that you configure and rehearse |
| Environments and branching | Confirm how many projects and environments your plan includes and whether staging copies are supported | You create staging stacks yourself, typically by duplicating Compose files and restoring a database dump |
| Upgrades | Nhost applies platform upgrades; confirm notice periods and any downtime windows | You plan and run each upgrade, including PostgreSQL minor and major upgrades, Hasura and Nhost component versions |
| Monitoring and alerting | Confirm which metrics and logs are exposed to you and how long they are kept | You choose and run the observability stack; the Postgres layer needs its own connection, replication and disk alerts |
| Support and compliance scope | Confirm which SOC 2 scope and support tier the Team plan covers before relying on it for an audit | Community support and your own controls; any compliance evidence for the stack is produced by your team |
Where your data lives and who can see it
These cards cover where the database and files sit, who operates the stack, who can read user records and secrets, and what compliance evidence you can show. Each one shifts when you move from Nhost Cloud to a self-hosted Nhost, so the decision belongs to the data owner and the security team together.
Data location and region
Nhost Cloud decides which cloud account, region and network hold your Postgres database and file storage, and that choice is fixed when the project is created. Check the region at signup against your residency rule, and confirm in writing where backups and logs are kept. When you self-host, your team chooses the account, region and network, so the same rule becomes a design decision for your platform team. Confirm the region before any production data is loaded.
Who operates the hosting
On Nhost Cloud, Nhost runs the infrastructure behind Postgres, Hasura, auth, storage and functions. Self-hosting moves provisioning, patching, scaling and restores to your team, whether you run the Docker Compose example or build your own orchestration around it. Ask Nhost which parts of the self-hosted stack it supports for production and which components carry vendor support. Budget for the on-call rota and upgrade work that come with running the stack yourself.
Where user records live
User accounts and password hashes sit in the same database as your application data, so anyone with database administrator access can read them. On Nhost Cloud, access to that database is governed by Nhost's operations controls and your project settings. Self-hosted, your team controls it, which means restricting superuser roles, limiting who can query the auth tables, and documenting that list. Ask Nhost how it protects auth data at rest and who inside its operations can reach it.
Keys and admin secrets
The Hasura admin secret, the JWT signing key, storage credentials and the database password decide who can bypass your permission rules. Nhost Cloud keeps these in project configuration that Nhost manages, while self-hosting places them in your environment files or secret store. Inventory every secret, name an owner and a rotation schedule for each, and confirm that no placeholder value from the example configuration reaches production. Ask Nhost how each key is generated, stored and rotated.
SOC 2 scope and evidence
The Nhost Cloud Team plan carries SOC 2 coverage, which can support your own vendor review for the services Nhost describes. Before you cite that report, confirm its scope: the audit period, which services and regions it includes, and whether it reaches your application layer or any self-hosted deployment. Self-hosting means you generate your own control evidence for the stack. DeployOpen prepares controls and evidence for assessment, but it does not issue reports or attestations; independent auditors do.
Who runs Postgres, Hasura and auth after the move
When you self-host Nhost, the operating duties that Nhost Cloud currently handles move to your team. You decide when to apply Nhost and Hasura version upgrades, test migrations and Hasura metadata against a copy of production, and roll back if a release breaks a query or an auth flow. You also patch the host operating system, the container runtime and each service image, and you own the rotation of auth and storage secrets, the Hasura admin secret and the database credentials. Scaling the Postgres instance, watching its disk, connections and replication lag, and deciding what to alert on are part of the same list. Before you commit, confirm with Nhost's self-hosting documentation which services, secrets and upgrade procedures apply to your version, and write down who is on call when an auth outage happens at 2 a.m.
The Docker Compose example is a starting point for evaluation, not a production topology. It typically places every service on one host with one Postgres container and no standby, so a host failure takes the whole backend down. PostgreSQL can run hot standby servers and replicate synchronously or asynchronously, but it does not detect a failed primary or notify a standby to take over. Automatic failover therefore needs an external failover tool, and that tool needs its own configuration, fencing rules and testing. Decide your recovery time and data loss targets first, then read the PostgreSQL failover documentation to see what your chosen tooling must cover.
Connection handling is the next thing to evaluate. Hasura and the auth service each hold database connections, and as concurrent users grow, the Postgres connection count can become a bottleneck before CPU or storage does. PgBouncer is a common connection pooler to test under load, but confirm that your pooling mode works with the session-level features your Nhost stack uses. Minor PostgreSQL releases replace executables and require a restart, while major upgrades need pg_upgrade, a dump and restore, or logical replication. PostgreSQL 14 is supported only until November 12, 2026, so plan that major upgrade into your calendar now.
What the Postgres layer under Nhost means for upgrades
Nhost runs on PostgreSQL, so the Postgres release calendar sets the upgrade clock for a self-hosted stack. On Nhost Cloud the provider carries that work, while on self-hosted Nhost your team owns version choice, minor patches and major upgrades. The four cards below cover the license, the release cadence, the support window and the upgrade paths.
Permissive license for the database
PostgreSQL is released under the PostgreSQL License, a liberal open source license similar to the BSD or MIT licenses. For a self-hosted Nhost stack, this means no license fee for the database engine and no vendor-specific terms to add to your review. Check with your legal or procurement team whether any managed Postgres service you pair with the stack adds its own terms.
Yearly major releases, five-year support
PostgreSQL ships a new major version about once a year and supports each major for five years after its initial release. Minor releases arrive at least once every three months. Plan a recurring review of the Postgres version in your Nhost deployment, since the calendar sets when security patches stop for that major.
Check support end dates
Supported majors include 18 (to November 14, 2030), 17 (to November 8, 2029), 16 (to November 9, 2028), 15 (to November 11, 2027) and 14 (to November 12, 2026). Majors 13 and earlier are no longer supported. If your Nhost deployment runs 14, the end date is the trigger to schedule an upgrade, and you should confirm the version in your own environment before planning.
Minor patches versus major upgrades
Minor releases never change the internal storage format, so updating means replacing executables and restarting. Major upgrades need a different method: a dump and restore with pg_dumpall, pg_upgrade, or logical replication, which works between major versions with only several seconds of downtime. Your choice depends on database size, downtime tolerance and how much of the Hasura metadata and schema you need to re-verify afterward.
How backups and point-in-time recovery change
On a hosted service, Nhost Cloud may provide managed backups and point-in-time recovery, but self-hosting moves that responsibility to your team. Before cutover, confirm in writing what Nhost Cloud backs up (the Postgres database, storage objects, auth data or some combination), how far back a restore can reach, who can trigger a restore, and whether those settings are included in the plan you buy. Nhost's plan documentation and your contract are the sources to check, not assumptions carried over from other platforms. Once you run Nhost yourself, none of those answers are provided for you.
Point-in-time recovery in PostgreSQL works on a simple model described in the continuous archiving documentation: you keep a periodic base backup of the data directory and continuously archive the write-ahead log (WAL) segments produced after it. To restore to a chosen moment, you start from the base backup and replay archived WAL up to that point. Your team must own every part of that chain: the archive command or tool, its storage location and encryption, retention rules that match your recovery and compliance needs, and alerts for archiving failures. A gap in the WAL archive silently removes the ability to recover to any time after it, so monitor archive lag as closely as database health.
Point-in-time recovery is only as good as the last restore you have actually performed. Before cutover, run a restore drill on a separate host: restore the latest base backup, replay WAL to a timestamp chosen in advance, then start the Nhost services against that database and confirm that Hasura metadata, migrations, auth users and storage object references all resolve. Record the elapsed time and the data loss window you achieved, and compare both with what your recovery objectives require. Repeat the drill on a schedule after go-live, and treat a failed drill as a blocker for the production move.
Which costs fall on your team and which stay with the vendor
Moving from Nhost Cloud to self-hosted Nhost shifts some costs from a vendor invoice to your own budget and staff time. The cards below separate what you keep paying for, what you start paying for, and what is paid once, so you can ask each provider the same questions in writing.
Nhost Cloud subscription and usage
Your Nhost Cloud bill combines a plan fee with metered charges for database, storage, egress and any dedicated compute you add. Overages in these categories are where bills usually move between months, so the cost depends on your traffic and data growth as much as on the plan. Check the current plan terms and usage rates directly on the Nhost pricing page, and ask for a written projection based on your own usage history.
Servers, cloud accounts and backup storage
Self-hosting moves compute, networking and storage into your cloud account or data center. Costs scale with the size of the Postgres, Hasura, auth, storage and function containers, plus snapshot or off-site backup copies that you now own. Ask your cloud provider or infrastructure team to model instance sizes, storage growth and egress for your expected traffic, rather than copying the Nhost Cloud usage pattern.
Managed Postgres, if you choose it
Running Postgres on a managed service removes some patching and backup work, but it adds a separate recurring line item and may not support every extension or the Hasura metadata setup you rely on. Confirm which Postgres versions the provider supports, how point-in-time recovery is priced, and whether the service can host the Hasura and storage connections your Nhost stack uses.
Monitoring, logging and on-call
A self-hosted stack needs metrics, logs, alerting and an on-call rotation that Nhost Cloud otherwise handles for you. Costs include the monitoring tools themselves, log retention storage and the time to tune alerts. Decide who receives pages for database, auth and storage failures, and ask any monitoring vendor for retention and per-GB pricing in writing before you commit.
One-time migration and hardening
Moving data, users, storage files, Hasura metadata and auth provider settings is a project with a defined start and end. It includes testing restores, locking down network access, configuring secrets and documenting the setup. Fixed-scope work agreed in writing before it starts keeps this cost visible; ask any implementation partner for a scope that lists deliverables, environments tested and acceptance criteria.
Recurring upgrades and compliance evidence
Upgrading Nhost components, Postgres minor and major versions and container images, and producing evidence for SOC 2 style controls are ongoing responsibilities once you self-host. The Team plan's SOC 2 coverage ends at the vendor boundary, so your staff or a retainer must collect the evidence for everything you run. Ask for a retainer scope that states upgrade frequency, test environments and which evidence the partner prepares versus what your auditor reviews.
What a move from Nhost Cloud to self-hosted Nhost involves
The sequence moves the database, Hasura metadata, storage and auth configuration from Nhost Cloud into a self-hosted stack in stages, with a tested rollback path before any user traffic moves. Each step ends with a check that tells you whether to continue.
Inventory the project before changing anything
Your team lists everything the Nhost Cloud project depends on: database schema, Hasura metadata and migrations, serverless functions, enabled auth providers, storage buckets and their access rules, environment variables, and every client URL or redirect address the apps use. Engineers with access to the Nhost dashboard and the project repository do this, and a product owner should confirm which features are actually in use. The output is a written inventory that you can check item by item in later steps. Confirm the exact list of components against the Nhost migration documentation for the version you run.
Stand up the self-hosted stack in staging
Platform engineers deploy the open-source Nhost stack from its Docker Compose example into a staging environment that is separate from production. They configure Postgres, Hasura, auth, storage and functions, and set secrets and domains for the staging hostnames. The step is complete when every service reports healthy, the Hasura console is reachable only by authorized staff, and a test request reaches the database through Hasura. Your team owns the hosting, networking and TLS decisions, so record them as they are made.
Export and restore Postgres with verification
Database engineers dump the Nhost Cloud Postgres database and restore it into the staging instance, applying the schema and Hasura metadata in the order your inventory specifies. They compare row counts for every table, check primary keys, foreign keys, unique constraints and check constraints, and confirm that sequences resume at the correct values. The step is complete when the counts and constraint checks match the source for each table, and the discrepancies you find are logged and resolved. Restore into staging first, so a failed attempt never touches production.
Move storage files and confirm access rules
Engineers copy every storage bucket's files to the self-hosted storage service and keep the original file paths and metadata. They then test the access rules with requests made as an anonymous user, an authenticated user who owns a file, and a user who does not. The step is complete when file counts and checksums match for sampled and full buckets, and each access case returns the result your rules require. Any file that cannot be copied is listed with its owner, so the business decides what to do with it.
Reconfigure auth providers and client URLs, then test sign-in
Engineers recreate each enabled auth provider in the self-hosted auth service, update OAuth redirect URIs with each identity provider, and change the Nhost domain, storage URL and GraphQL endpoint in every client build and configuration. QA staff then sign in with each provider and each role in staging, check token refresh, and confirm that protected queries behave as before. The step is complete when every provider signs in and every client endpoint points at the staging self-hosted stack. Plan how existing user accounts and password hashes will be handled before this step, because that decision determines whether users must reset passwords.
Cut over with a rollback plan and a restore test
Before the cutover, the team writes a rollback plan that names who decides to revert, how client URLs are switched back, and how writes made during the window are reconciled. They run a restore test from a backup of the production-equivalent database into a fresh instance, then freeze writes, repeat the final export and restore, switch DNS and client endpoints, and watch error rates and sign-in success. The cutover is complete when the production traffic is served by the self-hosted stack, the rollback path has been rehearsed, and the backup schedule is confirmed. Work scales with the number of functions, custom integrations and auth providers, so each of these may add effort to every step.
Questions buyers ask before self-hosting Nhost
How much effort does self-hosting Nhost take?
The effort depends on how much of the stack you operate and how many environments you run. Nhost bundles Postgres, Hasura, auth, storage and functions, and each one needs configuration, upgrades, monitoring and backups. The main drivers are the number of environments (development, staging and production each need their own stack), the number of serverless functions and their dependencies, the number of auth providers with their callback URLs, and your compliance scope, since every control you claim needs evidence. Inventory these before you size the work, and ask any implementation partner to base its estimate on that inventory.
Can a small team run self-hosted Nhost alone?
A small team can run it alone if at least one engineer is comfortable with the core skills and someone is available to respond to incidents. The skills include PostgreSQL administration, Hasura metadata and migrations, Docker or Kubernetes operations, TLS and secrets handling, and tested backup and restore. PostgreSQL supports hot standby servers and point-in-time recovery through continuous archiving, but it does not detect a failed primary or promote a standby by itself, so automatic failover requires external tooling. Plan for on-call coverage and a documented incident process, because a single person on call is a common point of failure.
How long does a migration from Nhost Cloud take?
No single duration applies to every project, so the timeline should come from the scope you write down. The factors that move it most are the size of the Postgres database, the volume of storage files, how many Hasura permissions and migrations need to be replayed, how many auth providers and client URLs must be reconfigured, and how many serverless functions need to be ported and tested. Downtime planning also matters, since cutover windows depend on how long a consistent dump and restore takes for your data. Ask for a dated plan with checkpoints for each of these items rather than a single headline figure.
Does Nhost SOC 2 coverage carry over to self-hosting?
No, SOC 2 coverage does not carry over automatically. A vendor's report describes that vendor's hosted service, and it does not cover infrastructure you run in your own cloud account or data center. Your organization needs its own system description, its own controls for access, change management, backups and monitoring, and its own evidence that those controls operated. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations. An independent auditor decides whether your controls meet the criteria. Confirm the exact scope of the Team plan report with Nhost before you rely on it.
Is the Nhost Docker Compose example production ready?
The Docker Compose example is a useful starting point, but it is not production ready as delivered. Production work usually adds TLS termination with managed certificates, secrets kept out of compose files, pinned image versions, resource limits, network segmentation, and persistent volumes with monitoring. It also needs scheduled Postgres backups, continuous archiving for point-in-time recovery, and restore tests that someone has actually run. High availability needs a standby and a failover tool, and the upgrade process needs a rehearsal in a non-production environment. Treat each of these as a line item in your written scope.
What costs recur after moving off Nhost Cloud?
One-time costs cover planning, migration, configuration, hardening and testing. Recurring costs cover the servers or cloud resources that run Postgres, Hasura, auth, storage and functions, plus backup storage, egress, monitoring, log retention and the time your team spends on upgrades, patching and on-call duty. Some teams also pay for managed Postgres, a support retainer or a periodic security test. Costs rise with the number of environments, data volume, backup retention, and the need for redundancy. Compare these components against your current Nhost Cloud invoices, and ask any vendor for a breakdown that separates one-time work from monthly running costs.
What should a written, fixed-scope quote from DeployOpen include?
A fixed-scope quote should list what is in and out of the engagement, in writing, before work starts. Ask for the inventory of services, environments, functions and auth providers that the work covers, the deliverables for each phase, and the acceptance criteria for cutover. The quote should name the responsibilities split between your team and DeployOpen, the assumptions about your infrastructure and access, and the items excluded, such as application code changes. Ask whether backup and restore testing, hardening, compliance evidence preparation and post-launch support are included or offered as a separate retainer. DeployOpen does not publish a price list, so the quote follows from that written scope.
How DeployOpen helps you decide, implement and migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Nhost Cloud vs self-hosted Nhost, we start by agreeing on what you need to operate yourself and what you are willing to hand to a managed provider.
How we scope
- We agree in writing which Nhost services you will run: Postgres, Hasura, auth, storage and functions.
- We record backup, recovery and data location requirements before any environment is provisioned.
- Scope, deliverables and timelines are fixed in writing before work starts, and a quote follows from that scope.
How we build
- We deploy the Nhost stack from its Docker Compose example into your cloud account, data center or air-gapped network.
- We configure Postgres backups and recovery procedures, and test a restore before go-live.
- We set up auth providers, storage and client URLs, and test access rules against your own user roles.
How we hand over
- We document the architecture, configuration, runbooks and Hasura metadata so your team can operate the stack.
- We walk your platform, security and database owners through restore, upgrade and incident procedures.
- We prepare control and evidence records for your compliance assessment, while independent auditors issue any reports.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrades to Nhost components and PostgreSQL are planned, tested in a staging copy and documented before rollout.
- Ask us to confirm the support scope, response expectations and exit terms in the written agreement.
