Deploy Frontend and Backend Separately to Production

Map the Frontend and Backend for Deployment

Before deploying anything, identify exactly how the frontend and backend communicate and what each service needs in production.

Frontend & Backend Production Map

Maps the frontend's build/runtime configuration and every frontend environment variable, and the backend's framework, start command, port handling, database, CORS, cookies and every backend environment variable, then reports how the two connect — API URL, authentication method, and whether they need a shared or separate domain — without exposing secret values or changing anything yet.

Review this project specifically for deploying the frontend and backend as separate production services. Identify the frontend and backend separately. For the frontend, identify: - framework and project type - package manager - production build command - build output directory - whether it is static or requires its own server runtime - required Node.js/runtime version, if applicable - every frontend environment variable — names only - the current API base URL - authentication-related configuration - any hard-coded localhost or development backend URLs For the backend, identify: - framework or server library - package manager - production build command, if required - production start command - server entry point - required Node.js/runtime version - how the server receives its production port - every backend environment variable — names only - database connection - authentication/session handling - CORS configuration - cookies - file uploads or storage - email - payments and webhooks - external APIs - scheduled jobs - WebSockets or realtime features Also identify: - how the frontend currently calls the backend - whether authentication uses cookies, bearer tokens, or another method - whether the frontend and backend must share a domain or can use separate domains - any callback, redirect, webhook, or allowed-origin URLs - anything that currently depends on localhost - anything that will depend on the final production domains Do not expose secret values. Do not change anything yet. Finish with a production map in this format: Frontend: - deployment type - build command - output/start configuration Backend: - deployment type - build command - start command - runtime Connection: - production API URL needed by the frontend - allowed frontend origin needed by the backend - authentication method between them External Services: - database - storage - email - payments - other APIs Then list anything that must be fixed before deployment.

Prepare the Backend

Prepare the frontend and backend without combining them into one application. The backend must be able to run independently from the frontend — preserve the existing architecture unless there is a genuine production blocker.

Has a valid production start command

Uses the hosting platform's assigned port

Connects to production services through environment variables

Does not depend on localhost

Accepts requests only from the required frontend origins

Keeps private credentials server-side

Prepare the Frontend

The frontend must use the production backend URL instead of a local API URL.

Do not hard-code the final URL when the project already uses environment variables appropriately.

Separate Production Preparation

Fixes production scripts, port handling, environment-variable loading, CORS/allowed origins, secure cookies, and hard-coded localhost URLs on both services while keeping them separate and making only the smallest necessary changes — enforces that backend secrets and credentials never reach frontend code and that CORS is never opened to every origin — then reports READY or NOT READY for each service with the exact build/start commands and environment-variable names.

Prepare this project for separate frontend and backend production deployment. Keep the two services separate. Make the smallest necessary changes. For the backend, check and fix where required: - production scripts - build configuration - start command - runtime compatibility - production port handling - environment-variable loading - database connection - CORS - allowed origins - authentication/session configuration - secure cookies - file/storage configuration - callback and webhook URLs - hard-coded localhost URLs For the frontend, check and fix where required: - production build configuration - environment-variable usage - API base URL configuration - authentication requests - credentials/cookie handling if required - hard-coded localhost backend URLs Security requirements: - private backend secrets must never be exposed to frontend code - database credentials must stay server-side - payment/email/private API credentials must stay server-side - do not use permissive CORS such as allowing every origin when authenticated/private APIs are involved unless the application genuinely requires it Preserve the existing project architecture and framework choices. Do not merge the frontend and backend into one application. Run the relevant production builds and fix deployment-related errors. Do not deploy anything yet. Finish with: Frontend: READY / NOT READY Backend: READY / NOT READY Then provide the exact: - frontend build command - frontend output/start configuration - backend build command, if required - backend start command - backend runtime version - frontend production API environment-variable name - backend production allowed-origin environment-variable name, if one exists

Get Hostinger Node.js Hosting

Deploy the backend before the frontend. This gives you a real production API URL that the frontend can use. This tutorial uses Hostinger to run the production backend.

Get Hostinger Node.js Hosting

Deploy your Node.js backend from GitHub with production environment variables.

USED IN THIS TUTORIAL

https://www.hostg.xyz/SHJyP

Create the Backend Application in Hostinger

Create the backend application in Hostinger and connect its GitHub repository or backend directory, depending on the project structure.

Websites Add Website Deploy Web App

Connect the backend repository or directory Set the Node.js/runtime version Set the install command Set the build command, if required Set the start command and server entry point Add the production environment variables

Add the Backend's Private Production Values

Add the backend's private production values directly through the hosting environment rather than committing them to GitHub.

Database URL

Authentication/session secret

JWT secret

Storage credentials

Email credentials

Payment secrets

Webhook secrets

Private external API keys

AI API keys

IMPORTANT

Never commit these values to GitHub.

Deploy and Test the API

After deployment, note the temporary or production backend URL, then test the backend independently before connecting the frontend.

Example Backend URL

https://api.example.com

Or the temporary URL provided before the custom domain is connected.

Deployed Backend Review

Checks server startup, runtime logs, port handling, required environment variables, database connectivity, public and protected API endpoints, authentication and session/token behavior, CORS, storage, email, payments, webhooks, and external APIs — diagnoses the root cause of any error or log you provide without weakening authentication, authorization, or CORS, and without exposing secrets — then returns PASS or NOT READY with exactly what remains.

Review the deployed backend before I connect the frontend to it. Check: - server startup - runtime logs - production port handling - required environment variables - database connectivity - public API endpoints - protected API endpoints - authentication - session/token behavior - CORS configuration - storage/uploads - email - payments - webhooks - external APIs - runtime errors If I provide an error or deployment log, diagnose the root cause and make only the smallest necessary fix. Do not weaken authentication, authorization, or CORS simply to make a request succeed. Do not expose secrets. Do not deploy automatically. Finish with: Backend status: PASS / NOT READY If NOT READY, list exactly what remains.

IMPORTANT

Do not continue until the backend is responding correctly.

Set the Production API URL

Once the backend works, update the frontend's production environment variable so API requests go to the deployed backend.

Example Production API URL Variable

VITE_API_URL=https://api.example.com

Or the equivalent variable already used by the project. Use the project's existing environment-variable naming rather than creating a new convention unnecessarily.

Configure CORS for the Frontend Origin

On the backend, allow requests from the actual frontend production origin.

Frontend

https://example.com

Backend

https://api.example.com

If authentication uses cookies across origins, verify the application's credential, cookie, SameSite, Secure, and CORS configuration carefully.

IMPORTANT

Do not simply use Access-Control-Allow-Origin: * as a universal fix for authentication problems.

Deploy the Frontend

Configure the frontend deployment, then deploy it.

Websites Add Website Deploy Web App

Set the production branch Set the build command Set the output directory or start configuration Set the runtime, if required Add the client-safe environment variables Deploy the project

Frontend-to-Backend Connection Review

Verifies the frontend's production API URL, remaining localhost references, backend allowed origin and CORS, credentialed requests, authentication tokens/cookies and their production security settings, exposed environment variables, API route availability, and HTTPS — pays particular attention to cookie behavior across different subdomains — without weakening security controls — then returns READY or NOT READY with exactly what must be corrected.

The backend is deployed and I am now connecting the production frontend to it. Review the frontend-to-backend production configuration. Verify: - the frontend is using the correct production API URL - there are no remaining localhost API URLs - the backend allows the correct frontend origin - CORS is configured appropriately - browser requests use credentials when required - authentication tokens or cookies are handled correctly - secure cookie settings are correct for production - no backend secrets are exposed through frontend environment variables - API routes used by the frontend exist in production - HTTPS is used for production communication If frontend and backend use different subdomains, pay particular attention to authentication and cookie behavior. Do not weaken security controls to make cross-origin requests work. Do not deploy automatically. Finish with: Frontend/backend connection: READY / NOT READY If NOT READY, list exactly what must be corrected.

Connect Your Final Production Domains

Once both services work, connect the final domains and test the application as one complete system.

A common setup is example.com for the frontend and api.example.com for the backend. You may use a different architecture if the existing project requires it.

Update Anything That Depends on the Final URLs

After connecting the domains, review anything that depends on the final URLs.

Frontend API URL

Backend allowed origins

CORS

Authentication callback URLs

OAuth redirect URLs

Cookie domains

Payment return URLs

Webhook endpoints

Email confirmation URLs

Password-reset URLs

External service callbacks

Canonical URLs

Final Production URL Review

Reviews the frontend's API base URL, backend allowed origins and CORS, cookie domain/security settings, authentication and OAuth redirects, payment and webhook URLs, email verification and password-reset URLs, external service callbacks, and any remaining localhost or temporary deployment URLs — without exposing secrets — then returns only the production URL updates this project actually needs.

The frontend and backend now have their final production domains. Review the project for anything that still needs the final URLs. Check: - frontend API base URL - backend allowed origins - CORS - cookie domain and security settings - authentication redirects - OAuth callbacks - payment return/callback URLs - webhook endpoints - email verification URLs - password-reset URLs - external service callbacks - hard-coded localhost or temporary deployment URLs Do not expose secrets. Give me only the production URL updates that are actually required for this project.

Apply the required changes and redeploy the affected service if necessary.

Run the Final Production Test

Test the application through the real frontend.

Pages and navigation

Frontend → backend requests

Signup

Login

Logout

Session persistence

Protected pages

Protected API routes

Database reads and writes

Private user data

File uploads

Email

Payments

Webhooks

External APIs

Error handling

HTTPS

Mobile behavior

Browser console

Failed network requests

Final Production-Readiness Audit

Runs a full production-readiness audit across HTTPS on both domains, correct frontend-to-backend wiring, CORS, authentication/session behavior, protected frontend and backend routes, private-data access, database and storage operations, email, payments/webhooks, external APIs, and server-only credential handling — without weakening any security control to pass — then returns GO or NO-GO with exactly what remains before launch.

Run a final production-readiness audit for this separately deployed frontend and backend. Verify: - the frontend domain works over HTTPS - the backend/API domain works over HTTPS - the frontend uses the correct production backend - no localhost or temporary API URLs remain - CORS allows the required frontend and does not unnecessarily expose private APIs - signup/login/logout work - sessions or authentication tokens work correctly - protected frontend areas remain protected - protected backend endpoints remain protected - users cannot access private data they do not own - database reads and writes work - uploads/storage work - email works - payments and webhooks work if used - external APIs work - private backend credentials remain server-only - no important browser, network, or backend runtime errors remain Do not weaken any security control to make the final test pass. Finish with: Production status: GO / NO-GO If NO-GO, list exactly what remains before launch.

Treat the frontend and backend as separate deployments. When an update affects only one service, deploy only that service when possible. Before changing an API used by the frontend, check compatibility between both versions.

Check Before You Publish an Update

Pre-Update Safety Check

Identifies whether a change affects the frontend, backend, or both, runs the relevant production builds/tests, and checks for new environment variables, frontend/backend API compatibility, required database migrations, authentication/session impact, CORS or production-domain changes, and storage/email/payment/webhook/external-API impact — then tells you exactly which service or services need to be redeployed, without deploying automatically.

I have made changes to this separately deployed frontend/backend project. Before publishing: - identify whether the change affects the frontend, backend, or both - run the relevant production builds/tests - check for new environment variables - check API compatibility between frontend and backend - check whether database migrations are required - check authentication/session impact - check CORS or production-domain changes - check storage, email, payment, webhook, or external API impact Tell me which service or services actually need to be redeployed. Do not deploy automatically. Finish with: Ready to update: YES / NO