promptfoo / promptfoo

Test your prompts, agents, and RAGs. Use LLM evals to improve your app's quality and catch problems. Compare performance of GPT, Claude, Gemini, Llama, and more. Simple declarative configs with command line and CI/CD integration.

Home Page:https://www.promptfoo.dev/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Share button in UI doesn't go to self-hosted url

NathanKarthik1996 opened this issue · comments

Hello,

When I set the env variables for PROMPTFOO_REMOTE_API_BASE_URL and PROMPTFOO_REMOTE_APP_BASE_URL I am able to send the evals to my self hosted server via cmd line. If I were to use the share button, it seems to be going to the default API server, not quite sure why, the source code seems to check for the env variable but doesn't quite seem to work.

I had this issue as well, and the solution was to add the following environment variable in the Dockerfile before building the image:

ARG NEXT_PUBLIC_PROMPTFOO_REMOTE_APP_BASE_URL
ENV NEXT_PUBLIC_PROMPTFOO_REMOTE_APP_BASE_URL=${NEXT_PUBLIC_PROMPTFOO_REMOTE_APP_BASE_URL}

and when building the docker image, include the build arg:
--build-arg NEXT_PUBLIC_PROMPTFOO_REMOTE_APP_BASE_URL=http://<BASE_URL>

(Similarly you can specify NEXT_PUBLIC_PROMPTFOO_REMOTE_API_BASE_URL in the same way, which will send all eval api calls to your own domain, but I haven't found a reason to do this)

Someone should correct me if I am wrong, but it seems like the build stage of the Dockerfile uses the environment variables set in the Dockerfile (or in src/web/nextui/.env.production as noted in the Dockerfile comments) to build the nextjs app. The nextjs app uses the constants:
image
which seem to be set at build time? As a result, any environment variables added after the image is built cannot be injected back into the UI's logic (including the share button). If this is correct, is this the intended sequence?

For our use case, this is a bit problematic as we would like to have a set docker image and specify the base url at a later stage (as we would like to deploy to multiple domains). Is there a workaround for this?

@typpo Sorry to ping you directly, but I would really appreciate if you could chime in on the last question in my previous comment.

@leo-shakudo Thanks for tagging me. I agree having to set the URL as a build arg is pretty inconvenient. This is a side effect of the web ui being a next.js app built in standalone mode. The environment variables are inlined at build time. Too much magic!

There's an article here with some alternatives which I'll have to try out https://notes.dt.in.th/NextRuntimeEnv

Found an alternative by moving the build stage into the container (npm install inside entrypoint.sh), which is obviously slower, but I am now able to use container env variables which can be set dynamically when running/deploying. For anyone else curious, this is how entrypoint.sh is defined in my Dockerfile:

RUN echo -e '#!/bin/sh\n\
echo "Writing environment variables to .env file..."\n\
env > .env\n\
echo "Loaded environment variables:"\n\
cat .env\n\
cp .env /app/src/web/nextui/.env.production\n\
npm install\n\
cd /app/src/web/nextui\n\
npm prune --production\n\
cd /app\n\
cp -rf /app/src/web/nextui/public ./public\n\
cp -rf /app/src/web/nextui/.next/standalone/* ./\n\
cp -rf /app/src/web/nextui/.next ./.next\n\
echo "Starting server..."\n\
node server.js' > entrypoint.sh

Thanks for responding @typpo, I am not too familiar with nextjs and was wondering what would be the side effect of not building in standalone mode?