Skip to content

Deploying a Vite site under a subdirectory

development

A Vite build published below a path such as /portal/ needs asset URLs and router configuration that agree with that location.

Check access and requirements

Confirm the final public base path and whether a frontend router is used. Keep the build output separate from the source project and private configuration.

01 Deploy a Vite site under a subdirectory

  1. Set the Vite public base option to the intended deployment path before building. Use the appropriate documented relative-base behavior only when that is the planned architecture.

  2. Configure the client router’s base or basename consistently. A correct asset prefix does not automatically change the router’s own URL assumptions.

  3. Build the project with its locked dependencies and publish the generated output into the matching server directory.

  4. Configure a fallback for application routes under that path where required. Exclude existing assets and unrelated API or website paths from the fallback.

  5. Test the entry page, a nested route, a browser refresh and navigation back to the parent website.

02 Example: build Vite assets for the /portal/ directory

For a site published at https://example.com/portal/, merge this base-path setting into the existing Vite configuration before the production build. Keep other plugins and project settings in place.

Code or configuration example
import { defineConfig } from 'vite';

export default defineConfig({
  base: '/portal/',
});

Deploy the generated dist contents into the matching portal document directory. If the application has a browser router, configure its base or basename separately to agree with the same path. A server rewrite can support direct route visits, but it cannot repair asset addresses already built with the wrong prefix.

Expected result: The browser requests JavaScript and CSS below /portal/, and a direct visit to a supported inner route works. A missing asset still fails normally, while the parent website at / keeps its own routing and content.

Confirm the expected result

Inspect CSS and JavaScript requests and confirm they use the intended prefix. Check that an unknown asset is not returned as the application HTML with an incorrect content type.

Resolve setup problems

If the page is blank, distinguish missing assets from a router error. Review the browser console and network responses before changing the server’s main document root.

A common question

Can I fix every path problem with a rewrite to index.html?

No. Rewrites do not correct asset URLs already embedded in the build, and overly broad rules can intercept real files or API requests.

Sources and further reading

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support