Move Your Vercel Website or Web App to Your Own Hosting

Audit the Vercel Project

Before moving anything, identify what Vercel currently provides for the project and what must be prepared for external hosting. Keep the existing Vercel deployment live while you work.

Vercel Migration Audit

Classifies everything the project depends on as portable as-is, needing production configuration, or Vercel-dependent, then returns the recommended deployment type, exact build and start commands, output directory, runtime version, and a migration checklist.

Review this project specifically for migrating it from Vercel to my own hosting. Identify: - the framework and project type - the package manager - the production build command - the build output directory, if applicable - the production start command, if required - the required Node.js or runtime version - whether the project is static/frontend-only or requires a server runtime - the Git repository and production branch, if detectable - any `vercel.json` configuration - API routes, Route Handlers, Server Actions, server functions, or other server-side code - middleware or Edge Runtime features - redirects, rewrites, and custom headers - scheduled or cron jobs - every environment variable required in production — names only - authentication - databases - storage and file uploads - payments - email - AI APIs - webhooks - analytics or monitoring - Vercel-specific packages, SDKs, integrations, or services - any hard-coded `vercel.app`, preview, localhost, or old production URLs - anything that depends on the final production domain Pay special attention to features that may currently work because Vercel provides the runtime or infrastructure for them. Classify what you find into: 1. Portable as-is — should continue working on normal external hosting 2. Needs production configuration — portable, but requires environment variables, URLs, domains, or service settings 3. Vercel-dependent — requires a replacement or adjustment before Vercel can be removed Do not expose secret values. Do not change anything yet. Finish with: - the recommended deployment type - the exact build command - the exact start command, if required - the build output directory, if applicable - the required runtime version - a short migration checklist - anything that must be resolved before the project can leave Vercel

Prepare the Project for External Hosting

Once you understand the dependencies, prepare only what is necessary for the project to run outside Vercel.

Prepare for External Hosting

Makes only the changes needed for the project to build and run outside Vercel, preserves every existing framework, service, and integration, runs the production build, and reports what changed and whether the project is ready to deploy elsewhere.

Prepare this project to run on standard production hosting instead of Vercel. Use the migration audit you just completed. Make the smallest necessary changes. Check and fix only where required: - production build configuration - package scripts - production start command - Node.js/runtime compatibility - build output configuration - server entry point - production port handling if the project runs a server - redirects, rewrites, or headers that currently depend on Vercel - server-side functions or routes that need adjustment outside Vercel - middleware or runtime assumptions that are Vercel-specific - hard-coded Vercel, preview, localhost, or old production URLs - Vercel-specific packages or APIs that would prevent the project from running elsewhere Preserve the existing: - framework - project architecture - authentication - database structure and data - external storage - payments - email - APIs - working third-party services Do not replace an external service simply because it was connected while the project was hosted on Vercel. Never move private secrets into client-side code or commit them to the repository. Run the production build and fix any migration-related errors. Do not deploy anything yet. Do not commit or push anything yet. Finish with: 1. what you changed 2. any Vercel-specific dependencies that remain 3. the exact build command 4. the exact start command, if required 5. the build output directory, if applicable 6. the required runtime version 7. whether the project is ready to deploy outside Vercel

Get Hostinger Web App Hosting

This guide uses Hostinger to run the production version of your Vercel project.

Get Hostinger Web App Hosting

Deploy your Vercel project to Hostinger through GitHub and keep future updates connected.

USED IN THIS TUTORIAL

https://www.hostg.xyz/SHJyP

Already have Hostinger hosting? Continue below.

Set Up the Project on Hostinger

Create the replacement deployment while the Vercel version stays online. Create a new website or web app in Hostinger using the deployment type identified in the previous step.

If the project already uses GitHub, connect the same repository and production branch whenever appropriate.

Configure the project using the settings identified during the audit:

Framework or project type

Node.js/runtime version

Build command

Start command

Build output directory or server entry point

Move the Production Environment Variables

In your Vercel project, review the environment variables used by the Production environment, then add the required production values to the corresponding environment-variable settings in Hostinger.

IMPORTANT

Do not paste secret values into AI prompts. Do not commit private .env files to GitHub. Do not move server-only secrets into frontend code. Do not assume Preview, Development, and Production values are identical. Do not remove the Vercel variables yet.

Check the Production Configuration

Review the production deployment configuration before you deploy to Hostinger.

Production Configuration Check

Verifies the framework, runtime version, build and start commands, output directory, required environment variable names, and any remaining Vercel-specific dependency, then answers Ready to deploy: YES or NO.

Review the production deployment configuration for this project before I deploy it to Hostinger. Based on the codebase and the migration audit, verify: - framework/project type - package manager - required Node.js/runtime version - build command - start command - build output directory or server entry point - required production environment variable names - any production URLs that still need to be configured Also check whether any Vercel-specific dependency still prevents the project from working correctly outside Vercel. Do not ask me to paste secret values. Do not change anything. Finish with: Ready to deploy: YES / NO If NO, list only what is still missing.

Deploy the Project

Start the deployment in Hostinger and wait for the production build to complete.

IMPORTANT

Deploy to Hostinger before changing your production domain. This keeps the existing Vercel version live and available to users while you test the replacement deployment.

If the deployment fails, use the build or runtime logs to identify the problem before continuing.

Test the New Deployment

Use the temporary Hostinger URL and test the features your project actually depends on.

Homepage

Important pages and routes

Direct page refreshes

Authentication

Protected pages

Database reads and writes

API requests

Server-side routes or functions

Forms

File uploads

Images and static assets

Email

AI features

Redirects and rewrites

Mobile layout

Browser console errors

Failed network requests

Features that require the final production domain, such as some OAuth callbacks, webhooks, or payment flows, can be completed after the domain switch.

Review the New Deployment

Compare the live deployment with what the project requires before moving the production domain.

Deployment Review

Compares the live Hostinger deployment against what the project requires — routes, authentication, database access, storage, APIs, redirects, and CORS — and reports Migration test: PASS or NOT READY.

Review this new deployment before I move the production domain away from Vercel. Compare the live deployment with what the project requires. Check for migration problems involving: - failed pages or routes - direct URL refreshes - server-side routes or functions - missing or incorrect environment-variable configuration - authentication - database access - storage or file uploads - external APIs - email - payments - images and static assets - redirects or rewrites - CORS - runtime errors - browser console errors - failed network requests - remaining Vercel-specific dependencies If I provide an error or deployment log, diagnose the root cause and make only the smallest necessary fix. Do not change the production domain. Do not remove the Vercel deployment. Finish with: Migration test: PASS / NOT READY If it is not ready, list exactly what still needs to be fixed before the domain is moved.

IMPORTANT

Do not continue until the replacement deployment passes the important tests.

Check What Uses the Production Domain

Once the new deployment works correctly, move the real production domain from Vercel to Hostinger. Before changing DNS, identify every part of the project or external service that depends on the current live URL.

Production-Domain Update Checklist

Reviews the project for every URL, redirect, callback, webhook, and SEO setting tied to the live domain, then returns the exact checklist to update when the production domain switches.

The new deployment is working and I am preparing to move the production domain from Vercel to Hostinger. Review this project and create the exact production-domain update checklist. Check for: - site or app URL environment variables - authentication Site URLs - authentication redirect URLs - OAuth callback URLs - allowed origins - CORS configuration - API base URLs - webhook endpoints - payment success, cancel, return, or callback URLs - email verification links - password-reset links - storage or upload URLs if relevant - canonical URLs - sitemap configuration - Open Graph URLs - hard-coded `vercel.app` URLs - old preview or production URLs Do not change DNS. Do not expose secrets. Give me a short checklist showing exactly what must be updated when the production domain switches.

Connect the Domain to Hostinger

Add your existing production domain to the new Hostinger deployment, then update the required DNS configuration so the domain points to the new deployment.

If Vercel currently manages the DNS zone, make sure you preserve any records required for:

Professional email

Domain verification

Third-party services

Subdomains

Other existing services

IMPORTANT

Do not delete the Vercel project during this process.

Update Production Services

Apply the checklist from the previous prompt.

Update anything that requires the final domain:

Environment variables

Authentication URLs

OAuth callbacks

Allowed origins

CORS

Webhooks

Payment URLs

Email links

API URLs

SEO URLs

If production environment variables changed, redeploy the project when required.

Run the Final Migration Check

Test the most important user flows again on the real production domain, then use your AI coding assistant for a final dependency audit.

Final Migration Audit

Verifies HTTPS, routing, authentication, sessions, databases, APIs, storage, email, payments, webhooks, redirects, and scheduled jobs on the final domain, confirms nothing still depends on the old Vercel deployment, and reports Migration status: GO or NO-GO.

Run a final migration audit now that this project has moved from Vercel to its new production hosting. Verify: - the production domain reaches the new deployment - HTTPS works correctly - root domain and `www` behavior are correct, if applicable - important pages and routes work - direct page refreshes work - authentication works - sessions remain valid after refresh - password reset works if used - OAuth login works if used - private user data remains protected - database reads and writes work - APIs and server-side routes work - storage and uploads work - email works - payment flows and webhooks work if used - AI or external APIs work - redirects and rewrites work - scheduled jobs still run if the project uses them - analytics or monitoring work if required - no production request unexpectedly depends on the old Vercel deployment - no old `vercel.app` URLs remain where they should have been replaced - no required Vercel-specific service would stop working if the old deployment were removed Do not delete or disconnect anything automatically. Finish with: Migration status: GO / NO-GO If GO, list which Vercel resources are now safe to disconnect. If NO-GO, list the remaining dependencies or problems that must be solved first.

Leave Vercel Safely

Confirm nothing still required is running only on Vercel before you disconnect the old deployment.

IMPORTANT

Only remove the old Vercel deployment after the final audit returns GO.

Before doing so, confirm that the project no longer depends on any Vercel-hosted:

Functions

Cron jobs

Storage

Databases

Integrations

Environment configuration

Webhook endpoints

Other platform-specific resources

If something is still required, migrate or intentionally keep that service before removing the old deployment.

Once the migration is complete, use your Git repository as the source of truth.

Make your changes. Test the project locally. Run the production build. Commit and push the changes to GitHub. Let Hostinger redeploy the connected project. Test the important flows on the live website.

Check Before You Publish an Update

Pre-Update Safety Check

Reviews a change for build errors, environment-variable and database-migration impact, and effects on authentication, APIs, payments, storage, or email, then answers Ready to update: YES or NO.

I have made changes to this project after migrating it from Vercel. Before I publish the update: - review the changes - check for build errors - check whether environment variables changed - check whether database migrations are required - check for authentication, API, payment, storage, email, or external-service impact - run the production build Do not deploy anything automatically. Tell me whether the update is safe to push to the production branch. Finish with: Ready to update: YES / NO