Skip to content

Configurable runtime base path for reverse-proxy deployments #46

Description

@johnthagen

Disclaimer: I had Codex 5.6 Sol help prepare this issue summary, but I have reviewed and modified the output

Summary

Please add runtime support for hosting ai-chat-ui beneath a URL prefix such as /chat/.

This is needed when the UI is deployed behind a reverse proxy alongside other applications:

  • / → main application
  • /docs/ → documentation
  • /chat/ → Pydantic AI chat UI

Current behavior

With ai-chat-ui 2.1.0 served at /chat/, starting a conversation changes the browser URL to:

/<conversation-id>

The UI also requests API endpoints using root-relative URLs:

/api/chat
/api/configure

These URLs escape the/chat/ namespace. The conversation URL may then be handled by the main application, and the API paths can conflict with other services.

An HTML <base> element does not fully solve this because the UI directly modifies URL.pathname and uses root-relative API URLs.
The current offline bundle can only be made to work by patching its minified JavaScript or reserving root-level routes in the reverse proxy.

Requested behavior

Provide a supported runtime configuration for the public base path, for example:

<script>
  window.PYDANTIC_AI_CHAT_CONFIG = {
    basePath: "/chat/"
  };
</script>

A meta element, initialization option, or another runtime mechanism would also work.
The configured base path should apply consistently to:

  • Conversation URLs, such as /chat/
  • Browser history and navigation
  • /chat/api/chat
  • /chat/api/configure
  • Reloading or directly opening a conversation URL

The default should remain / for backward compatibility.

Runtime configuration is particularly important for the official single-file offline bundle because users cannot supply a Vite build-time base without rebuilding the project.

Why this is broadly useful

Hosting applications below a path prefix is common with:

  • Kubernetes ingress controllers
  • NGINX, Apache, and Traefik reverse proxies
  • JupyterHub and similar multi-user platforms
  • Enterprise application portals
  • Air-gapped and on-premises deployments

Supporting a configurable base path would let these deployments use the official offline artifact unchanged, avoid route collisions, and remove the need for fragile patches to minified JavaScript.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions