[Feature Request] Simplify Docker Compose (drop requirement to clone repo) - upvote if you agree

[kpatdev]

Is your feature request related to a problem? Please describe.

Currently, in order to run Perplexica on Docker you have to clone down the repo and build the containers. This is a step that should be unnecessary as every time the app is updated you have to reclone the repo and rebuild. While I understand that this is extending prebuilt images, it still shouldn't be required.

[!NOTE] @ItzCrazyKns is currently unifying Perplexica into 1 image. There currently is no ETA on when this will be complete. This is a request to reduce the barrier to continuous deployment on Docker in the meantime.

Describe the solution you'd like

The docker-compose.yaml file should not require the building/extending of any image. The pre-built images that are already provided should contain everything that is needed for running Perplexica.

There should be no requirement to clone down the repo. Prebuilt images should contain everything that is needed and any customizable variables should be present in either the .env or the config.toml.

.env:

SEARXNG_API_URL=http://searxng:8080
NEXT_PUBLIC_API_URL=http://127.0.0.1:3001/api
NEXT_PUBLIC_WS_URL=ws://127.0.0.1:3001

The config.toml that's already provided shouldn't need to be changed.

docker-compose.yaml:

services:
  searxng:
    image: docker.io/searxng/searxng:latest
    volumes:
      - ./searxng:/etc/searxng:rw
    ports:
      - 4000:8080
    networks:
      - perplexica-network
    restart: unless-stopped

  perplexica-backend:
    image: itzcrazykns1337/perplexica-backend:main
    environment:
      - SEARXNG_API_URL=${SEARXNG_API_URL}
    depends_on:
      - searxng
    ports:
      - 3001:3001
    volumes:
      - backend-dbstore:/home/perplexica/data
      - uploads:/home/perplexica/uploads
      - ./config.toml:/home/perplexica/config.toml
    extra_hosts:
      - 'host.docker.internal:host-gateway'
    networks:
      - perplexica-network
    restart: unless-stopped

  perplexica-frontend:
    image: itzcrazykns1337/perplexica-frontend:main
    environment:
      - NEXT_PUBLIC_API_URL=${NEXT_PUBLIC_API_URL}
      - NEXT_PUBLIC_WS_URL=${NEXT_PUBLIC_WS_URL}
    depends_on:
      - perplexica-backend
    ports:
      - 3000:3000
    networks:
      - perplexica-network
    restart: unless-stopped

networks:
  perplexica-network:

volumes:
  backend-dbstore:
  uploads:

[!NOTE] If you're not running your own SearXNG instance, you'll still need to use the proper files located here.

Additional context

We discussed at length here: #661 @ItzCrazyKns @mayphilc. Per his request, I've created a separate issue to gauge interest in simplification of the docker deployment as a stop-gap prior to the unification he is currently planning.

Related: #570 #565 #581

There's many issues/discussions that are related to this. This should be addressed to allow for smoother adoption.

---

If you are interested in this, please upvote/leave a comment on any additional changes you'd want.

[RepairYourTech]

I would absolutely love being able to dive right in but at the same time I do not know enough about perplexica or what they have going on to justify me weighing in on what might be harder before or after the unification. Thats all way over my head.

I personally don't care about unification I'm already running 50 containers what's the difference if perplexica has a unified image or needs a backend? Supabase and lagnfuse and others have multiple images to make them run and I still use seperate compose file for every image and just use includes in the main compose. Some of the services use config.toml files so they have appdata folders and I have one central .env for all my environment configurations for every single service in my stack

[kpatdev]

I would absolutely love being able to dive right in but at the same time I do not know enough about perplexica or what they have going on to justify me weighing in on what might be harder before or after the unification. Thats all way over my head.

I personally don't care about unification I'm already running 50 containers what's the difference if perplexica has a unified image or needs a backend? Supabase and lagnfuse and others have multiple images to make them run and I still use seperate compose file for every image and just use includes in the main compose. Some of the services use config.toml files so they have appdata folders and I have one central .env for all my environment configurations for every single service in my stack

Unification of the images is fine for a goal of the project but to reduce the barrier to entry and continuous deployment, the current practices are unsustainable.

Everyone has their own way of managing their compose files. I use a separate .env for every stack.

But one thing is consistent across all my stacks. None of them require me to clone a repo. Sure some of them require me to copy config files, .env.examples, etc. But that's only ONE time. Cloning the repo on every update just doesn't make sense.

The images should be prebuilt and configuration should be done with environment variables or the config.toml (ideally both). @ItzCrazyKns can have a look at how Open WebUI handles configuration variables.

When launching Open WebUI for the first time, all environment variables are treated equally and can be used to configure the application. However, for environment variables marked as PersistentConfig, their values are persisted and stored internally.

After the initial launch, if you restart the container, PersistentConfig environment variables will no longer use the external environment variable values. Instead, they will use the internally stored values.

In contrast, regular environment variables will continue to be updated and applied on each subsequent restart.

You can update the values of PersistentConfig environment variables directly from within Open WebUI, and these changes will be stored internally. This allows you to manage these configuration settings independently of the external environment variables.

Please note that PersistentConfig environment variables are clearly marked as such in the documentation below, so you can be aware of how they will behave.

This feels like a good middle-ground. When Perplexica is launched the first time, the .env variables are used. Afterwards, the ones that can be changed from the UI can be stored in the config.toml and at that point they take priority over the .env variables.

[RepairYourTech]

I would absolutely love being able to dive right in but at the same time I do not know enough about perplexica or what they have going on to justify me weighing in on what might be harder before or after the unification. Thats all way over my head.

I personally don't care about unification I'm already running 50 containers what's the difference if perplexica has a unified image or needs a backend? Supabase and lagnfuse and others have multiple images to make them run and I still use seperate compose file for every image and just use includes in the main compose. Some of the services use config.toml files so they have appdata folders and I have one central .env for all my environment configurations for every single service in my stack

Unification of the images is fine for a goal of the project but to reduce the barrier to entry and continuous deployment, the current practices are unsustainable.

Everyone has their own way of managing their compose files. I use a separate .env for every stack.

But one thing is consistent across all my stacks. None of them require me to clone a repo. Sure some of them require me to copy config files, .env.examples, etc. But that's only ONE time. Cloning the repo on every update just doesn't make sense.

The images should be prebuilt and configuration should be done with environment variables or the config.toml (ideally both). @ItzCrazyKns can have a look at how Open WebUI handles configuration variables.

When launching Open WebUI for the first time, all environment variables are treated equally and can be used to configure the application. However, for environment variables marked as PersistentConfig, their values are persisted and stored internally.

After the initial launch, if you restart the container, PersistentConfig environment variables will no longer use the external environment variable values. Instead, they will use the internally stored values.

In contrast, regular environment variables will continue to be updated and applied on each subsequent restart.

You can update the values of PersistentConfig environment variables directly from within Open WebUI, and these changes will be stored internally. This allows you to manage these configuration settings independently of the external environment variables.

Please note that PersistentConfig environment variables are clearly marked as such in the documentation below, so you can be aware of how they will behave.

This feels like a good middle-ground. When Perplexica is launched the first time, the .env variables are used. Afterwards, the ones that can be changed from the UI can be stored in the config.toml and at that point they take priority over the .env variables.

Yes that's ideal 💯 %

[ItzCrazyKns]

This is exactly what I mentioned in the PR, you can read my earlier comments where I said I am going to give config variables more priority over environment variables so they can be edited from the UI.

[o10s]

Just adding here a comment I would love indeed not to clone the repo... plus I am on Kubernetes so not going to run a docker compose stack anyways but I do prefer to just pull images add in my env variables from secrets stores and that's it that's all .

Thanks for all the hard work

[gilbrotheraway]

what's the difference between perplexica-backend and perplexica images on docker hub?

[ItzCrazyKns]

what's the difference between perplexica-backend and perplexica images on docker hub?

perplexica-backend and perplexica-frontend are old images when the backend and frontend were separate, since they've been merged now I decided to create a single perplexica image

[Ghostbird]

I think this can be closed. There's no more requirement to clone the repo now. Docker compose just pulls in the pre-built images.

[o10s]

@Ghostbird I still can see this build in the compose file https://github.com/ItzCrazyKns/Perplexica/blob/master/docker-compose.yaml#L14-L16

so I'm not sure it is done...

[RepairYourTech]

@Ghostbird I still can see this build in the compose file https://github.com/ItzCrazyKns/Perplexica/blob/master/docker-compose.yaml#L14-L16

so I'm not sure it is done...

Sooooo close lol

I wouldn't want to have to build anything g in my k8s either thats whack asf and ruins any gitops procedures

[Ghostbird]

@Ghostbird I still can see this build in the compose file https://github.com/ItzCrazyKns/Perplexica/blob/master/docker-compose.yaml#L14-L16

so I'm not sure it is done...

If you specify an image, docker compose will prefer to use that^1, barring other options that override this behaviour.

Let me put it another way. I first started using Perplexica this weekend. When I came across this issue, I was confused why people claimed you needed to pull the repo, as:

• I hadn't done so, and my Perplexica was running fine
• I hadn't seen anything that suggested I needed to pull the repo when I set-up Perplexica. Note: I had just copied the parts of the docker compose file I needed, to my larger docker compose file, and since I saw it was image based, I just didn't copy the build section.

Then I checked the commits, and realised that the mechanism to run Perplexica from a prebuilt image was only added three weeks ago.

When Compose is confronted with both a build subsection for a service and an image attribute, it follows the rules defined by the pull_policy attribute. If pull_policy is missing from the service definition, Compose attempts to pull the image first and then builds from source if the image isn't found in the registry or platform cache.

[o10s]

@Ghostbird I didn't know this actually and I was suspecting that it was a requirement so basically I should be ok just referencing the newer image ! Since I use Kubernetes I # have to change some stuff as I can't use compose of course but if your setup works without the build I should be able to pull it off as well !

[vrozaksen]

For me it works on latest image without building: https://github.com/vrozaksen/home-ops/blob/main/kubernetes/apps/ai/perplexica/helmrelease.yaml

[kpatdev]

Fixed with #661. Closing to avoid confusion.