Move a Replit-Built Website or Web App to Hostinger

Confirm the Replit App Works

Open the project in Replit and run it, then check:

Main page loads

The main feature works

I know whether the app is already published on Replit

If something is already broken, fix it in Replit first. Don't mix an existing bug with the hosting move.

Audit the Replit Dependencies

Use this prompt in your Replit App. It only inspects — nothing changes yet.

Check What This Replit App Depends On

Let AI inspect the project and separate portable code from Replit-specific services before anything is moved.

I want to move the production version of this existing Replit-built website or web app to Hostinger, deployed as a Node.js Web App from GitHub. Do NOT change anything yet. First inspect the current project and determine what the app depends on to run outside Replit. Never print secret values or connection strings. Report environment variable NAMES only. 1. IDENTIFY THE PROJECT Determine: - framework - language / runtime - frontend-only vs server-side / full-stack - package manager - package.json or the equivalent runtime configuration - build command - production start command, where relevant - build output directory, where relevant - entry file, where relevant - how the app currently runs in Replit (.replit run / deployment configuration) Do not guess. Use the real project. If the production app is not a JavaScript / Node.js project (for example a Python, Go or Java server), say clearly: OUTSIDE HOSTINGER NODE.JS WEB APPS Do not suggest a VPS or a manual server setup instead. 2. FIND REPLIT-SPECIFIC DEPENDENCIES Look specifically for dependencies on Replit-managed or Replit-specific services. Examples, only if present: - a Replit database - a DATABASE_URL supplied by Replit - Replit Auth - Replit App Storage (formerly Object Storage) - Replit-specific SDKs or @replit/* packages - Replit-specific environment variables (such as REPL_ID or REPLIT_DOMAINS) - Replit deployment / runtime configuration - Replit-only filesystem assumptions - replit.dev / replit.app domain or URL assumptions - callback URLs registered for a Replit domain - Replit-specific proxy, host or port behavior Do not assume these exist. Report only real findings, and say for each whether it matters in PRODUCTION or only while developing in Replit. 3. FIND PORTABLE EXTERNAL SERVICES Identify services that are already independent of Replit. Examples: Supabase, Firebase, Neon, MongoDB Atlas, Stripe, Resend, external APIs, external object storage, other hosted services. These should normally stay where they are. Do NOT plan to migrate a working external service just because the application host is changing. 4. ENVIRONMENT VARIABLES Identify every environment variable required to run the app, and classify each as: PUBLIC — safe to expose to browser code or: PRIVATE — must remain server-side Report names only. Identify which values currently come from Replit Secrets, and which are provided automatically by Replit rather than set by me. 5. DATABASE Determine exactly what database the app uses, and classify it as exactly one: EXTERNAL / PORTABLE DATABASE — the app already uses a database that stays independent of Replit. REPLIT-MANAGED DATABASE — the app uses a Replit-managed development or production database that needs special handling before independent hosting. NO DATABASE Replit Apps can have separate development and production databases. Do not assume the development DATABASE_URL is the correct production database — it may not even be reachable outside this Replit App. If the app is published, identify which database the PUBLISHED app actually reads and writes, and whether real user data lives there. 6. AUTHENTICATION Identify whether authentication uses Supabase, Firebase, Clerk, Auth0, custom auth, Replit Auth, another provider, or none. External auth providers can usually stay. If Replit Auth is used, flag it as a migration dependency. Do not invent a replacement yet. 7. FILES / STORAGE Determine whether uploaded or persistent files are stored in Supabase Storage, S3 / R2 / other external storage, Replit App Storage (Object Storage), the local filesystem, or nowhere. If production user files depend on Replit-specific or local / ephemeral storage, flag that clearly. Files must not be lost during the move. 8. PORTABILITY VERDICT Return exactly one: READY TO MOVE — the code can run on Hostinger while keeping its existing independent services. or: NEEDS PORTABILITY WORK — one or more important production dependencies are tied to Replit and must be handled first. Return: APP TYPE Framework: Runtime: Build command: Start command: Output / entry, where relevant: DEPENDENCIES Portable external services: Replit-specific services: DATABASE Current model: Production-data location: AUTH Provider: STORAGE Provider / location: ENVIRONMENT VARIABLES Public: Private: BLOCKERS Only real blockers. PORTABILITY VERDICT READY TO MOVE or NEEDS PORTABILITY WORK Do not modify anything yet.

Open Replit

Do not continue until you know where the production data, authentication and persistent files actually live.

If the report says OUTSIDE HOSTINGER NODE.JS WEB APPS, stop here — this guide's hosting path doesn't fit that project.

Remove Replit Runtime Assumptions

Use this prompt in the same session. It changes only what running outside Replit needs.

Prepare the Replit Project for Independent Hosting

Fix only the parts that prevent the app from running outside Replit while preserving its existing features and architecture.

Using the portability audit we just completed, prepare this project to run independently on Hostinger as a Node.js Web App deployed from GitHub. - Do not redesign the app. - Do not rebuild working features. - Do not migrate services that are already portable. Never print secret values. 1. REPLIT-SPECIFIC CODE For each confirmed Replit-specific dependency, decide whether it is: A. DEVELOPMENT-ONLY — safe to keep for developing in Replit, not required in production. B. CONFIGURATION-ONLY — can be made provider-neutral through environment variables or configuration. C. PRODUCTION SERVICE DEPENDENCY — needs a real migration or replacement before production can leave Replit hosting. Make only the smallest necessary change for A and B. Do not remove development-only Replit files or tooling that keep the project working in Replit. Do not try to migrate C here — list it for the next step. 2. HOST AND PORT For server-side apps, make sure the production server listens on the port the host provides through the PORT environment variable, and does not hardcode a Replit host or port. Keep a local default only for development. Do not invent a fixed production port. 3. REPLIT URLS Replace production-breaking hardcoded replit.dev / replit.app URLs only where necessary, using environment-aware production URLs. Do not blindly replace legitimate development URLs. 4. ENVIRONMENT VARIABLES Move runtime configuration into the project's existing portable environment-variable pattern where necessary. Do NOT: - hardcode secrets - expose private values through browser / public environment variables - write Replit Secrets values into source code or into any committed file Make sure local secret files are ignored by Git. 5. PACKAGE AND STARTUP Make sure: - runtime and build dependencies are declared - the build command works - production start behavior works outside Replit - no Replit-only command is required to build or boot production Do not upgrade unrelated dependencies. Run only the smallest relevant checks (build, and a type check where the project has one). Report: 1. Replit-specific assumptions found 2. Which were removed or made configurable 3. Files changed 4. Build command 5. Production start behavior 6. Environment variable NAMES required on Hostinger 7. Any remaining production service migration needed Do NOT commit or push.

Open Replit

Keep the list of environment variable names it reports — you'll add them in Hostinger.

Protect API Keys Before Deploying an AI-Built Website or Web App

Use this first if a private key turns up in browser code.

/video/protect-api-keys-before-deploying-ai-built-app

Handle Replit-Only Services

What you do here depends on your Step 1 verdict.

READY TO MOVE

No Replit-only production service needs migration. Continue to GitHub.

NEEDS PORTABILITY WORK

Use this prompt. It handles only the Replit-only database, auth or storage the audit found, and keeps everything else where it is.

Give Replit-Only Services an Independent Path

Plan and carry out only the database, authentication or storage moves the audit found, without deleting anything in Replit.

Our portability audit returned NEEDS PORTABILITY WORK. Handle ONLY the Replit-only production services it found. Do not touch services that are already independent. Never print secret values or connection strings. Never commit database exports, backups, user files or credentials to the repository. Do NOT delete, reset or disable anything in the current Replit App — its database, App Storage, Secrets or published deployment — during this work. The old production setup must stay available until the new Hostinger app is verified. 1. DATABASE If the app already uses an independent external production database: keep it. Do nothing here. If it depends on a Replit-managed database: Do NOT simply copy the development DATABASE_URL to Hostinger. First identify: - the real production database the published app uses - whether real production data must be preserved - whether that database can be reached safely and independently from outside Replit - whether a separate independent production database is required Explain your recommendation in plain language and wait for my confirmation before copying anything. If a migration is needed: - Choose a standard destination that fits the real database and project (for a PostgreSQL database, a PostgreSQL-compatible host). Do not force a provider just because it is popular. - Take a backup of the real production database first, stored outside the repository. - Copy the schema and data with a standard export/import workflow for that database. Do not recreate the schema from memory when it can be migrated. - Never overwrite a database that already holds real data without asking me. - Tell me the new connection variable NAME to set on Hostinger, and where I find its value. Do not print the value. - Verify row counts or key records match between the old and new database. 2. AUTHENTICATION If auth is already external: keep it. If the app depends on Replit Auth: STOP before pretending the move is complete, and report: REPLIT AUTH MIGRATION REQUIRED Identify the authenticated users and user-linked data that must be preserved. Do not silently replace the auth system here. Only use a provider-independent migration path if the project already clearly contains one. Otherwise report that the authentication migration is a prerequisite that needs its own workflow. 3. FILES / STORAGE If files already use independent external storage: keep it. If files depend on Replit App Storage (Object Storage) or local production files, identify: - which files must be preserved - where their references or URLs are stored in the database - what independent storage is needed Do not delete old storage. Do not claim the migration succeeded until both the FILE OBJECTS and their DATABASE REFERENCES resolve correctly. If a full storage migration becomes a substantial separate project, report it as a blocker instead of improvising one. Report: 1. Database: kept / migrated / blocked — and why 2. Authentication: kept / REPLIT AUTH MIGRATION REQUIRED 3. Storage: kept / migrated / blocked — and why 4. New environment variable NAMES for Hostinger 5. Remaining blockers Final status, exactly one: INDEPENDENT PATH READY or: BLOCKED BEFORE DEPLOYMENT Do NOT commit or push.

Open Replit

If a database has to move, the AI plans the technical work. Your part stays simple:

Confirm which database the published app really uses Make a backup Create or choose the independent production database Copy the schema and data safely Keep the new connection details for Hostinger Check the data arrived

IMPORTANT

Never put database backups, exports or credentials in GitHub. If the result is REPLIT AUTH MIGRATION REQUIRED or BLOCKED BEFORE DEPLOYMENT, stop — deploying now would launch an app that can't sign users in or find their data.

Every production service the app needs has an independent path

Put the Portable Project on GitHub

GitHub carries the code to Hostinger — and later lets every update redeploy automatically.

Before pushing, check:

The portability changes are reviewed

The project builds successfully

No .env or other secret files are being published

node_modules and other generated dependency folders are not committed

No database exports, backups or uploaded user files are included

Replit App Tools Git

In the Git pane, connect your GitHub account and push the project. If the Replit App is already connected to the right repository, use it — don't create another one.

My current portable project is available in GitHub

Get Hostinger Web App Hosting

Use a Hostinger plan that includes Node.js Web Apps.

Deploy on Hostinger

Recommended plan: Business

USED IN TUTORIAL

https://www.hostg.xyz/SHK1P

Import the GitHub Project

Hostinger Websites Add Website Node.js Web App

Choose Import Git repository Connect GitHub and authorize access if asked Select your project's repository Select the branch to deploy Let Hostinger inspect the project

Review the Detected Settings

Hostinger reads the project and suggests the framework and build settings. Compare them with your Step 1 and Step 2 reports. If they match, keep them.

If the Framework Shows Other

Enter the output directory and entry file from your reports, only where your project uses them. Don't guess common values.

Stay on this screen — you'll add the environment variables next, before deploying.

Add Environment Variables and Deploy

Replit Secrets don't travel with the code. Add each production value to Hostinger yourself.

Open the Environment variables section Add each variable from your reports with its exact name Enter its production value Click Deploy and wait for the result

IMPORTANT

Keep the public and private labels from the report — never turn a private key into a public browser variable to make a deployment work. For DATABASE_URL, use the independent production database from Step 2, not the development value from Replit.

If the app uses Supabase, Firebase or another external service, keep it — just add its production variables here.

Fix a Failed Website or Web App Deployment with AI

Use this if the Hostinger deployment fails.

/video/fix-a-failed-website-or-web-app-deployment-with-ai

Update Production URLs

Once Hostinger gives you the live URL, update only the settings your app really uses:

Sign-in redirect and OAuth callback URLs

CORS allowlists

Webhook destinations

SITE_URL, APP_URL or API base URLs

Links inside emails

Keep external services where they are and change only their allowed production URLs. If you changed a Hostinger variable, redeploy so it takes effect.

Production URL settings point to the Hostinger app

Test the Live Migration

Open the Hostinger URL and check:

Hostinger live URL opens

Main page renders

Refreshing an important route still works

The main feature works

Sign-in works, if used

Existing production data appears, if used

Saving new data works, using safe test data

Uploaded files load and upload, if used

External APIs work

No localhost or Replit-only URL is used by the live app

IMPORTANT

Do not delete or disable the old Replit production setup — app, database, storage or Secrets — until the Hostinger version has been verified. It's your fallback while you check the move.

Verify Independence

From now on: build in Replit (or any editor) → push to GitHub → Hostinger redeploys → test live.

Verify the Replit to Hostinger Migration

Confirm the live app no longer relies on accidental Replit-only production dependencies and is ready for future GitHub updates.

Perform a focused final verification of this Replit → GitHub → Hostinger migration. Do not add new features. Never print secret values or connection strings. Do not claim to inspect Hostinger dashboard state you cannot access. Ask me for the live URL if you do not have it, and ask me to confirm specific Hostinger values when needed. 1. SOURCE Verify: - GitHub contains the current approved source - real secret files are not tracked - production database exports or backups are not tracked 2. HOSTINGER Verify: - the app deployed successfully - the build / start configuration matches the real project - the required environment variable names are configured - the intended GitHub repository and branch are used 3. REPLIT DEPENDENCIES Search the production code path for the Replit-specific assumptions identified in the audit. Confirm each is: REMOVED CONFIGURED FOR MULTIPLE ENVIRONMENTS or: INTENTIONALLY STILL USED AS AN EXTERNAL SERVICE Do not flag harmless development-only Replit files just because the project can still be edited in Replit. The goal is production independence, not removing the word "Replit" from the repository. 4. DATABASE If the app is database-backed, confirm the live Hostinger app points to the intended production database — NOT development data, an obsolete shared database or an old Replit-only connection. Confirm the expected production records appear. 5. AUTH If authentication exists, verify sign-in and one authenticated action, and confirm the production URLs / callbacks are allowed by the provider. 6. STORAGE If persistent file storage exists, verify one safe test file workflow. Do not declare success if database rows load but their files are missing. 7. LIVE TEST Verify the public page, the main feature, the database / API dependency, auth where present, and storage where present. Use safe test data for writes — never modify or delete real user records to test. 8. FINAL VERDICT Return exactly one: MIGRATION VERIFIED or: NEEDS ATTENTION Use MIGRATION VERIFIED only if the Hostinger app works, the correct production services are connected, no required production dependency is still tied to the old Replit hosting runtime, expected production data is available, and required auth / storage behavior works. If NEEDS ATTENTION, list only the remaining migration blockers. 9. FUTURE UPDATES Explain the future workflow briefly. I can keep building in Replit: Replit change → review → push to GitHub → Hostinger redeploys → test live or with another AI tool or code editor: change → GitHub → Hostinger redeploys → test live The important change: production deployment now comes from GitHub and Hostinger. Do not teach Git branching and do not create a second deployment workflow.

Open Replit

Open the Hostinger version one last time and complete the main user flow before changing or removing the old Replit deployment.