.gif)
Discover why static path adjustments are essential for Lovable apps. Learn configuration tips and best practices for deploying across different hosts.
Book a call with an Expert
Starting a new venture? Need to upgrade your web app? RapidDev builds application with your growth in mind.
Static paths must be adjusted because the URL base that serves your app and assets changes between environments (local preview, Lovable Cloud preview, a custom domain, or a subpath on a host), and hard-coded or root-relative paths that work in one host will break or load wrong assets on another.
.png)
.png)
// Prompt to paste into Lovable chat:
// Ask Lovable to scan the repo and produce a precise report explaining where static paths are used and why they will break on different hosts.
// Do NOT change files; only analyze and explain per-file.
// Tasks:
// 1) Search the project for common static-path patterns (e.g., "/static/", "publicPath", "base", src="/", <link href=, <script src=, process.env.PUBLIC_URL).
// 2) For each match, list the file path, the line/snippet, and explain why that path would fail or behave differently when deployed to:
// - root domain
// - subpath (example.com/app/)
// - Lovable preview/custom domain
// - CDN or cross-origin host
// 3) Summarize places where build-time vs runtime values are used (e.g., webpack/Vite publicPath, index.html references).
// 4) Output a short recommendation header (analysis only) describing whether the issue is "host-dependent", "likely safe", or "needs runtime configuration".
// Return the report as Markdown with code references and exact file paths.
This prompt helps an AI assistant understand your setup and guide you through the fix step by step, without assuming technical knowledge.
Use a build-time environment variable (set in Lovable Cloud Secrets) and make your app read that var in the framework's config + router/asset code so the deployed site uses the correct base path. Below are ready-to-paste Lovable chat prompts (one per common stack) that tell Lovable exactly which files to edit and which secret to add.
Tell Lovable to update vite config, app entry (router basename), and add a Secret named VITE_BASE_PATH.
// Edit vite.config.ts
// set base to process.env.VITE_BASE_PATH so build uses the secret at build-time
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
export default defineConfig({
// // set base from environment when building in Lovable Cloud
base: process.env.VITE_BASE_PATH || '/',
plugins: [react()]
})
// Edit src/main.tsx (or src/main.jsx) where you set up BrowserRouter
// use import.meta.env.VITE_BASE_PATH (Vite injects VITE_* at build-time) or fallback '/'
import React from 'react'
import { createRoot } from 'react-dom/client'
import { BrowserRouter } from 'react-router-dom'
import App from './App'
const basename = import.meta.env.VITE_BASE_PATH || '/'
createRoot(document.getElementById('root')!).render(
<BrowserRouter basename={basename}>
<App />
</BrowserRouter>
)
Tell Lovable to read a Secret named REACT_APP_BASE\_PATH and use it as the router basename; update Lovable Secrets accordingly.
// Edit src/index.js (or src/index.tsx)
// set BrowserRouter basename from process.env.REACT_APP_BASE_PATH
import React from 'react'
import { createRoot } from 'react-dom/client'
import { BrowserRouter } from 'react-router-dom'
import App from './App'
const basename = process.env.REACT_APP_BASE_PATH || process.env.PUBLIC_URL || '/'
createRoot(document.getElementById('root')).render(
<BrowserRouter basename={basename}>
<App />
</BrowserRouter>
)
Tell Lovable to update next.config.js to read NEXT_PUBLIC_BASE\_PATH and to add that secret in Lovable Cloud; Next uses that at build-time for basePath and assetPrefix.
// Edit next.config.js
// set basePath and assetPrefix from environment at build-time
module.exports = {
basePath: process.env.NEXT_PUBLIC_BASE_PATH || '',
assetPrefix: process.env.NEXT_PUBLIC_BASE_PATH || '',
// keep existing config here
}
// Optional: update any manual <img> or static URL usage to prefix process.env.NEXT_PUBLIC_BASE_PATH
// so they resolve correctly when deployed under a subpath
// Example usage in React components:
const base = process.env.NEXT_PUBLIC_BASE_PATH || ''
<img src={`${base}/images/logo.png`} alt="logo" />
Connect with our team to unlock the full potential of no-code solutions with a no-commitment consultation!
.svg)
Use a single, runtime-safe base path: read a configured env var exposed at build (VITE_/PUBLIC_), provide a runtime fallback/override, centralize URL construction in one helper, set your bundler’s base to that env var, and manage the value per-environment via Lovable’s Secrets UI — then test with Lovable Preview and re-publish.
Keep one source of truth for static paths: one env var + one helper means you won’t chase hard-coded leading slashes or different behaviors between Preview, local, and deployed builds. Use Lovable Secrets to set per-environment values and Preview to validate without a terminal.
// Create src/lib/assetPath.ts with this content
// This file exports getBasePath() and asset(path) to build static URLs safely
export function getBasePath(): string {
// runtime override that Preview/hosting can set
// window.__LOVABLE_BASE_PATH__ is checked first
// import.meta.env.VITE_PUBLIC_BASE_PATH is the build-time env (Vite)
// fall back to empty string so relative paths work
// keep string normalized (no trailing slash)
// @ts-ignore
const runtime = typeof window !== 'undefined' && (window.__LOVABLE_BASE_PATH__ as string | undefined)
const build = (import.meta && import.meta.env && (import.meta.env.VITE_PUBLIC_BASE_PATH as string | undefined)) || ''
const raw = runtime ?? build ?? ''
// normalize: remove trailing slash unless it is just '/'
if (raw === '' || raw === '/') return ''
return raw.replace(/\/+$/, '')
}
export function asset(path: string): string {
// normalize path and avoid double slashes
const base = getBasePath()
const p = path.replace(/^\/+/, '')
return base === '' ? `/${p}` : `${base}/${p}`
}
// Update public/index.html (or your project's index.html) near the top <head> block:
// insert this script tag so Preview builds can auto-set a runtime base from the current path
<script>
// // set a runtime override for Preview/hosting when needed
// // Lovable Preview will serve from a path; this tries to detect subpath and set window.__LOVABLE_BASE_PATH__
(function(){
try {
// // Example heuristic: if app is served from a subpath, use location.pathname up to the app root
// // Adjust the logic if your app is not mounted at root of the path
const parts = location.pathname.split('/');
if (parts.length > 2) {
// // build base like "/my/project"
const maybeBase = '/' + parts.slice(1,2).join('/');
window.__LOVABLE_BASE_PATH__ = maybeBase === '/' ? '' : maybeBase;
}
} catch(e){}
})();
</script>
// Find files that reference absolute static paths (examples: src/App.tsx, public/manifest.json usage, UI img src).
// Replace usages like "/assets/logo.png" with asset('assets/logo.png') from src/lib/assetPath.ts.
// Example edit: update src/App.tsx in the JSX <img src="..."> to:
// import { asset } from './lib/assetPath'
// <img src={asset('assets/logo.png')} alt="logo" />
// Update vite.config.ts at the top to read env and set base
// modify export default defineConfig({...}) to set base: process.env.VITE_PUBLIC_BASE_PATH || '/'
import { defineConfig, loadEnv } from 'vite'
export default ({ mode }) => {
const env = loadEnv(mode, process.cwd(), '')
return defineConfig({
// // use build-time base so absolute imports emitted by bundler are correct
base: env.VITE_PUBLIC_BASE_PATH || '/',
// ...rest
})
}
// Use Lovable UI: open Secrets (left sidebar) -> Add secret
// Name: VITE_PUBLIC_BASE_PATH
// Value: /your/subpath (or '/' or '' for root)
// Scope: set per-environment (Preview/Production) in Lovable Cloud
// After changing a secret, use Lovable Publish to rebuild the app so the build-time value is applied.
If you need help tailoring the helper to Next.js, SvelteKit, or another bundler, paste your repo tree and I’ll create the exact edits for those files.
From startups to enterprises and everything in between, see for yourself our incredible impact.
They do complex work on extremely fast timelines and effectively manage the testing and pre-launch process to deliver the best possible product. I'm extremely impressed with their execution ability.
