Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 22:23:50 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #2360] [DOCS]: Unclear how to access the app on local network #1539

New Issue
Closed
opened 2026-02-22 18:25:19 -05:00 by yindo · 9 comments
yindo commented 2026-02-22 18:25:19 -05:00
Owner
Copy Link
Copy Source

Originally created by @tcsenpai on GitHub (Sep 24, 2024).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/2360

Description

Hello!
I am using the Windows app on a PC on my network.
As I am using a laptop in the same network for daily usage, I'd like to access my anythingllm instance through LAN.

As far as I understood, by enabling discovery in Admin settings I should be able to do that.

I have indeed access to [lan ip]:3001 but it returns a "Not found" string without any other explanation.

In the past, using Docker, I was able to reach 3001 and the app just fine.

I could not find any instructions in the docs either.

Originally created by @tcsenpai on GitHub (Sep 24, 2024). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/2360 ### Description Hello! I am using the Windows app on a PC on my network. As I am using a laptop in the same network for daily usage, I'd like to access my anythingllm instance through LAN. As far as I understood, by enabling discovery in Admin settings I should be able to do that. I have indeed access to [lan ip]:3001 but it returns a "Not found" string without any other explanation. In the past, using Docker, I was able to reach 3001 and the app just fine. I could not find any instructions in the docs either.
yindo added the documentation label 2026-02-22 18:25:19 -05:00
yindo closed this issue 2026-02-22 18:25:19 -05:00
yindo commented 2026-02-22 18:25:19 -05:00
Author
Owner
Copy Link
Copy Source

@olariuromeo commented on GitHub (Sep 24, 2024):

To enable access to your Docker container from another device on the same LAN, you need to ensure the following:

  1. Network Connectivity: Ensure the PC and the laptop are on the same network and can communicate via LAN.

  2. Docker Container Access: The container should be accessible through the host's IP and port. By default, Docker containers are isolated, and you need to expose the container's network to allow external access.

Steps to achieve this:

1. Expose the container on the host network

In your docker-compose.yml file, you can specify the extra_hosts to bind the container's network to the host's gateway so that the container can be accessed from other devices on the LAN.

Add the following to your docker-compose.yml under the service configuration:

version: "3.8"
services:
  your_service_name:
    image: your_image_name
    ports:
      - "3001:3001"  # Expose port 3001 to the host
    extra_hosts:
      - "host.docker.internal:host-gateway"
      - "127.0.0.1:host-gateway" # expose to local host server
      - "172.0.0.1:host-gateway" # Add the local network gateway to the hosts

The key is the ports section, which exposes port 3001 of the container to port 3001 on the host.

2. Allow External Access via Firewall

You also need to ensure that the host machine's firewall allows incoming connections on port 3001 from other devices on the LAN. If you're using UFW (Uncomplicated Firewall), add a rule to allow access on port 3001:

sudo ufw allow from 192.168.0.0/24 to any port 3001

This allows access to port 3001 from any device within the 192.168.0.0/24 subnet.

3. Check Docker Network

Ensure that the Docker network is properly configured. By default, Docker uses a bridge network. For communication between containers and external devices, ensure that your container is using a bridge or host network:

docker network ls  # Check the available networks

You can set up a custom Docker network in docker-compose.yml as follows:

networks:
  app_network:
    driver: bridge

services:
  your_service_name:
    networks:
      - app_network

4. Restart Docker Compose

After updating the docker-compose.yml file, restart the services to apply the changes:

docker-compose down
docker-compose up -d

5. Test Access from Another PC

Once Docker is running with the updated configuration and the firewall allows access, test the connection by accessing [host_machine_ip]:3001 from your laptop or any other device on the same LAN.

Summary:

By exposing the container port with docker-compose and adding firewall rules, you can access your Docker service from another machine on the same LAN. The key components are:

  • Using extra_hosts to bind the container network to the host.
  • Configuring firewall rules to allow LAN traffic to access the service.

To add an Nginx service that proxies traffic from a subdomain on port 443 to your application running on port 3001, you need to:

  1. Set up Nginx in your docker-compose.yml to forward traffic from the subdomain to your application.
  2. Configure Nginx to handle SSL (port 443) and proxy requests to the application running on port 3001.
  3. Use Let's Encrypt (via Certbot) for SSL to secure the connection, if necessary.

Step-by-Step Setup:

1. Modify docker-compose.yml

In your existing docker-compose.yml, add a new Nginx service that will handle traffic on port 443. It will also forward traffic to your app running on port 3001.

Here's an example of how to structure the docker-compose.yml:

version: "3.8"
services:
  app_service:
    image: your_app_image
    ports:
      - "3001:3001"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    networks:
      - app_network

  nginx:
    image: nginx:latest
    ports:
      - "443:443"  # Nginx listens on port 443 for HTTPS traffic
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf  # Nginx config file
      - ./certs:/etc/nginx/certs  # SSL certificates
    networks:
      - app_network

networks:
  app_network:
    driver: bridge

In this setup:

  • app_service is your application running on port 3001.
  • nginx will listen on port 443 for HTTPS traffic and forward it to your app.
  • You should ensure that SSL certificates are mounted in /etc/nginx/certs.

2. Create nginx.conf for Nginx Configuration

You need to create an Nginx configuration file that will handle the SSL certificate and proxy traffic to your app.

Here’s an example nginx.conf that:

  • Exposes a subdomain (e.g., app.example.com) on port 443.
  • Uses SSL for security.
  • Proxies requests to the app on port 3001.
server {
    listen 443 ssl;
    server_name app.example.com;

    # SSL configuration (replace with your own certificates)
    ssl_certificate /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/privkey.pem;

    location / {
        # Prevent timeouts on long-running requests
        proxy_connect_timeout       605;
        proxy_send_timeout          605;
        proxy_read_timeout          605;
        send_timeout                605;
        keepalive_timeout           605;

        # Proxy to your app running on port 3001
        proxy_pass http://app_service:3001;

        # Additional proxy settings (optional)
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

This configuration does the following:

  • Listens on port 443 and applies the SSL certificates.
  • Proxies requests to the application running on app_service:3001.
  • The subdomain app.example.com is the entry point.

3. Obtain SSL Certificates (Optional)

If you want to secure your connection using SSL, you can use Let's Encrypt. You can generate the SSL certificates using Certbot.

Here's how to obtain certificates for your subdomain:

  1. Install Certbot and its Nginx plugin on your machine (or inside a container).

  2. Run Certbot to automatically generate and install certificates:

    sudo certbot --nginx -d app.example.com

This command will handle everything, from generating SSL certificates to automatically updating your nginx.conf file with the correct paths for the certificates.

Alternatively, if you generate the certificates manually, ensure they are placed in the /certs directory, and the paths in nginx.conf point to them.

4. Apply the Subdomain Configuration

Replace app.example.com with your actual subdomain. Ensure that:

  • Your domain's DNS is configured to point to your server's public IP.
  • Port 443 is open on your firewall to allow HTTPS traffic.

You can add the firewall rule with UFW as follows:

sudo ufw allow 443/tcp

5. Test the Setup

Once your docker-compose.yml and nginx.conf are configured:

  1. Rebuild your containers:

    docker-compose down
docker-compose up -d

  2. Access your application using the subdomain:

    https://app.example.com

Nginx will handle the SSL connection and forward all requests to your app running on port 3001.

Summary:

  • Add an Nginx service to your docker-compose.yml to handle SSL and proxy requests.
  • Configure Nginx to listen on port 443, apply the SSL certificates, and forward traffic to the application running on port 3001.
  • Ensure your firewall allows port 443 and that your subdomain is correctly configured in DNS.

To set up and run Qdrant, a vector database, as part of your docker-compose configuration for handling vectors, follow these steps. This guide explains how to add the Qdrant service to your docker-compose.yml, how to configure the necessary files, and how to get the service running for vector search.

Step-by-Step Guide:

1. Download and Install Qdrant

Qdrant is available as a Docker image, so there’s no need to install it manually. You can simply pull the Qdrant image and configure it in your Docker Compose.

2. Update docker-compose.yml

Here's the Docker Compose configuration for running Qdrant as a service. This includes the necessary ports and volumes for persistent data storage:

version: "3.9"

networks:
  app_network:
    external: true

services:
  qdrant:
    image: qdrant/qdrant:latest
    restart: always
    container_name: qdrant
    ports:
      - "172.17.0.1:6333:6333" # For the HTTP API, and health endpoints
      - "172.17.0.1:6334:6334" # For the gRPC API
      - "172.17.0.1:6335:6335" # For Distributed deployment
    expose:
      - "6333"
      - "6334"
      - "6335"
    volumes:
      - ./qdrant_data:/qdrant/storage  # Persistent storage
    configs:
      - source: qdrant_config
        target: /qdrant/config/production.yaml
    networks:
      - app_network
    extra_hosts:
      - "host.docker.internal:host-gateway"
      - "172.17.0.1:host-gateway"  # LAN network
      - "127.0.0.1:host-gateway"   # Local IP

configs:
  qdrant_config:
    content: |
      log_level: INFO

Explanation of the Configuration:

  • image: qdrant/qdrant:latest: This pulls the latest version of Qdrant from Docker Hub.
  • ports: These map the necessary ports for the HTTP API (6333), gRPC API (6334), and distributed deployment (6335) to your host.
  • volumes: The qdrant_data directory on your local machine is mounted into the container for persistent storage.
  • extra_hosts: This is used to allow the container to resolve specific hostnames for internal networking.
  • configs: The qdrant_config section defines a minimal configuration for Qdrant, setting the log level to INFO. You can customize this configuration based on your needs.

3. Download and Run the Qdrant Container

To run Qdrant, follow these steps:

  1. Create a new folder for the Qdrant configuration and data:

    mkdir qdrant_data

  2. Pull the latest Qdrant image from Docker Hub:

    docker pull qdrant/qdrant:latest

  3. Start the Docker containers with the updated docker-compose.yml:

    docker-compose up -d

    This command starts Qdrant and any other services in the background (-d stands for "detached mode").

4. Verify Qdrant is Running

To check if the Qdrant container is running correctly:

docker ps

You should see a container with the name qdrant listed as running. Additionally, you can verify the API by making an HTTP request to Qdrant:

curl http://172.17.0.1:6333/collections

This should return the list of collections (if any exist) from Qdrant.

5. Expose Qdrant to Your LAN

Make sure that the docker-compose.yml is correctly configured to expose Qdrant on your local network (LAN). In this case, the extra_hosts directive helps make the service accessible from other machines within the network.

6. Optional: Add Nginx for HTTPS

If you want to expose Qdrant via HTTPS and make it accessible via a domain/subdomain, you can add an Nginx service in the same docker-compose.yml file, similar to what we discussed earlier for your app.

Example Nginx Config for Qdrant:

server {
    listen 443 ssl;
    server_name vectors.example.com;

    # SSL configuration (replace with your own certificates)
    ssl_certificate /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/privkey.pem;

    location / {
        proxy_pass http://qdrant:6333;  # Proxy to Qdrant HTTP API
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

After configuring Nginx, restart the services to expose Qdrant over HTTPS using your subdomain.

Summary of Steps:

  1. Update the docker-compose.yml with Qdrant as a service.
  2. Pull the Qdrant image and start the containers.
  3. Verify Qdrant is running and accessible over LAN.
  4. (Optional) Expose Qdrant over HTTPS using Nginx and a subdomain.

This setup will allow you to handle vector data using Qdrant in your Docker environment, with the option to expose it securely over the internet using Nginx.

it is better not to mix these services, but to have them all in the same network, so you have three separate applications.

** Add qdrant in your bakend app and Have fun! wherever you are,you have your data in your pocket**

Here's the final comment added:

Final Comment:

If you want more security, add a reverse proxy with Caddy plus Redis in the front, and create two networks: one public and one private. Connect only Caddy to the public network and route traffic through Caddy to access the private network. The other containers should remain connected only to the private network. This setup helps isolate your services and provides more security. I would explain more but I will limit myself to that.

@olariuromeo commented on GitHub (Sep 24, 2024): To enable access to your Docker container from another device on the same LAN, you need to ensure the following: 1. **Network Connectivity**: Ensure the PC and the laptop are on the same network and can communicate via LAN. 2. **Docker Container Access**: The container should be accessible through the host's IP and port. By default, Docker containers are isolated, and you need to expose the container's network to allow external access. ### Steps to achieve this: #### 1. **Expose the container on the host network** In your `docker-compose.yml` file, you can specify the `extra_hosts` to bind the container's network to the host's gateway so that the container can be accessed from other devices on the LAN. Add the following to your `docker-compose.yml` under the service configuration: ```yaml version: "3.8" services: your_service_name: image: your_image_name ports: - "3001:3001" # Expose port 3001 to the host extra_hosts: - "host.docker.internal:host-gateway" - "127.0.0.1:host-gateway" # expose to local host server - "172.0.0.1:host-gateway" # Add the local network gateway to the hosts ``` The key is the `ports` section, which exposes port `3001` of the container to port `3001` on the host. #### 2. **Allow External Access via Firewall** You also need to ensure that the host machine's firewall allows incoming connections on port 3001 from other devices on the LAN. If you're using UFW (Uncomplicated Firewall), add a rule to allow access on port 3001: ```bash sudo ufw allow from 192.168.0.0/24 to any port 3001 ``` This allows access to port 3001 from any device within the `192.168.0.0/24` subnet. #### 3. **Check Docker Network** Ensure that the Docker network is properly configured. By default, Docker uses a `bridge` network. For communication between containers and external devices, ensure that your container is using a bridge or host network: ```bash docker network ls # Check the available networks ``` You can set up a custom Docker network in `docker-compose.yml` as follows: ```yaml networks: app_network: driver: bridge services: your_service_name: networks: - app_network ``` #### 4. **Restart Docker Compose** After updating the `docker-compose.yml` file, restart the services to apply the changes: ```bash docker-compose down docker-compose up -d ``` #### 5. **Test Access from Another PC** Once Docker is running with the updated configuration and the firewall allows access, test the connection by accessing `[host_machine_ip]:3001` from your laptop or any other device on the same LAN. ### Summary: By exposing the container port with `docker-compose` and adding firewall rules, you can access your Docker service from another machine on the same LAN. The key components are: - Using `extra_hosts` to bind the container network to the host. - Configuring firewall rules to allow LAN traffic to access the service. To add an Nginx service that proxies traffic from a subdomain on port 443 to your application running on port 3001, you need to: 1. **Set up Nginx in your `docker-compose.yml`** to forward traffic from the subdomain to your application. 2. **Configure Nginx** to handle SSL (port 443) and proxy requests to the application running on port 3001. 3. **Use Let's Encrypt** (via Certbot) for SSL to secure the connection, if necessary. ### Step-by-Step Setup: #### 1. Modify `docker-compose.yml` In your existing `docker-compose.yml`, add a new Nginx service that will handle traffic on port 443. It will also forward traffic to your app running on port 3001. Here's an example of how to structure the `docker-compose.yml`: ```yaml version: "3.8" services: app_service: image: your_app_image ports: - "3001:3001" extra_hosts: - "host.docker.internal:host-gateway" networks: - app_network nginx: image: nginx:latest ports: - "443:443" # Nginx listens on port 443 for HTTPS traffic volumes: - ./nginx.conf:/etc/nginx/nginx.conf # Nginx config file - ./certs:/etc/nginx/certs # SSL certificates networks: - app_network networks: app_network: driver: bridge ``` In this setup: - `app_service` is your application running on port 3001. - `nginx` will listen on port 443 for HTTPS traffic and forward it to your app. - You should ensure that SSL certificates are mounted in `/etc/nginx/certs`. #### 2. Create `nginx.conf` for Nginx Configuration You need to create an Nginx configuration file that will handle the SSL certificate and proxy traffic to your app. Here’s an example `nginx.conf` that: - Exposes a subdomain (e.g., `app.example.com`) on port 443. - Uses SSL for security. - Proxies requests to the app on port 3001. ```nginx server { listen 443 ssl; server_name app.example.com; # SSL configuration (replace with your own certificates) ssl_certificate /etc/nginx/certs/fullchain.pem; ssl_certificate_key /etc/nginx/certs/privkey.pem; location / { # Prevent timeouts on long-running requests proxy_connect_timeout 605; proxy_send_timeout 605; proxy_read_timeout 605; send_timeout 605; keepalive_timeout 605; # Proxy to your app running on port 3001 proxy_pass http://app_service:3001; # Additional proxy settings (optional) proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } ``` This configuration does the following: - Listens on port `443` and applies the SSL certificates. - Proxies requests to the application running on `app_service:3001`. - The subdomain `app.example.com` is the entry point. #### 3. Obtain SSL Certificates (Optional) If you want to secure your connection using SSL, you can use **Let's Encrypt**. You can generate the SSL certificates using Certbot. Here's how to obtain certificates for your subdomain: 1. **Install Certbot** and its Nginx plugin on your machine (or inside a container). 2. **Run Certbot** to automatically generate and install certificates: ```bash sudo certbot --nginx -d app.example.com ``` This command will handle everything, from generating SSL certificates to automatically updating your `nginx.conf` file with the correct paths for the certificates. Alternatively, if you generate the certificates manually, ensure they are placed in the `/certs` directory, and the paths in `nginx.conf` point to them. #### 4. Apply the Subdomain Configuration Replace `app.example.com` with your actual subdomain. Ensure that: - Your domain's DNS is configured to point to your server's public IP. - Port `443` is open on your firewall to allow HTTPS traffic. You can add the firewall rule with UFW as follows: ```bash sudo ufw allow 443/tcp ``` #### 5. Test the Setup Once your `docker-compose.yml` and `nginx.conf` are configured: 1. **Rebuild your containers**: ```bash docker-compose down docker-compose up -d ``` 2. **Access your application** using the subdomain: ``` https://app.example.com ``` Nginx will handle the SSL connection and forward all requests to your app running on port `3001`. ### Summary: - Add an Nginx service to your `docker-compose.yml` to handle SSL and proxy requests. - Configure Nginx to listen on port 443, apply the SSL certificates, and forward traffic to the application running on port 3001. - Ensure your firewall allows port 443 and that your subdomain is correctly configured in DNS. To set up and run **Qdrant**, a vector database, as part of your `docker-compose` configuration for handling vectors, follow these steps. This guide explains how to add the **Qdrant** service to your `docker-compose.yml`, how to configure the necessary files, and how to get the service running for vector search. ### Step-by-Step Guide: #### 1. Download and Install Qdrant Qdrant is available as a Docker image, so there’s no need to install it manually. You can simply pull the Qdrant image and configure it in your Docker Compose. #### 2. Update `docker-compose.yml` Here's the Docker Compose configuration for running Qdrant as a service. This includes the necessary ports and volumes for persistent data storage: ```yaml version: "3.9" networks: app_network: external: true services: qdrant: image: qdrant/qdrant:latest restart: always container_name: qdrant ports: - "172.17.0.1:6333:6333" # For the HTTP API, and health endpoints - "172.17.0.1:6334:6334" # For the gRPC API - "172.17.0.1:6335:6335" # For Distributed deployment expose: - "6333" - "6334" - "6335" volumes: - ./qdrant_data:/qdrant/storage # Persistent storage configs: - source: qdrant_config target: /qdrant/config/production.yaml networks: - app_network extra_hosts: - "host.docker.internal:host-gateway" - "172.17.0.1:host-gateway" # LAN network - "127.0.0.1:host-gateway" # Local IP configs: qdrant_config: content: | log_level: INFO ``` ### Explanation of the Configuration: - **`image: qdrant/qdrant:latest`**: This pulls the latest version of Qdrant from Docker Hub. - **`ports`**: These map the necessary ports for the HTTP API (6333), gRPC API (6334), and distributed deployment (6335) to your host. - **`volumes`**: The `qdrant_data` directory on your local machine is mounted into the container for persistent storage. - **`extra_hosts`**: This is used to allow the container to resolve specific hostnames for internal networking. - **`configs`**: The `qdrant_config` section defines a minimal configuration for Qdrant, setting the log level to `INFO`. You can customize this configuration based on your needs. #### 3. Download and Run the Qdrant Container To run Qdrant, follow these steps: 1. **Create a new folder** for the Qdrant configuration and data: ```bash mkdir qdrant_data ``` 2. **Pull the latest Qdrant image** from Docker Hub: ```bash docker pull qdrant/qdrant:latest ``` 3. **Start the Docker containers** with the updated `docker-compose.yml`: ```bash docker-compose up -d ``` This command starts Qdrant and any other services in the background (`-d` stands for "detached mode"). #### 4. Verify Qdrant is Running To check if the Qdrant container is running correctly: ```bash docker ps ``` You should see a container with the name `qdrant` listed as running. Additionally, you can verify the API by making an HTTP request to Qdrant: ```bash curl http://172.17.0.1:6333/collections ``` This should return the list of collections (if any exist) from Qdrant. #### 5. Expose Qdrant to Your LAN Make sure that the `docker-compose.yml` is correctly configured to expose Qdrant on your local network (LAN). In this case, the `extra_hosts` directive helps make the service accessible from other machines within the network. #### 6. Optional: Add Nginx for HTTPS If you want to expose Qdrant via HTTPS and make it accessible via a domain/subdomain, you can add an **Nginx service** in the same `docker-compose.yml` file, similar to what we discussed earlier for your app. ### Example Nginx Config for Qdrant: ```nginx server { listen 443 ssl; server_name vectors.example.com; # SSL configuration (replace with your own certificates) ssl_certificate /etc/nginx/certs/fullchain.pem; ssl_certificate_key /etc/nginx/certs/privkey.pem; location / { proxy_pass http://qdrant:6333; # Proxy to Qdrant HTTP API proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } ``` After configuring Nginx, restart the services to expose Qdrant over HTTPS using your subdomain. --- ### Summary of Steps: 1. **Update the `docker-compose.yml`** with Qdrant as a service. 2. **Pull the Qdrant image** and start the containers. 3. **Verify Qdrant is running** and accessible over LAN. 4. (Optional) **Expose Qdrant over HTTPS** using Nginx and a subdomain. This setup will allow you to handle vector data using Qdrant in your Docker environment, with the option to expose it securely over the internet using Nginx. it is better not to mix these services, but to have them all in the same network, so you have three separate applications. ** Add qdrant in your bakend app and Have fun! wherever you are,you have your data in your pocket** Here's the final comment added: --- **Final Comment:** If you want more security, add a reverse proxy with **Caddy plus Redis** in the front, and create two networks: one public and one private. Connect only **Caddy** to the public network and route traffic through Caddy to access the private network. The other containers should remain connected only to the private network. This setup helps isolate your services and provides more security. I would explain more but I will limit myself to that.
yindo commented 2026-02-22 18:25:19 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Sep 24, 2024):

@tcsenpai

As far as I understood, by enabling discovery in Admin settings I should be able to do that.

Correct, then you need to close and reopen the app when you edit that setting. Then the app should attach to 0.0.0.0 and other devices can see it.

In the past, using Docker, I was able to reach 3001 and the app just fine.

Ah, there is some confusion on the UI part. The desktop app serves the GUI only within the client, but that discoverability is if you want to use the API for the desktop client. Only the docker version serves the GUI from the server - so that it can be accessed in a browser.

The desktop app has never served the UI from the server, intentionally.

@timothycarambat commented on GitHub (Sep 24, 2024): @tcsenpai > As far as I understood, by enabling discovery in Admin settings I should be able to do that. Correct, then you need to _close and reopen the app_ when you edit that setting. Then the app should attach to 0.0.0.0 and other devices can see it. > In the past, using Docker, I was able to reach 3001 and the app just fine. Ah, there is some confusion on the UI part. The _desktop_ app serves the GUI only within the client, but that discoverability is if you want to use the API for the desktop client. Only the _docker_ version serves the GUI from the server - so that it can be accessed in a browser. The desktop app has never served the UI from the server, intentionally.
yindo commented 2026-02-22 18:25:19 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Sep 24, 2024):

@olariuromeo I highly doubt you wrote that comment out and pretty sure its AI. Please dont post comments generated by AI for helping people. The comment you posted would not have helped the OP at all and was mostly irrelevant to their question.

Or just use a better model if you're going to do that and maybe limit max_tokens.

@timothycarambat commented on GitHub (Sep 24, 2024): @olariuromeo I highly doubt you wrote that comment out and pretty sure its AI. Please dont post comments generated by AI for helping people. The comment you posted would not have helped the OP at all and was mostly irrelevant to their question. Or just use a better model if you're going to do that and maybe limit `max_tokens`.
yindo commented 2026-02-22 18:25:20 -05:00
Author
Owner
Copy Link
Copy Source

@olariuromeo commented on GitHub (Sep 26, 2024):

@olariuromeo I highly doubt you wrote that comment out and pretty sure its AI. Please dont post comments generated by AI for helping people. The comment you posted would not have helped the OP at all and was mostly irrelevant to their question.

Or just use a better model if you're going to do that and maybe limit max_tokens.

the comment was created by me, AI only did the translation and formatting of the text and the grammar correction, my englesh its nor perfect, if you think that the configuration of nginx and the one for anything, nginx and qdrant docker compose files is wrong, which I already use successfully in every application and it works perfectly, any suggestion is welcome. There are 3 iterations for each app translation, my model is limited to 8k. the nginx configuration is the one you provided a few months ago and work very well qdrand config i created myself and do the job. anyting-llm docker compose is adaptation from your docker run documentation and work very well for me, but you know beterr the app

@olariuromeo commented on GitHub (Sep 26, 2024): > @olariuromeo I highly doubt you wrote that comment out and pretty sure its AI. Please dont post comments generated by AI for helping people. The comment you posted would not have helped the OP at all and was mostly irrelevant to their question. > > Or just use a better model if you're going to do that and maybe limit `max_tokens`. the comment was created by me, AI only did the translation and formatting of the text and the grammar correction, my englesh its nor perfect, if you think that the configuration of nginx and the one for anything, nginx and qdrant docker compose files is wrong, which I already use successfully in every application and it works perfectly, any suggestion is welcome. There are 3 iterations for each app translation, my model is limited to 8k. the nginx configuration is the one you provided a few months ago and work very well qdrand config i created myself and do the job. anyting-llm docker compose is adaptation from your docker run documentation and work very well for me, but you know beterr the app
yindo commented 2026-02-22 18:25:20 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Sep 26, 2024):

@olariuromeo Apologies then, it was just so verbose and was not related to the question from OP so I assumed that as we have been recently spammed with AI issues/comments recently and thought it was more of the same.

@timothycarambat commented on GitHub (Sep 26, 2024): @olariuromeo Apologies then, it was just so verbose and was not related to the question from OP so I assumed that as we have been recently spammed with AI issues/comments recently and thought it was more of the same.
yindo commented 2026-02-22 18:25:20 -05:00
Author
Owner
Copy Link
Copy Source

@olariuromeo commented on GitHub (Sep 27, 2024):

@olariuromeo Apologies then, it was just so verbose and was not related to the question from OP so I assumed that as we have been recently spammed with AI issues/comments recently and thought it was more of the same.
It's only my fault that I gave a more extensive explanation of how I use the anything-llm application in docker to connect containers to each other, I thought it could be useful. In the future I will be more concise. The anything llm application is wonderful, it helped me a lot.

@olariuromeo commented on GitHub (Sep 27, 2024): > @olariuromeo Apologies then, it was just so verbose and was not related to the question from OP so I assumed that as we have been recently spammed with AI issues/comments recently and thought it was more of the same. It's only my fault that I gave a more extensive explanation of how I use the anything-llm application in docker to connect containers to each other, I thought it could be useful. In the future I will be more concise. The anything llm application is wonderful, it helped me a lot.
yindo commented 2026-02-22 18:25:20 -05:00
Author
Owner
Copy Link
Copy Source

@tcsenpai commented on GitHub (Sep 28, 2024):

Hi @olariuromeo , thanks for the reply.

Let me clarify: I have no issues using Docker both locally and publicly, I'd like to do the same while running the app itself.

Is that possible?

@tcsenpai commented on GitHub (Sep 28, 2024): Hi @olariuromeo , thanks for the reply. Let me clarify: I have no issues using Docker both locally and publicly, I'd like to do the same while running the app itself. Is that possible?
yindo commented 2026-02-22 18:25:20 -05:00
Author
Owner
Copy Link
Copy Source

@paulerbear commented on GitHub (Feb 24, 2025):

Hi! So I'm using AnythingLLM with my Windows-based Homelab PC running the standalone desktop application. I want to access this AnythingLLM instance on my LAN from my macbook. How do I do this?

@paulerbear commented on GitHub (Feb 24, 2025): Hi! So I'm using AnythingLLM with my Windows-based Homelab PC running the standalone desktop application. I want to access this AnythingLLM instance on my LAN from my macbook. How do I do this?
yindo commented 2026-02-22 18:25:20 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Feb 25, 2025):

Image

If you want a user interface across your LAN, you need to run the docker-based version of AnythingLLM

@timothycarambat commented on GitHub (Feb 25, 2025): <img width="1779" alt="Image" src="https://github.com/user-attachments/assets/4515ab02-2ad4-461f-9c5e-1a3b6875969d" /> If you want a _user interface_ across your LAN, you need to run the docker-based version of AnythingLLM
yindo changed title from [DOCS]: Unclear how to access the app on local network to [GH-ISSUE #2360] [DOCS]: Unclear how to access the app on local network 2026-06-05 14:41:18 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label documentation
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#1539
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?