How much work does migrating from Nhost Cloud to self-hosted Nhost take?
The database and Hasura layer move with the most predictability, while auth, storage, functions and client configuration need deliberate work. Teams usually reach this migration through a renewal, a data residency requirement, or a plan to run the backend inside their own cloud account. The work is typically carried out by platform or backend engineers, often with an implementation partner who handles the infrastructure. The total effort depends mainly on three things: the size and complexity of the Postgres schema and its Hasura metadata, how much of the authentication configuration (providers, redirect settings, email templates, and user records) must be recreated, and the volume of files in storage. A small project with one schema and a few providers is a very different job from a multi-tenant product with large file buckets.
Start by inventorying each component against the Nhost Cloud and self-hosted Nhost documentation, which are the reference for the exact export and configuration steps. For Postgres, plan a dump and restore into a self-hosted instance, then check that Hasura metadata and migrations apply cleanly and that the GraphQL schema matches what your clients expect. For auth, confirm which providers and secrets must be re-entered in the new environment and whether existing user records and password hashes can be carried across without forcing resets. For storage, estimate the file count and total size, since large transfers often dominate the schedule. Finally, update the client URLs, environment variables and redirect URIs in every app, and test each one against the new endpoints before cutover. Ask any implementation partner to price these components separately in a written scope.
Which Nhost Cloud capabilities move cleanly to self-hosted Nhost?
This table maps each Nhost Cloud capability to its self-hosted equivalent and rates the move as clean, needs rework or gap. Clean means the item moves with standard Postgres dump and restore or a Hasura metadata export, while items marked for confirmation depend on export paths the vendor documentation must settle. Use it as a checklist before you size the project.
| Capability | Self-hosted equivalent | Move rating and notes |
|---|---|---|
| Postgres database | Your own Postgres instance run from the Nhost Docker Compose setup | Clean. Use pg_dump and restore, then check extensions and roles on the target version. |
| Hasura GraphQL metadata and migrations | Hasura console or CLI against your self-hosted Hasura service | Needs confirmation. Export metadata and migrations, then confirm the export path against Nhost's docs. |
| Auth users and providers | Self-hosted Nhost auth service with your own provider settings | Needs rework. Password hashes, provider client secrets and redirect URLs must be re-entered or confirmed. |
| Storage buckets and files | Self-hosted storage service with an S3-compatible backend you operate | Needs confirmation. Copy objects and metadata, then verify bucket rules against Nhost's storage docs. |
| Serverless functions | Functions service running in your own cluster | Needs rework. Confirm runtime versions and rebuild any function that depends on hosted-only services. |
| Environment variables and client URLs | Your own environment configuration and frontend build settings | Needs rework. Every client, webhook and OAuth callback URL must point to the new domain. |
| Backups and point-in-time recovery | Backups you schedule and restore yourself | Gap for hosted features. Backup and recovery are now operated by you, so define retention and restore tests. |
| Custom domains and TLS | Your own DNS, reverse proxy and certificate process | Needs rework. Recreate DNS records and certificates, then confirm the Nhost configuration keys. |
What data and integrations have to be moved and rebuilt?
A migration from Nhost Cloud is less a single export than a set of separate moves: the Postgres data, the Hasura configuration, user accounts, files, functions and the URLs that clients and identity providers call. Each one has a different export path and a different owner, so confirm each item with Nhost before you start the cutover plan.
Postgres schema and data
Export the database with pg_dump or pg_dumpall, then restore it into the self-hosted Postgres instance. The PostgreSQL upgrading documentation covers same-version restores and major upgrades through pg_upgrade or logical replication, which matters if your target major version differs from the one Nhost Cloud runs. Confirm the Postgres version and extensions with Nhost before choosing the path, and check that any Nhost-managed schemas or roles are included in your dump.
Hasura metadata and migrations
Hasura tracked tables, relationships, permissions and actions live in metadata and migration files, which should be kept in version control and applied to the self-hosted Hasura engine. Your Nhost project's Hasura console or CLI export is the starting point, but permission rules and remote schemas must be reviewed by hand. Confirm with Nhost which metadata export format and Hasura version you will receive, so the self-hosted engine matches it.
Auth users and password hashes
User records, provider links and password hashes are the hardest part to move without forcing resets. Ask Nhost whether password hashes can be exported and in which algorithm, and whether the self-hosted Nhost Auth service will accept them. If hashes cannot move, plan a password reset campaign and communicate it to users before cutover. Verify the self-hosted auth service supports the same sign-in methods you use today.
Storage files and bucket rules
Storage moves in two parts: the file objects, copied from the Nhost bucket into your S3-compatible store, and the bucket and file metadata that the database references. Rebuild bucket rules and any access checks in the self-hosted storage service, because they are not carried by a file copy. Confirm with Nhost how file IDs map to object paths so that database references still resolve after the move.
Function code and secrets
Serverless function source code can be copied from the project repository, but environment variables and secrets are not exported by default. Each function must be rebuilt against the self-hosted runtime, and every secret, such as API keys and webhook signing values, must be re-entered in your own secret store. Test each function against the restored data before switching clients over.
Client and OAuth redirect URLs
Every client application, mobile deep link and OAuth provider has the Nhost Cloud domain registered as an allowed redirect or callback URL. Update these in each provider's console, along with the self-hosted base URL in your client configuration. Plan for a window where both domains are accepted, and confirm with each provider how long changes take to propagate.
What is the migration sequence from Nhost Cloud to self-hosted Nhost?
The sequence moves an Nhost Cloud project to a self-hosted stack in five gated steps, so each phase produces a checked artifact before the next one starts and the hosted project stays available as a fallback until cutover is verified.
Inventory the project and its owners
Before any infrastructure is built, list every part of the Nhost Cloud project: database schema, Hasura metadata and migrations, auth providers and their client IDs and redirect settings, storage buckets, serverless functions, environment variables, and every client URL that points at the project. Assign a named owner to each item, including who holds the Nhost Cloud account and who can change DNS and OAuth provider consoles. The output is a written inventory with owners and an agreed cutover approach. The step is done when the application team and the platform team have both signed off on that document.
Stand up a pilot in the target account
Deploy self-hosted Nhost from its Docker Compose example into the account, data center or air-gapped network where it will run, with TLS, backups and access controls configured to your own standards. Restore a copy of the Nhost Cloud Postgres database, then apply the Hasura metadata and migrations from the inventory. Confirm that storage buckets and a sample of files are reachable and that the auth providers can be configured. The output is a pilot environment and a restore log that shows which objects failed to apply, if any. Ask Nhost and your DeployOpen or internal team to confirm which Nhost Cloud features have no self-hosted equivalent before you rely on this environment.
Run a parallel environment and test clients
Point a staging build of the web or mobile client at the self-hosted GraphQL and auth endpoints while the Nhost Cloud project keeps serving production. Run the functional test suite, check role-based permissions in Hasura for each user role, and verify that sign-in, password reset, and third-party provider flows complete against the new redirect URLs. Repeat the data load until the restored database matches the source for the tables in scope. The output is a test report listing each client flow, its result, and the dated data load that produced the test database. This step closes when no open defects block a production cutover.
Cut over writes and client URLs
Announce a write freeze window with the owners from step one, then stop writes to the Nhost Cloud project. Take a final Postgres dump, restore it into the self-hosted database, and apply any storage files uploaded since the last copy. Switch client URLs, auth redirects and provider callback settings to the self-hosted domain, then confirm DNS and TLS. Verify with a fixed checklist: row counts for critical tables, a sign-in for each provider, a file upload and download, and one function invocation. The output is a signed cutover record with timestamps and the checklist results. Keep the rollback path documented until verification passes.
Decommission the Nhost Cloud project
After cutover is verified, change the Nhost Cloud project to read-only, or keep it reachable without client traffic, for a retention window set by your data retention policy and legal team. Confirm that a final backup of the hosted database and storage is stored in your own infrastructure. Once the window ends and no dependency remains, close the Nhost Cloud project and remove its credentials from CI systems and shared vaults. The output is a decommission record that lists the final backup location, the date the project was closed, and the owner who approved closure. Confirm the retention period with your compliance team, since this page does not set one.
How does the Postgres layer change once you operate it yourself?
The database under Nhost is standard PostgreSQL, so once you self-host, your team inherits Postgres operations as a discipline in its own right. Start by choosing the major version. PostgreSQL 14 support ends November 12, 2026, and versions 15 through 18 have later end dates, so check the target major version against the PostgreSQL versioning policy before you restore your Nhost Cloud dump. Confirm which version your Nhost Cloud project runs today, because the dump and restore path depends on it. Minor releases never change the storage format, so applying them means replacing executables and restarting. Major upgrades later use pg_dumpall and restore, pg_upgrade, or logical replication. Logical replication can keep downtime to several seconds, but it requires planning and testing that Nhost Cloud previously handled for you.
High availability is the next decision. Hot standby servers serve read-only queries, and you can choose synchronous replication, where a commit waits for standbys, or asynchronous replication, which does not wait. Each choice trades write latency against the data you could lose during a failure, so write that trade-off down before you pick one. PostgreSQL does not detect a failed primary or promote a standby on its own, so automatic failover needs an external tool that you select, configure and test. Confirm in writing who owns that tool and its runbook. Point-in-time recovery also depends on continuous archiving of WAL files, which you must set up, store off the database host and rehearse with a restore. Nhost Cloud's backup and recovery behavior should not be assumed to carry over unchanged.
Finally, plan connection handling. Hasura and the auth and storage services open many connections, and PgBouncer is the usual pooler to place in front of Postgres. Pool mode and connection limits must be tested against your Hasura and service settings, not copied from a default. Treat PgBouncer, the failover tool and the archiving setup as components you choose, install and run, each with its own upgrades and monitoring. Before cutover, ask whoever will own these pieces to document the target major version, the replication mode, the failover procedure and the restore test results.
What drives the cost and duration of the migration?
This table lists the factors that make an Nhost Cloud move larger or smaller, why each one matters, and how to reduce it before work starts. Read the rows first to size the project, then the cost split below them to see which spending happens once and which keeps recurring after cutover.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Database size and schema complexity | Larger Postgres databases take longer to dump, transfer and restore, and cross-table relationships and triggers add verification work after restore. | Remove unused tables and old data before export, and confirm the expected dump size and restore window with the team. |
| Hasura metadata, permissions and actions | Each role, row-level permission, relationship and custom action must be exported, reviewed and tested, and permission rules are the most common source of access errors. | Audit roles and permissions in the Hasura console, retire unused roles, and keep the metadata under version control. |
| Number of auth providers and users | Each sign-in provider needs its client IDs, secrets and redirect URLs reconfigured, and user records and password hashes must be moved and tested. | Disable unused providers and confirm with Nhost how password hashes and user data are exported for your project. |
| Volume and layout of storage files | File transfer time depends on total size and folder structure, and every stored file reference in the database must still resolve after the move. | Clean up orphaned files, group transfers by bucket, and verify a sample of file URLs after each copy. |
| Functions, webhooks and client apps | Each serverless function or event trigger needs to be rebuilt or redeployed, and every client app needs updated endpoints and environment variables. | List all functions, webhooks and apps in a single inventory, and retire those that no longer have an owner. |
| Target infrastructure, backups and monitoring | Servers, networking, TLS, backup schedules, restore tests and alerting are all set up by you, and each one adds design and testing hours. | Reuse existing infrastructure standards and define the backup and restore test plan before the build starts. |
| Team Postgres and Hasura experience | Teams familiar with Postgres and Hasura need less time to diagnose restore errors and permission mismatches, while newcomers need more review time. | Assign a named owner for each area and plan a short knowledge transfer before cutover. |
| One-time: migration work, testing and cutover | Mapping, scripting, rehearsal migrations, user acceptance testing, the cutover window and rollback planning happen once for the project. | Rehearse the full migration on a copy of production and agree the rollback steps in writing. |
| Recurring: servers, managed Postgres, backups and upgrades | Compute, storage, any managed database, backup retention, Nhost and Postgres upgrades, patching and on-call support continue after go-live. | Ask for a quote that separates setup from ongoing support so the recurring line is visible before you sign. |
How does the migration differ by starting point?
A small project with one database, a few sign-in providers and modest storage is the simplest path. The sequence stays short: stand up the self-hosted services, restore the Postgres dump, apply the Hasura metadata and migrations, copy the storage files, then reconfigure providers and client URLs before you move traffic. The main risk is assuming a small project has few hidden dependencies.
- Auth providers: List every enabled sign-in method and its callback URLs, then confirm each one is registered with its provider before cutover.
- Password hashes: Confirm whether users sign in with email and password and whether the export includes password data you can import without forcing resets. Ask Nhost what the export contains.
- Storage: Count the files and confirm the bucket layout copies cleanly into your self-hosted storage service.
- Client configuration: Find every app, environment file and webhook that points at the Nhost Cloud domain.
Before you move the production domain, confirm that a test user can sign in, read a row through a permitted GraphQL query and upload a file on the self-hosted stack.
A project with separate staging and production environments has separate data, configuration and access rules in each environment. Migrate staging first to rehearse the full sequence, then run production with the same steps in the same order. The rehearsal is where you find drift between environments, so treat it as a required phase rather than an optional test.
- Rehearse on staging: Run the full restore, metadata apply and cutover against staging, and write a runbook from what actually happened.
- Environment variables: Keep secrets and keys separate for each environment and confirm none were copied from staging into production.
- Schema drift: Compare the Hasura migrations in your repository with the live schema in each Cloud project, because a staging project may have diverged from production.
- Cutover order: Decide whether the backend or the clients move first, and define how writes are handled during the window when both systems could receive them.
Before you schedule the production change, confirm that the staging rehearsal produces matching row counts, the same Hasura metadata and the same sign-in results as the source.
When much of your access control lives in Hasura permission rules and custom actions, the database dump alone does not carry the behavior you depend on. Export and version the metadata, then test each role against the self-hosted endpoint to confirm that returned rows match the policy you expect. Treat the permission model as a separate workstream with its own verification.
- Metadata export: Export the Hasura metadata from the Cloud project and compare it with your repository copy before you apply it to self-hosted Nhost.
- Role-by-role tests: Test every role, including anonymous, user, admin and any custom roles, and check each result against the policy.
- Custom actions and functions: Confirm the handler URL, secrets and environment variables for each action, since these point at services that must be reachable from the new stack.
- Claims and rules: Check that the JWT claims issued by the self-hosted auth service contain the values your permission rules read.
Before cutover, run an access test matrix covering each role and each action, and keep the results as evidence in your change record.
Large file volumes make transfer time and the final synchronization window the constraints that matter most. Data residency requirements decide where the copied database and files may sit, so confirm the current location of your Nhost Cloud data before you choose target regions. Copy the bulk of the files ahead of cutover and plan a short final sync for the files that changed since the copy.
- Region of origin: Confirm in writing the region and provider where Nhost Cloud holds your database and files, then require the same or stricter terms at the target.
- Pre-copy and delta sync: Move most files before the cutover window, then copy only the objects changed since the first pass.
- Object storage target: Choose the self-hosted object store and confirm its replication and durability settings in writing for your environment.
- Database downtime: If your source and target Postgres major versions differ, PostgreSQL documents logical replication as a way to keep major-version downtime short. Review the PostgreSQL upgrade documentation for the options.
- Backups before cutover: Take a full backup of the database and storage before any move so you can roll back.
Before you accept the migration as complete, verify the file count, sampled checksums and the storage region against the source.
What usually goes wrong when moving off Nhost Cloud?
Most problems in an Nhost Cloud migration come from work the hosted service did for the team without being visible: password hashes, Hasura configuration, redirect URLs, storage rules and backups. Each card below names one risk, why it matters for this move, and the check to run before cutover.
Forced password resets
If user password hashes are not exported and imported, every user must reset their password after cutover, which generates support load and lost sign-ins. Confirm with Nhost which hash format its auth data uses, and test one account end to end on the self-hosted Nhost Auth service before any bulk import. Agree in writing who owns the hash export step.
Hasura metadata drift
Permissions, relationships and event triggers edited in the Hasura Console on Nhost Cloud may not exist in the version-controlled files. Export the metadata, compare it with the running project, and keep the files in Git as the single source of truth. Otherwise a rebuilt environment can silently lose row-level access rules.
Stale client and OAuth URLs
Frontend builds, mobile apps and mail templates still point at the old Nhost domains, and OAuth providers still list the old redirect URIs. Inventory every place a URL is set, including provider consoles for Google, GitHub and similar services, and update them in a planned window. Test sign-in with each provider on the new domain before retiring the old one.
Storage files without bucket rules
Copying files from storage without recreating the bucket settings, access rules and file metadata can expose private files or break downloads. Compare bucket configuration, file counts and sample checksums after the copy, and confirm that signed or private access behaves the same on the self-hosted stack.
Backups and recovery assumed away
Teams often assume the hosted provider handles backups and point-in-time recovery, so none are configured after cutover. Self-hosting moves that duty to you. Define backup frequency, retention, off-site copies and a restore test for Postgres and the storage bucket, and confirm how the provider's recovery features map to your own tooling.
No tested rollback path
A cutover without a documented way back leaves the team stuck if data diverges or the self-hosted stack fails under load. Decide the rollback trigger, freeze writes on the old project during the final sync, and rehearse the switch in a staging copy. Record the time a rollback takes so the go or no-go call rests on evidence.
What do teams ask before migrating from Nhost Cloud?
How much does a move from Nhost Cloud to self-hosted Nhost cost?
The cost is mostly people time and infrastructure, and the figures depend on your project. Nhost Cloud fees are paid to Nhost, while a self-hosted stack moves the cost to servers or cloud accounts, managed or self-run Postgres, storage, egress, monitoring, backups and the engineers who operate them. The main drivers are database size, file volume, number of Hasura metadata objects and functions, how many environments you need, and how much high availability you want. Ask for a quote that lists one-time work (setup, data move, auth and DNS cutover, testing) separately from recurring items (hosting, backups, upgrades, on-call support). Ask Nhost to confirm its current export and data egress terms, and ask your cloud provider for the compute and storage prices you would pay.
How long does migrating an Nhost Cloud project take?
The timeline depends on the drivers, so it should come from a written scope rather than a rule of thumb. The longest items are usually the Postgres dump and restore, verifying Hasura metadata and migrations against the new instance, moving storage files, and reconfiguring auth providers and client URLs. Smaller projects with few tables and files move faster than projects with many functions, custom auth flows or large media libraries. Plan a parallel run and a cutover window, and confirm with your provider how long each step will take on your data.
Can our own team migrate from Nhost Cloud without outside help?
Yes, if your team already has solid PostgreSQL and Hasura experience and someone who can run Docker Compose in production. Before starting, check that you can cover these points:
- Dump and restore Postgres with verified row counts and extensions
- Apply Hasura metadata and migrations and test permissions role by role
- Move storage objects and confirm file IDs and access rules still match
- Reconfigure auth providers, redirect URLs, SMTP and client environment variables
- Set up backups, restore tests, monitoring and an upgrade routine
If any item is new to the team, scope that part with an implementation partner in writing before cutover.
What does the migration need from our side?
Name a named owner for each area before work starts, because most delays come from decisions nobody can make. You will typically need an owner for authentication and identity providers, one for DNS and domains, one for the cloud accounts or servers that will host the stack, and one for data sign-off who can confirm the restored data is correct. You also need access to the Nhost Cloud project, a window for the cutover, and agreed rules on who can approve rollback. Record these owners in the written scope so the migration does not stall on approvals.
Will our users have to reset their passwords after the move?
Whether users must reset passwords depends on whether the password hashes can be exported and imported without changes. If the hashes and their parameters come out of Nhost Cloud, the self-hosted Auth service can verify existing logins; if they do not, users will need a reset flow. Confirm the export format with Nhost support and check the Nhost self-hosting documentation for how the auth service stores and verifies hashes. Test a sample of real logins on the new stack before cutover, including social and magic-link providers, which do not use passwords and need their redirect URLs updated.
Do storage files move automatically during the migration?
No, files need an explicit export and import step, and the file IDs, bucket settings and access rules must be checked afterward. Confirm the export path with Nhost before you plan the window, since egress and download limits can affect how long the copy takes. After the copy, compare object counts and checksums per bucket, then test that uploads, signed URLs and permissions behave the same way in the client app. Keep the original bucket readable until the new stack has passed these checks.
What do we lose by self-hosting Nhost instead of using Nhost Cloud?
Managed operations move to your team or your partner. Nhost Cloud handles infrastructure, hosting and vendor-run support, while a self-hosted stack puts backups, restore testing, patching, scaling, monitoring and incident response in your hands. Point-in-time recovery, managed high availability and the vendor's support plans need to be replaced or confirmed in your own design. The features and support terms of Nhost Cloud change over time, so compare the current plan details with the self-hosting documentation before you decide. Ask your provider to document each responsibility in a runbook.
How do we run Nhost Cloud and self-hosted Nhost in parallel?
Run the new stack alongside the old one, copy data on a schedule, and switch traffic only after checks pass. A common pattern is to restore a recent Postgres dump to the self-hosted instance, replay Hasura metadata, run automated and manual tests against it, then repeat the data sync just before cutover. Keep the Nhost Cloud project as the source of truth until the final sync, lower DNS time-to-live before the window, and keep a rollback path that points clients back to the original project. Write down the cutover order, the freeze on writes, and the criteria for declaring success.
How DeployOpen scopes and runs a migration from Nhost Cloud
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a move from Nhost Cloud to self-hosted Nhost, we agree the scope in writing first, then move the Postgres database, Hasura metadata, storage files and auth configuration in controlled, tested steps.
How we scope
- Written scope lists the Nhost Cloud project, Postgres version, Hasura metadata, auth providers, storage buckets and functions in use
- Scope states where the self-hosted Nhost stack will run, such as your cloud account, data center or air-gapped network
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any migration work starts
- Ask for a quote that lists each migration step, the cutover window, and any functions that need rewriting
How we build
- Set up the self-hosted Nhost services, including Postgres, Hasura, auth, storage and functions, from the Docker Compose example
- Dump and restore the Postgres database, then apply Hasura metadata and migrations and test queries against the restored data
- Copy storage files and verify checksums and object counts against the source buckets before cutover
- Reconfigure auth providers, redirect URLs and client endpoints, then test sign-in and file access in a staging environment
How we hand over
- Documentation covers the architecture, configuration keys, backup jobs and the runbook for the cutover and rollback steps
- Backup and restore procedures are tested so your team can confirm recovery before relying on the self-hosted stack
- Handover includes a list of Nhost Cloud features you will operate yourselves, such as point-in-time recovery and monitoring
- Evidence of controls and configuration is delivered for your own compliance assessors, who issue any audit report
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the migration is complete
- Upgrade plans cover Nhost, Hasura, Postgres minor releases and major version changes, scheduled and tested before rollout
- Security testing of the migrated applications and APIs can be scoped separately from the platform work
- Ask us to confirm which support responsibilities sit with DeployOpen, with your team, and with the Nhost project
