Skip to content

feast ui does not work on proxy subpath #3481

Closed

Description

@jiewpeng

Expected Behavior

Feast UI should work when it is served behind a proxy, on a subpath e.g. /feast-ui

Current Behavior

Parts of the feast UI works behind a subpath, but not entirely (nothing is displayed, just the feast logo with a "404" text - refer to screenshot). No requests in the network tab of the web browser are hitting 404.

image

Steps to reproduce

Serve feast UI as you would e.g. feature_store.serve_ui(), optionally passing in the root_path parameter (it does not help).

Set up an nginx pod with the following configuration (i.e. the nginx pod should have /etc/nginx/conf.d/default.conf with the following contents - dummy_project is the project name, and http://feast-ui-service:8080 is where the feast UI can be accessed from your nginx pod / container):

server {
  listen 80 default_server;

  location = /feast-ui/ {
      rewrite (.*) /feast-ui/p/dummy_project permanent;
  }

  location /feast-ui/ {
      proxy_pass http://feast-ui-service:8080/;
  }

  location / {
      proxy_pass http://feast-ui-service:8080/;
  }
}

This configuration works on localhost when nginx can listen on the root path /. However, note that the URL after all the redirects is wrong (it does not have the prefix).

  • The first block is required to force a redirect to the /p/{project_name}. Without this, the page will display 404 as above.
  • The second block is required to strip away /feast-ui so the UI app does not receive that path that it is not aware of
  • The third block is a trick to make this setup work in a local environment, because the app itself will redirect the user back to /p/dummy_project (without the prefix), which we then proxy into the feast UI app. However, in an actual environment, this setup does not work, because when the url does not contain the /feast-ui prefix, the ingress will not route it to the nginx pod, so the nginx pod cannot proxy the connection to the right place.

Ideally, if the feast ui app is capable of being served on a subpath, only the second location block should be required in the nginx configuration. The first and third location blocks are workarounds.

Specifications

  • Version: 0.29.0

Possible Solution

The app should redirect to relative and not absolute paths

Activity

  1. added 3 commits that reference this issue on Feb 7, 2023
  2. sudohainguyen commented on Mar 2, 2023

    @sudohainguyen
    Collaborator

    I have done it successfully for my project with extra customizations, feel free to ping me to discuss more

  3. MansoorSyed1311 commented on Apr 3, 2023

    @MansoorSyed1311

    still this error is encountering what is the possible solution for this error @sudohainguyen

  4. asinafuthiman commented on Jun 20, 2023

    @asinafuthiman

    @sudohainguyen This is still not working for me. My Feast version is 0.31.1 on Amazon Linux 2, and I'm using --root_path flag, but none of the links in the returned html is prefixed with the root path. Could you share some more details about your extra customizations? Do we need some specific customizations to make it work?

    Also, can someone reopen this issue?

  5. bennfocus commented on Sep 13, 2023

    @bennfocus
    Contributor

    Same here as @simonrouse9461 described, the --root_path didn't work.

    @sudohainguyen What did you do to make it work?

  6. Gsbreddy commented on Jun 3, 2024

    @Gsbreddy

    Same here as @simonrouse9461 described, the --root_path didn't work.

    @sudohainguyen What did you do to make it work?

  7. reopened this on Jun 3, 2024
  8. boumelhaa commented on Aug 30, 2024

    @boumelhaa

    Guys, do we have an update on this issue, the --root_path doesn't seem to solve it

  9. stale commented on Apr 26, 2025

    @stale

    This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

  10. csanadpoda commented on Feb 19, 2026

    @csanadpoda

    Why was this closed? Issue is still not resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions