Deploy a Codex-Built Website or Web App to Hostinger

Run the Project

Start the project the way you normally run it while building, then check:

Main page loads

Important navigation works

The main feature works

No obvious build or runtime error

If the project is already broken, fix that first. Deploying won't fix an existing bug — it only makes it harder to find.

Check Deployment Readiness

Open the project in Codex and use this prompt. It only inspects — nothing changes yet.

Check the Project for Hostinger

Let Codex inspect the project, identify its framework, build settings and required environment variables, and find deployment blockers before anything is changed.

I want to deploy this existing project to Hostinger as a Node.js Web App through GitHub. Do NOT change anything yet. First inspect the current project and prepare a deployment-readiness report. Never print secret values. Report environment variable NAMES only. 1. IDENTIFY THE PROJECT Determine: - framework - frontend-only vs server-side/full-stack - package manager - Node.js requirements, if relevant - package.json scripts - build command - production start behavior, if the app has a server - build output directory, where relevant - entry file, only if the runtime genuinely requires one Do not guess. Use the actual project configuration. 2. CHECK PACKAGE.JSON Confirm: - package.json exists - dependencies required at build time and runtime are declared correctly - the build script exists where required - the production start script exists if this is a persistent server-side Node.js app Do not rewrite package.json merely to make it look cleaner. 3. FIND ENVIRONMENT VARIABLES Identify every environment variable the deployed app actually expects, and classify each one as: PUBLIC — safe to expose to browser code or: PRIVATE — must remain server-side Examples may include API URLs, a Supabase Project URL, a Supabase Publishable key, server API keys, database URLs, Stripe secrets, webhook secrets and authentication secrets. Use the project's real variables. Do not invent values. Do not print secret values from existing local environment files. Also list any setting that depends on the final production URL, such as authentication redirects, OAuth callbacks, CORS allowlists, webhook URLs or APP_URL / SITE_URL. 4. CHECK FOR EXPOSED SECRETS If a private credential is currently embedded in browser or client code: STOP. Report: PRIVATE SECRET EXPOSED Do not continue pretending the project is deployment-ready. Point me to Profit Studio's existing API-key protection workflow ("Protect API Keys Before Deploying an AI-Built Website or Web App") and do not duplicate that guide here. Public browser configuration, such as legitimate Vite VITE_* or Next.js NEXT_PUBLIC_* values, should not automatically be treated as secrets. Judge each value by what it actually grants access to. 5. CHECK HOSTING COMPATIBILITY Look for anything tied to another hosting platform or to the local machine that could break on Hostinger. Examples, only when present: - Vercel-specific runtime assumptions - Netlify-specific functions - platform-specific serverless APIs - hardcoded localhost URLs - local filesystem paths - a local-only database connection - development-only proxy assumptions - unsupported persistent filesystem behavior - missing production start behavior - build output assumptions Do not assume these problems exist. Only report what the real project uses. If the project fundamentally needs custom server infrastructure that a managed Node.js Web App cannot provide, say so clearly instead of suggesting a VPS or manual server setup. 6. EXTERNAL SERVICES If the app already uses an external service such as Supabase, MongoDB Atlas, Firebase, an external API or a hosted database, do NOT migrate it just because the website is moving to Hostinger. Preserve the existing architecture where possible. 7. ROUTING Inspect client-side and framework routing, and determine whether the framework needs any special production handling. Do not invent .htaccess rules if Hostinger's managed Node.js deployment already handles routing. Use the current Hostinger deployment model. Return: DEPLOYMENT READINESS Framework: App type: Build command: Start command, if needed: Output directory, if relevant: Entry file, if relevant: ENVIRONMENT VARIABLES Public: Private: Settings that need the live URL: BLOCKERS List only real blockers. HOSTINGER SETUP EXPECTED Explain what Hostinger should normally auto-detect and what may require manual configuration. FINAL VERDICT READY TO PREPARE or NEEDS FIXES Do not modify any files yet.

Continue only after the report identifies the correct framework, build behavior and environment variables.

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

Use this first if the report says PRIVATE SECRET EXPOSED.

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

Fix Deployment Blockers

Use this prompt in the same Codex session. It changes only what deployment needs.

Prepare the Project for Hostinger

Fix only the deployment blockers found in the readiness check without redesigning or refactoring the app.

Using the deployment-readiness report we just confirmed, prepare this project for Hostinger deployment. Fix ONLY issues required for production deployment. - Do not redesign the website or web app. - Do not refactor unrelated code. - Do not add features. - Do not change working architecture without a deployment reason. Never print secret values. 1. PACKAGE AND BUILD Make sure the existing project has the correct: - dependencies - build command - production start behavior, where required Follow the framework's existing conventions. Do not replace the framework. Do not upgrade unrelated packages. 2. ENVIRONMENT VARIABLES Replace hardcoded environment-specific values only where necessary, using the project's existing environment-variable convention. Do NOT: - hardcode private credentials - expose private server keys through browser variables - commit .env files containing real secrets Make sure local secret files are ignored if they are not already. Do not remove legitimate public configuration from the client just because its name contains "key". 3. LOCALHOST Remove or parameterize production-breaking localhost URLs only where required. Do not globally replace every localhost occurrence without understanding it. Development-only localhost configuration may remain where appropriate. 4. PLATFORM-SPECIFIC CODE If the project contains a genuine blocker tied to another host, make the smallest provider-neutral or Hostinger-compatible change. Do not rewrite the project just because another deployment platform is mentioned in a config file. 5. VERIFY Run only the project's smallest relevant checks. Where applicable: - build - type check or an equivalent lightweight validation If the build fails, fix only the deployment-related failure. Do not perform unrelated cleanup. Report: 1. Files changed 2. Deployment blockers fixed 3. Build command 4. Production start behavior, if relevant 5. Environment variable NAMES required on Hostinger 6. Any value that must remain private 7. Any blocker still unresolved Do NOT commit or push yet.

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

Put the Project on GitHub

GitHub is what lets Hostinger redeploy your app every time you push an update.

Before pushing, check:

The project builds successfully

No .env or other secret files are being published

All required source files are included

node_modules and other generated dependency folders are not committed

Then put the project on GitHub using your normal Codex or GitHub workflow. If the project already has a repository, use it instead of creating another. If Codex opened a pull request, merge it into the branch you'll deploy.

My latest project code 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 Repository

Hostinger Websites Add Website Node.js Web App

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

Review the Detected Settings

Hostinger reads package.json and suggests the framework and build settings. Compare them with your Step 1 report. If they match, keep them.

If the Framework Shows Other

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

If the detected framework doesn't match your project, stop and compare it with the Step 1 report. Don't click through an obviously wrong configuration just to reach Deploy.

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

Add the Environment Variables

On the same settings screen, add every variable from your Step 2 report.

Open the Environment variables section Add each variable with its exact name Enter its production value

IMPORTANT

Keep the public and private labels from the report. Never turn a private key into a VITE_ or NEXT_PUBLIC_ variable to make the deployment work. If browser code in a frontend-only app needs a private secret, stop and fix that first.

If the app uses Supabase or another external database, keep it — just add its production variables here. The app's Hostinger dashboard also has an optional Connect helper for Supabase and MongoDB Atlas.

If your report listed settings that need the live URL — sign-in redirects, OAuth callbacks, CORS allowlists, webhooks or APP_URL / SITE_URL — update them once Hostinger gives you the URL.

Deploy the App

Do one final check, then deploy.

Detected framework matches your Step 1 report

Build settings match the report

Environment variables are added

The correct branch is selected

Click Deploy and wait for the result. When it succeeds, open the live URL.

If the Deployment Fails

Don't change settings at random. Copy the actual error Hostinger shows and use this prompt in Codex.

Fix the Hostinger Deployment Error

Give Codex the real Hostinger build error and let it fix only the deployment blocker.

My Codex project failed to deploy on Hostinger. Here is the actual Hostinger deployment/build error: [PASTE THE ERROR HERE] We already completed the deployment-readiness check. Inspect the current project and compare this error with: - package.json - the build script - production start behavior - framework configuration - environment variable names - the Hostinger build settings Find the smallest real cause. - Do not redesign the app. - Do not upgrade unrelated dependencies. - Do not change unrelated features. - Do not expose private secrets. If the problem is a Hostinger setting rather than code, tell me exactly which setting is wrong. If the problem is code or configuration, fix only that blocker. Then run the smallest relevant local validation. Report: - root cause - exact change - files changed - Hostinger setting to use - how to redeploy Do not commit, push or deploy automatically.

After a code fix, push it to GitHub the way you normally do and the connected deployment runs again. After a settings fix, change the setting in Hostinger and redeploy.

Test Production

Open the live URL and check:

Live URL opens

Main page renders correctly

Refreshing an important route still works

The main feature works

Database or API connections work, if used

Sign-in works, if used

No private secret is visible in the browser

Mobile layout has no deployment-only breakage

Uses sign-in or OAuth? Add the live URL to your auth provider's allowed redirect URLs if it requires them.

Verify Deployment and Future Updates

From now on, every update follows one loop: change it in Codex → review → push to GitHub → Hostinger redeploys → test the live app.

Verify the Hostinger Deployment

Check the live app against the local project and confirm the GitHub deployment path is ready for future updates.

Perform a focused final verification of this Codex → GitHub → Hostinger deployment. Do not add new features. Never print secret values. Do not claim to inspect Hostinger dashboard state you cannot access. Ask me for the live URL if you do not have it, and for any deployment detail that must be visually confirmed. 1. LOCAL / SOURCE Verify: - the project still builds successfully - the required production environment variable names are documented - private secret files are not tracked in Git 2. LIVE APP Verify: - the production URL loads - important routes work - the main feature works - required external API and database connections work - no localhost-only dependency remains in the production path 3. SECRETS Verify: - private credentials remain server-side - no private secret was converted into a public browser variable - no real .env secret file was committed 4. HOSTINGER Verify: - the expected framework and build configuration is being used - the GitHub repository and intended branch are connected - the deployment completed successfully 5. AUTOMATIC UPDATES Explain briefly that future pushes to the connected branch can trigger a Hostinger redeployment. Keep the future workflow simple: Codex change → review → GitHub → Hostinger redeploys → test live Do not teach Git branching, and do not create a second deployment workflow. 6. FINAL VERDICT Return exactly one: DEPLOYMENT VERIFIED or: NEEDS ATTENTION If DEPLOYMENT VERIFIED, summarize: - framework - repository - deployment method - environment variable status - live verification result If NEEDS ATTENTION, list only the remaining deployment problems.

Open the live app yourself one last time and test the main feature before sharing the URL.