feat(frontend): support configurable base path for subpath deployments

[debreczi]

Summary

Infisical's frontend cannot be served under a URL subpath (e.g. https://company.com/infisical/) because the Next.js app is built without a basePath. All internal links, asset references, and API calls are hardcoded to resolve from /, which makes subpath deployments impossible with the prebuilt Docker image.

Problem

Many organizations run multiple services under a single domain (e.g. Kubernetes clusters with a shared Ingress). Hosting Infisical requires a dedicated subdomain or domain today. Subpath routing — a common enterprise pattern — is not supported.

The existing SITE_URL environment variable only affects the backend (email callbacks, OAuth redirect URIs). It has no effect on the Next.js frontend routing, asset paths, or client-side navigation.

Expected behavior

When a NEXT_PUBLIC_BASE_PATH (or similar) build argument is provided, the Next.js app should:

set basePath and assetPrefix in next.config.js
prefix all internal hrefs, router.push() calls, and /_next/ asset paths with the base path
allow SITE_URL to include the subpath (e.g. https://company.com/infisical) for backend-generated URLs
Proposed implementation

// frontend/next.config.js
const basePath = process.env.NEXT_PUBLIC_BASE_PATH || '';

const nextConfig = {
basePath,
assetPrefix: basePath ? basePath + '/' : '',
// ... rest of config
};
With this change, the Docker image can be built with a build argument:

docker build
--build-arg NEXT_PUBLIC_BASE_PATH=/infisical
-t infisical:custom .
Or, if the team prefers to ship official images with this enabled at runtime, an alternative approach using Next.js App Router's server-side env reads could be explored — though that would require migrating away from Pages Router static export patterns.

Use case

Kubernetes cluster with a shared Ingress and a single wildcard cert. Multiple internal tools are routed by path under one domain. Adding a subdomain requires DNS changes and certificate updates that may not be feasible in all enterprise environments.

Workaround today

Clone the repo, manually patch next.config.js, build a custom image, and maintain it across Infisical releases. This is fragile and blocks adoption of official updates.