Is Nhost Cloud cost higher than self-hosting Nhost?
Self-hosting Nhost usually costs less on the license line and more on the operations line. Nhost is MIT-licensed, so there is no software license fee to pay whether you run it yourself or buy the hosted edition. What you pay for instead is infrastructure, the people who run the stack, and the time spent on upgrades. Whether the total ends up lower depends on how much of the Nhost stack you actually use and how much your team already runs for Postgres and containers. If you are renewing or your usage bill has grown, start by separating the two sides before comparing them.
The answer depends on the Nhost plan and the usage you are billed for. The research behind this page does not include Nhost's own plan fees, database, storage or egress overage rates, or dedicated compute prices, so pull those from Nhost's pricing page and the last several invoices. Note which charges recur monthly and which grow with database size, stored files or outbound traffic, because those are the lines that move as your app grows. Ask Nhost to confirm in writing which services each plan includes and which support terms apply.
On the self-hosted side, the costs are servers or cloud instances for Postgres, Hasura, auth, storage and functions, plus backups and monitoring. The larger recurring cost is staff time for Postgres operations, security patches, version upgrades and incident response, along with any backup or high availability setup you need in place. Estimate those hours on your own team, and check whether a backup and restore has been tested, since hosted plans may include some of those controls that you must build. Your data residency requirement may tip the balance on its own, so confirm where each option would store your data before comparing invoices.
Which cost components move when you leave Nhost Cloud
This table compares each cost component of running Nhost Cloud with the matching cost of running the open-source Nhost stack yourself, and marks whether each cost is one-time or recurring. The Nhost Cloud column is filled from your own invoices and Nhost's current pricing page, since no Nhost prices are included here. Use it to find which lines disappear, which move to your cloud account, and which new internal effort you must budget for.
| Cost component | Nhost Cloud (commercial side) | Self-hosted Nhost (open-source side) | One-time or recurring |
|---|---|---|---|
| Subscription or plan fee | Monthly plan fee for the tier you use, as shown on Nhost's pricing page and your invoices | No license fee, since Nhost is MIT-licensed; you pay only for the infrastructure and people that run it | Recurring on the commercial side; none on the open-source side |
| Database and storage overages | Usage charged above plan allowances for Postgres and file storage, visible on your invoice | Storage cost becomes the disks, volumes or object store in your account, sized by your own data growth | Recurring |
| Egress | Data transfer charges billed by Nhost, which depend on how much your clients download | Egress billed by your cloud provider or charged against your own network links | Recurring |
| Dedicated compute | Dedicated resources priced by Nhost for the tier you choose | Virtual machines or nodes you size, patch and pay for in your own account | Recurring |
| Servers or cloud accounts | Included in the platform fee; no separate server bill | Compute for Hasura, auth, storage, functions and the Postgres host, plus load balancing and DNS | Recurring |
| Managed Postgres | Included in Nhost's database offering, billed through the plan | Either a self-run Postgres container on your servers or a managed Postgres service you pay for separately | Recurring |
| Implementation and setup | Little or none, since the project is provisioned for you | Engineering time to deploy the Docker Compose stack, configure services, set secrets and connect client URLs | One-time, sometimes repeated for new environments |
| Data migration | Export and import effort on your side, plus any Nhost support you request | Dumping and restoring Postgres, applying Hasura metadata and migrations, and moving storage files and auth providers | One-time |
| Upgrades, backups and internal skills | Platform maintenance and backups handled by Nhost within the plan | Ongoing patching of each service, tested backups, point-in-time recovery design and staff who know Hasura and Postgres | Recurring; the largest component to budget for |
What pushes the comparison up or down
Six drivers decide whether a self-hosted Nhost stack costs less than Nhost Cloud for your workload. Each one pushes the comparison in a different direction on the hosted side and the self-run side, so measure them before you compare plan fees with server and staff costs.
Concurrent users and request volume
Hosted plan fees and overages usually rise with traffic, so heavy GraphQL query volume moves cost toward Nhost Cloud. On a self-hosted stack, the same traffic is served by the servers you size, so cost rises in steps as you add nodes or larger instances. Measure peak concurrent sessions, requests per second through Hasura, and how often auth tokens are refreshed. Ask Nhost to show how its plans meter requests before you assume a flat fee.
Database size and growth
Database size is the driver most teams underestimate. Hosted database storage is metered, so a growing Postgres dataset raises the bill steadily. Self-hosted, storage is a disk you provision, back up and replicate, which adds volume cost plus backup retention cost. Measure current size, monthly growth, and the retention you need for point-in-time recovery, since hosted backups and self-hosted backups are built differently.
File storage and egress patterns
Storage volume and egress are separate meters on hosted plans, and downloads of large files or image transforms can cost more than the stored bytes. Self-hosted, egress depends on your network provider and the bandwidth of your servers, and storage can move to an S3-compatible store. Measure total stored bytes, daily download volume, and how many files are served publicly versus through signed access.
Availability and recovery targets
A hosted plan with managed backups and recovery features moves that work to the vendor, which carries cost in the plan price. A self-hosted stack needs your own standby database, failover process, and tested restores, and the staff time to keep them working. Define the recovery point and recovery time you need, then ask which of those features the plan you are evaluating includes and which you would build yourself.
Number of environments
Each extra environment, such as staging, preview or a customer sandbox, multiplies cost on a self-hosted stack because each one needs its own containers, database and storage. Hosted plans may price additional projects differently, so the comparison shifts with the count. Count environments you need in a normal month, including short-lived review environments, and ask the vendor how each one is billed.
In-house skills to run the stack
The people cost of running Postgres, Hasura, auth and storage is often the largest line in a self-hosted estimate, and it recurs every month. Teams with strong Postgres and container operations skills carry less of that cost, while teams without them may need outside help for upgrades and security patches. Inventory who can operate each component, how many hours a month they can spare, and what a quote for ongoing support would cover.
How to build the Nhost comparison with your own numbers
This sequence turns Nhost Cloud invoices and your own infrastructure quotes into a side-by-side model of recurring and one-time costs over the horizon your business uses. Every figure in the result comes from your environment and your quotes, not from this page.
Export twelve months of Nhost invoices
The billing owner exports the last twelve months of Nhost Cloud invoices and usage reports from the billing account. Split each month into plan fee, database, storage, egress, dedicated compute and any other line item, and note which months include overages. Check that the totals match the amounts charged to your payment method. The output is a table of monthly cost by component that shows which lines recur and which spike with usage.
List the Nhost features your app uses
Engineering lists every Nhost service the application calls: Postgres tables and views, Hasura GraphQL queries and subscriptions, auth providers and sign-in flows, storage buckets, serverless functions and scheduled jobs. Mark each item as core, occasional or unused. This list defines the scope of the self-hosted stack, because the cost of running a service you never call is a cost you can drop. The output is a signed-off feature inventory that the team can price against.
Price the self-hosted compute from your own rates
The platform or cloud team prices compute using your own cloud account or data center rates, not list prices from a catalog. Supabase's self-hosting guide gives minimum requirements of 4 GB RAM, 2 CPU cores and a 40 GB SSD, and recommends 8 GB RAM, 4 cores and 80 GB. Treat those figures only as a reference point for sizing a sibling stack, then load-test your own workload to set the real size. Include staging and development environments if you will run them. The output is a monthly compute line for each environment.
Price the database and backup layer
Decide whether Postgres will be a managed service from your cloud provider or a self-managed cluster you run. For a managed service, request the quote for instance size, storage, backups, retention and cross-region copies. For self-managed Postgres, add the cost of a standby server, WAL archiving for point-in-time recovery and monitoring. PostgreSQL supports hot standby and synchronous or asynchronous replication, but it does not detect a primary failure on its own, so price an external failover tool as well. The output is a database line with backup and standby costs stated separately.
Estimate staff hours for upgrades and on-call
Platform engineering estimates the hours needed each month for routine work: applying Docker Compose configuration releases, rebuilding services that pin new upstream versions, planning PostgreSQL minor and major upgrades, rotating secrets, reviewing security fixes and responding to alerts. Supabase's self-hosting docs describe the community support channels rather than a support contract, so count the people who will own each incident. Use your own loaded hourly cost. The output is a monthly staff line with named owners and an on-call rota.
Add the one-time migration cost
Estimate the one-time work separately: setting up the services, dumping and restoring Postgres, applying Hasura metadata and migrations, moving storage files, reconfiguring auth providers and client URLs, testing, and running parallel environments during cutover. Ask any implementation partner for a fixed-scope written quote that names deliverables and timelines before work starts. The output is a single one-time figure with its scope written beside it.
Compare one-time and recurring cost over your horizon
Finance and engineering add the one-time migration cost to the recurring self-hosted lines and compare the total with the twelve-month Nhost baseline across the planning horizon your business uses. Run the comparison again with higher usage, a second environment and a failed-upgrade scenario, labeled as illustrative. Record which assumptions drive the result, such as storage growth, egress or on-call load. The output is a dated model with its assumptions, reviewed by the people who own the budget.
What running the Postgres layer yourself adds to the bill
The database layer costs little in licensing and a good deal in operations. PostgreSQL is released under the PostgreSQL License, a liberal license similar to the BSD or MIT licenses, so there is no license fee to pay. What you pay for is the infrastructure underneath it, the time of the people who patch it, and the support you arrange for it. Each major version is supported for five years after its initial release, and the supported window matters for planning. Version 17 is supported until November 8, 2029, version 16 until November 9, 2028, version 15 until November 11, 2027 and version 14 until November 12, 2026. Check which major version your Nhost project runs today and put its end-of-support date on the upgrade calendar. Minor releases never change the internal storage format, but they still mean replacing executables and restarting the server, so schedule them in a maintenance window.
Major upgrades are the expensive step. You can dump and restore, run pg_upgrade, or use logical replication. Logical replication works between major versions and can keep downtime to several seconds, but it needs a cutover plan, validation of replicated data and someone who understands the replication slots. Restore-based upgrades are simpler and take longer, and their duration grows with database size. Ask your team or implementation partner to estimate the effort for your data volume and to rehearse the upgrade on a copy before the production date. High availability is the second cost. PostgreSQL does not include automatic failover, so detecting a failed primary and promoting a standby requires external tooling, monitoring and staff who can run it. Hot standbys and synchronous or asynchronous replication are built in, but the decisions about failover and their testing are yours.
Backups and point-in-time recovery are the last line of the bill. PostgreSQL provides continuous archiving, but the archive location, retention, encryption, restore runbooks and regular restore tests are your responsibility. Hosted platforms usually bundle these controls, so treat them as new line items: storage for base backups and WAL archives, the engineering hours to build the pipeline, and the recurring time to test restores. Confirm your recovery time and recovery point objectives before you compare numbers, because they determine how much standby capacity and archive storage you need.
How the comparison changes by team and availability need
A single app in one environment makes the hosted plan the simplest line to read, but self-hosting carries fixed costs that do not shrink with traffic. Most of the self-hosted bill is the server, the off-host backup target and the hours spent on upgrades and monitoring, and those costs are similar whether the app has a few users or many.
- Server and storage. One virtual machine sized for the Docker Compose footprint, plus disk for Postgres, file storage and backups. Ask Nhost for its recommended minimum resources for the services you plan to run.
- Backups. A single node needs copies stored off the host. Point-in-time recovery depends on continuous archiving, which you set up, store and pay for yourself.
- Upgrades and monitoring. Each Nhost, Hasura and Postgres update becomes a task your team owns, and nobody is on call unless you assign it.
- Hosted plan fees. Compare the plan's fixed fee with your server and labor, including any overage on database size, storage and egress at your expected usage. Get those rates in writing.
- Fixed scope. A single-node installation, a tested backup and restore routine, and an upgrade runbook.
Confirm with Nhost which backup and support terms apply to the plan you would leave, and whether a single-node setup suits your app's expected growth.
Several apps multiply most cost lines, because each environment usually needs its own database, storage bucket, authentication configuration and functions. The cost question shifts from one server to how many stacks you run, how often they change and who moves changes between them.
- Per-project and per-environment fees. Ask whether the hosted plan bills each project or environment separately, and how an extra staging project changes the total.
- Duplicate infrastructure. Self-hosted staging and production mean two stacks, two backup chains and two upgrade windows, unless you share hosts and accept weaker isolation between them.
- Promotion work. Hasura metadata, migrations and auth provider settings must move between environments through version control. That pipeline is labor you build and maintain.
- Shared database capacity. Several apps sharing one Postgres need connection planning and sizing, and a connection pooler such as PgBouncer is worth evaluating before you commit to a layout.
- Fixed scope. Environment parity between staging and production, a promotion pipeline, separated secrets and a documented process for schema changes.
Confirm how Nhost counts projects, seats and environments, and decide in advance who owns the pipeline that promotes changes between staging and production.
Regulated teams with strict recovery and data location requirements find that most of the cost sits in design and operations. The software fee matters less than the recovery targets, the replication layout, the evidence you must produce and the staff who keep those controls running.
- High availability. PostgreSQL supports hot standby servers and both synchronous and asynchronous replication, but it does not detect a primary failure or fail over by itself. External failover tooling, a second node and regular failover tests are costs you carry. The PostgreSQL high availability documentation explains the building blocks.
- Recovery design. Point-in-time recovery needs continuous archiving to storage in the approved location, plus restore drills measured against your own recovery targets.
- Residency. Confirm which regions Nhost offers and where backups are held. Self-hosting lets you choose the location, and that choice brings hardware, bandwidth and staffing costs.
- Evidence. A hosted plan may include vendor-side compliance reports, but your team still needs evidence for the self-hosted stack, access controls and change records. DeployOpen prepares controls and evidence for assessment, while independent auditors issue any report.
- Fixed scope. A high availability design, a point-in-time recovery runbook, a restore test with recorded results, an evidence pack and a documented on-call model.
Ask Nhost in writing for the scope of its compliance reports, the backup and point-in-time recovery options by plan, and the data location for each option before you compare totals.
Questions buyers ask before comparing Nhost costs
How much effort does self-hosting Nhost take, and what does the team need to provide?
Self-hosting Nhost moves the work of running Postgres, Hasura GraphQL, auth, storage and functions from the vendor to your team. Effort depends on how many environments you run, how often you upgrade, and whether you already operate containers, TLS, secrets and database backups. Expect ongoing work for patching, monitoring, capacity planning and incident response, not only the first deployment. Ask your team to estimate those tasks against its current on-call load before you decide. The Nhost documentation for its Docker Compose example is the natural starting point for that estimate.
Can our team self-host Nhost without outside help, and what skills should we check?
Many teams can, provided they already run production Postgres and container platforms. Check for hands-on experience with PostgreSQL backups and restores, Docker or Kubernetes operations, reverse proxies with TLS, secret rotation, and the Hasura metadata and migration workflow. Also check whether someone can own upgrades for each component, since the services release independently. If any of these skills are thin, the gap is usually the cost driver, not the software. Run a short internal test restore before you commit to self-hosting.
How long does migrating from Nhost Cloud take, and what drives that time?
The supplied research does not give a duration for migrating an Nhost project, so treat any figure you hear as unverified until you test it. The main drivers are the size of the Postgres database, the volume of storage files, how much Hasura metadata and migration history must be replayed, the number of auth providers to reconfigure, and how many client URLs change. Run a rehearsal on a copy of production data and time each step. That measured result is the number to plan around.
Does self-hosting Nhost remove the license fee?
Nhost is MIT-licensed, so self-hosting removes the subscription line for the hosted service but does not remove the cost of running the stack. You still pay for servers or cloud instances, storage, network egress, backup storage, monitoring, and the people who operate it. Those costs replace the Nhost plan fees rather than disappearing. Build a side-by-side model with the Nhost Pro or Team plan fees, overage charges and dedicated compute on one side, and infrastructure plus operations time on the other. Confirm current plan terms directly with Nhost, since plan details can change.
What does a fixed-scope implementation of self-hosted Nhost include?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Nhost, a typical written scope covers the deployment architecture, environment setup, database and storage migration, auth provider reconfiguration, backup and restore testing, hardening, and handover documentation. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports or certifications.
What recurring costs remain after a self-hosted Nhost goes live?
After go-live, costs recur in four areas: compute and database hosting, storage and egress, backup retention and restore testing, and ongoing operations. Upgrades also recur, and you should plan for them as a standing task. Self-hosting also means you own high availability. The PostgreSQL high availability documentation notes that automatic failover needs external tools, so budget for that tooling and its operation. Ask whether support is part of the plan, since community channels and retainers have very different cost profiles.
What should we ask a provider for in a quote for self-hosted Nhost?
Ask for a written scope that lists each deliverable, the environments included, and the acceptance criteria for migration and cutover. Request the assumptions behind the estimate, including database size, storage volume, number of auth providers and Hasura metadata complexity. Ask how backups, restore tests, upgrades and hardening are handled, and whether they are one-time or recurring. Confirm what happens if scope changes, which responsibilities stay with your team, and what evidence you will receive for compliance reviews. DeployOpen provides a quote based on the written scope.
How DeployOpen scopes a fixed-price Nhost self-hosting implementation
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Nhost Cloud cost vs self-hosted Nhost, the work starts with a written scope that compares your actual plan, overage and infrastructure costs against the people time a self-hosted Nhost stack would need.
How we scope
- Inventory current Nhost Cloud plan fees, database, storage and egress usage, and any dedicated compute you pay for today.
- Agree in writing which Nhost services move in scope: Postgres, Hasura, auth, storage and functions.
- Define who operates the stack after handover and which support model you want, as an engagement is fixed-scope with ongoing support available as a retainer.
How we build
- Deploy the self-hosted Nhost stack from its Docker Compose example in your environment, with secrets generated rather than left at defaults.
- Size server, managed Postgres and storage components against your measured workload, and document the assumptions behind each size.
- Test backups and restores, auth configuration and client URLs before any cutover, and record the results for your review.
How we hand over
- Deliver runbooks covering upgrades, Hasura metadata and migration steps, and backup and recovery procedures for your team.
- Document the cost model so you can see which line items recur, which are one-time, and what drives each one up or down.
- Walk your platform and security staff through operations, then confirm acceptance against the written scope.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
- Plan upgrades of Nhost components and underlying Postgres versions as a tested change, with rollback steps documented.
- Prepare controls and evidence for compliance assessments, noting that independent auditors and certification bodies issue any reports.
