Is your feature request related to a problem? Please describe.
The standalone server is only accessible as a single page app at the root path. This presents challenges when attempting to host it behind a common domain name shared by other services. For example, if hosting an app at www.myapp.com, the Nginx routing must reserve the following paths for the Capjs stand alone server:

• 'www.myapp.com
• 'www.myapp.com/'
• 'www.myapp.com/server/'
• 'www.myapp.com/auth/login'
• 'www.myapp.com/public'

Although it is possible to have Nginx route the Capjs single-page app root (www.myapp.com) from another location ( www.myapp.com/capjs => localhost:3000), the API calls and static assets will still load from the root domain absolute paths.

Describe the solution you'd like
An optional BASE_PATH environment variable would allow the Capjs standalone server to support a subpath such that the single-page app could be access at that subpath, and all API calls and asset loading would be relative to that path.

Proposed Changes

Server-Side Changes

• Update all Elysia route prefixes in auth, server, assets, and cap modules to include BASE_PATH
• Modify static file serving to handle BASE_PATH with custom route for multi-level paths
• Add redirect route from base path 'without trailing slash' to 'with trailing slash' for proper relative path resolution
• Add BASE_PATH normalization logic to ensure paths start with / and don't end with /
• Update console logging to display configured BASE_PATH and endpoint URLs

Frontend Changes

• Modify login form to dynamically detect base path from current URL for authentication calls
• Update API client to auto-detect base path from window.location.pathname for all server API calls
• Ensure relative static asset paths work correctly with trailing slash requirement

Example .env:
BASE_PATH=/cap

Example Nginx (abbreviated)
location /cap/ {
proxy_pass http://127.0.0.1:3000/cap;
}

Describe alternatives you've considered
Obtaining a new DNS name and VIP dedicated to Capjs was considered. This would work by serving it on its own endpoint, but requires extra management (more vips, more nginx, CORS configuration, certificates, etc.)

Explicitly configuring Nginx to Route each known Capjs path was also considered. This would require avoiding conflicts with capjs paths by limiting our application paths, including not using /public or our static files. This would also be brittle when paths are added to Capjs in future versions.

Additional context
A branch of v2.0.9 has been created for the changes necessary to support these features. These changes keep the BASE_PATH optional and ensured backwards compatibility is maintained for current usages of the stand-alone server. These changes can be provided as a Pull Request if desired.