mirror of
https://github.com/tiennm99/DocsGPT.git
synced 2026-10-13 14:15:52 +00:00
build(docker): slim backend image, static frontend image, -docling variant
Backend (arc53/docsgpt): 4.5 GB compressed -> 0.9 GB with both embedding models and tiktoken baked in. - torch/transformers gone from the default install (docling extra only). - Ubuntu 24.04 ships python3.12: no deadsnakes PPA, no software-properties- common; every pin is a wheel, so no gcc/g++/rust in the builder. - COPY --chown and a prefetch that runs as the process user replace the trailing chown -R, which duplicated the 600 MB model layer. - .dockerignore keeps __pycache__, .coverage, local indexes and .env out. - EXTRAS build arg (INSTALL_DOCLING kept as an alias); the docling variant also bakes docling's layout/table/RapidOCR models (DOCLING_ARTIFACTS_PATH) and tesseract, and drops only the discovery documents of Google APIs the app never builds. - FLASK_DEBUG env removed (unused); OCI labels added. Frontend (arc53/docsgpt-fe): 302 MB Vite dev server -> 25 MB static build behind nginx. VITE_* variables are injected at container start into /config.js and read through src/env.ts, so the image no longer needs a rebuild per deployment; docker-compose.yaml keeps hot reload via the dev target. Publishing: every release and develop build now pushes a slim tag and a -docling tag (docling engine + models + tesseract). docker-compose-hub.yaml takes DOCSGPT_IMAGE_TAG / DOCSGPT_IMAGE_VARIANT; docker-compose-standalone.yaml runs the stack from pre-built images without a checkout and is attached to each release. setup.sh selects the -docling variant for OCR instead of requiring a local build. A new workflow builds the image on PRs that touch it and runs verify_offline under --network none; lint checks the exported requirements match uv.lock.
This commit is contained in:
Alex committed
1 parent
4707c45b93
commit
aecb596e99
30 files changed
+706
-247
No files matched your search
@@ -17,9 +17,57 @@ Docker is the recommended method for deploying DocsGPT, providing a consistent a
|
||||
|
||||
**Important Note for Windows Users:** Docker Desktop on Windows generally requires the WSL 2 backend to function correctly, especially when using features like host networking which are utilized in DocsGPT's Docker Compose setup. Ensure WSL 2 is enabled and configured in Docker Desktop settings.
|
||||
|
||||
## Quickest Setup: Using DocsGPT Public API
|
||||
## Quickest Setup: Pre-built Images, No Checkout
|
||||
|
||||
The fastest way to try out DocsGPT is by using the public API endpoint. This requires minimal configuration and no local LLM setup.
|
||||
Every release publishes ready-to-run images to Docker Hub (`arc53/docsgpt`,
|
||||
`arc53/docsgpt-fe`) and GitHub Container Registry (`ghcr.io/arc53/docsgpt`,
|
||||
`ghcr.io/arc53/docsgpt-fe`) for `linux/amd64` and `linux/arm64`. The images
|
||||
contain everything the default configuration needs (embedding models,
|
||||
tokenizers, tiktoken's encoding), so a fresh container makes no downloads on
|
||||
first use. You do not need the source tree to run them:
|
||||
|
||||
1. **Download the standalone Compose file** (also attached to every
|
||||
[release](https://github.com/arc53/DocsGPT/releases)):
|
||||
|
||||
```bash
|
||||
mkdir docsgpt && cd docsgpt
|
||||
curl -fsSLO https://raw.githubusercontent.com/arc53/DocsGPT/main/deployment/docker-compose-standalone.yaml
|
||||
```
|
||||
|
||||
2. **Create a `.env` next to it** with your settings, for example the public API:
|
||||
|
||||
```
|
||||
LLM_PROVIDER=docsgpt
|
||||
VITE_API_STREAMING=true
|
||||
```
|
||||
|
||||
3. **Start it:**
|
||||
|
||||
```bash
|
||||
docker compose -f docker-compose-standalone.yaml up -d
|
||||
```
|
||||
|
||||
Then open [http://localhost:5173/](http://localhost:5173/). Data lives in
|
||||
named Docker volumes; `docker compose -f docker-compose-standalone.yaml down`
|
||||
keeps it and `down -v` removes it.
|
||||
|
||||
**Tags and variants.** `DOCSGPT_IMAGE_TAG` picks the version: a release such
|
||||
as `0.20.0`, `latest` (the newest release, the default) or `develop` (follows
|
||||
the `main` branch). `DOCSGPT_IMAGE_VARIANT` picks the flavour: empty for the
|
||||
slim default image, or `-docling` for the image with the docling parser
|
||||
engine, its models and tesseract baked in (needed for OCR of scanned
|
||||
documents, see the [OCR guide](/Guides/ocr)). Both are read from `.env` or
|
||||
the shell, e.g. `DOCSGPT_IMAGE_TAG=0.20.0 DOCSGPT_IMAGE_VARIANT=-docling`.
|
||||
The same two variables drive `deployment/docker-compose-hub.yaml` in a
|
||||
checkout.
|
||||
|
||||
## Using the Source Checkout
|
||||
|
||||
With a clone of the repository, `deployment/docker-compose-hub.yaml` runs the
|
||||
same pre-built images while keeping your data in `application/indexes`,
|
||||
`application/inputs` and `application/vectors`, and `deployment/docker-compose.yaml`
|
||||
builds the images from your working tree (for local changes, or a build with
|
||||
extra packages: `EXTRAS=docling` in `.env`).
|
||||
|
||||
1. **Clone the DocsGPT Repository (if you haven't already):**
|
||||
|
||||
@@ -48,10 +96,12 @@ The fastest way to try out DocsGPT is by using the public API endpoint. This req
|
||||
Navigate to the root directory of the DocsGPT repository in your terminal and run:
|
||||
|
||||
```bash
|
||||
docker compose --env-file .env -f deployment/docker-compose.yaml up -d
|
||||
docker compose --env-file .env -f deployment/docker-compose-hub.yaml up -d
|
||||
```
|
||||
|
||||
The `-d` flag runs Docker Compose in detached mode (in the background).
|
||||
To build the images from your working tree instead of pulling them, use
|
||||
`deployment/docker-compose.yaml` with `up --build -d`.
|
||||
|
||||
5. **Access DocsGPT in your browser:**
|
||||
|
||||
@@ -62,7 +112,7 @@ The fastest way to try out DocsGPT is by using the public API endpoint. This req
|
||||
To stop the application, navigate to the same directory in your terminal and run:
|
||||
|
||||
```bash
|
||||
docker compose -f deployment/docker-compose.yaml down
|
||||
docker compose -f deployment/docker-compose-hub.yaml down
|
||||
```
|
||||
|
||||
## Optional Ollama Setup (Local Models)
|
||||
@@ -84,11 +134,11 @@ There are two Ollama optional files:
|
||||
|
||||
**CPU:**
|
||||
```bash
|
||||
docker compose --env-file .env -f deployment/docker-compose.yaml -f deployment/optional/docker-compose.optional.ollama-cpu.yaml up -d
|
||||
docker compose --env-file .env -f deployment/docker-compose-hub.yaml -f deployment/optional/docker-compose.optional.ollama-cpu.yaml up -d
|
||||
```
|
||||
**GPU:**
|
||||
```bash
|
||||
docker compose --env-file .env -f deployment/docker-compose.yaml -f deployment/optional/docker-compose.optional.ollama-gpu.yaml up -d
|
||||
docker compose --env-file .env -f deployment/docker-compose-hub.yaml -f deployment/optional/docker-compose.optional.ollama-gpu.yaml up -d
|
||||
```
|
||||
|
||||
3. **Pull the Ollama Model:**
|
||||
@@ -96,11 +146,11 @@ There are two Ollama optional files:
|
||||
**Crucially, after launching with Ollama, you need to pull the desired model into the Ollama container.** Find the `LLM_NAME` you configured in your `.env` file (e.g., `llama3.2:1b`). Then execute the following command to pull the model *inside* the running Ollama container:
|
||||
|
||||
```bash
|
||||
docker compose -f deployment/docker-compose.yaml -f deployment/optional/docker-compose.optional.ollama-cpu.yaml exec -it ollama ollama pull <LLM_NAME>
|
||||
docker compose -f deployment/docker-compose-hub.yaml -f deployment/optional/docker-compose.optional.ollama-cpu.yaml exec -it ollama ollama pull <LLM_NAME>
|
||||
```
|
||||
or (for GPU):
|
||||
```bash
|
||||
docker compose -f deployment/docker-compose.yaml -f deployment/optional/docker-compose.optional.ollama-gpu.yaml exec -it ollama ollama pull <LLM_NAME>
|
||||
docker compose -f deployment/docker-compose-hub.yaml -f deployment/optional/docker-compose.optional.ollama-gpu.yaml exec -it ollama ollama pull <LLM_NAME>
|
||||
```
|
||||
Replace `<LLM_NAME>` with the actual model name from your `.env` file.
|
||||
|
||||
@@ -113,12 +163,12 @@ There are two Ollama optional files:
|
||||
To stop a DocsGPT setup launched with Ollama optional files, use `docker compose down` and include all the compose files used during the `up` command:
|
||||
|
||||
```bash
|
||||
docker compose -f deployment/docker-compose.yaml -f deployment/optional/docker-compose.optional.ollama-cpu.yaml down
|
||||
docker compose -f deployment/docker-compose-hub.yaml -f deployment/optional/docker-compose.optional.ollama-cpu.yaml down
|
||||
```
|
||||
or
|
||||
|
||||
```bash
|
||||
docker compose -f deployment/docker-compose.yaml -f deployment/optional/docker-compose.optional.ollama-gpu.yaml down
|
||||
docker compose -f deployment/docker-compose-hub.yaml -f deployment/optional/docker-compose.optional.ollama-gpu.yaml down
|
||||
```
|
||||
|
||||
**Important for GPU Usage:**
|
||||
|
||||
+25
-11
@@ -64,11 +64,17 @@ docker build --build-arg INSTALL_TESSERACT=true ./application
|
||||
`INSTALL_TESSERACT=true` in `.env` (or the shell) bakes tesseract plus the
|
||||
English pack into locally built backend and worker images; `setup.sh` writes
|
||||
it when you answer yes to the OCR question after choosing to build images
|
||||
locally. Pre-built Docker Hub images (`docker-compose-hub.yaml`) do not
|
||||
include it, so `setup.sh` leaves OCR at its default (off) for them; to OCR
|
||||
there, point `OCR_ENGINE=deepseek` at a DeepSeek-OCR endpoint or install
|
||||
`tesseract-ocr` in a derived image. With `OCR_ENABLED=true` and no binary on
|
||||
`PATH`, scanned pages fail with an install hint (text-layer documents are
|
||||
locally.
|
||||
|
||||
With pre-built images the switch is the image variant: every tag is
|
||||
published twice, slim (`arc53/docsgpt:<tag>`) and `-docling`
|
||||
(`arc53/docsgpt:<tag>-docling`), and the latter bakes tesseract, the docling
|
||||
engine and its models in. Set `DOCSGPT_IMAGE_VARIANT=-docling` in `.env` for
|
||||
`docker-compose-hub.yaml` or `docker-compose-standalone.yaml`; `setup.sh`
|
||||
writes it when you answer yes to the OCR question with Docker Hub images.
|
||||
Alternatively point `OCR_ENGINE=deepseek` at a DeepSeek-OCR endpoint, which
|
||||
needs no system package. With `OCR_ENABLED=true` and no binary on `PATH`,
|
||||
scanned pages fail with an install hint (text-layer documents are
|
||||
unaffected).
|
||||
|
||||
<Callout type="warning" emoji="⚠️">
|
||||
@@ -88,19 +94,27 @@ docling is not part of the base install, and OCR does not need it (see
|
||||
output:
|
||||
|
||||
```bash
|
||||
pip install -r application/requirements-docling.txt
|
||||
pip install -r application/requirements-docling.txt # or: uv sync --extra docling
|
||||
```
|
||||
|
||||
Docker images build without it by default; opt in with the build argument:
|
||||
That file is the core set plus the `docling` extra, exported from the same
|
||||
lock. On Linux it takes torch from the CPU-only PyTorch index, so the extra
|
||||
costs about 1.5 GB rather than the 2.7 GB the CUDA build of torch would; a
|
||||
GPU deployment can reinstall torch from PyPI on top.
|
||||
|
||||
Pre-built images: use the `-docling` variant (`arc53/docsgpt:<tag>-docling`,
|
||||
`DOCSGPT_IMAGE_VARIANT=-docling` in `.env`), which also bakes docling's
|
||||
layout, table-structure and RapidOCR models in so the first parse does not
|
||||
download them. Local builds opt in with the build argument:
|
||||
|
||||
```bash
|
||||
docker build --build-arg INSTALL_DOCLING=true ./application
|
||||
docker build --build-arg EXTRAS=docling ./application
|
||||
```
|
||||
|
||||
`deployment/docker-compose.yaml` forwards the same switch, so setting
|
||||
`INSTALL_DOCLING=true` in `.env` (or the shell) bakes docling into locally
|
||||
built backend and worker images; `setup.sh` offers it as a follow-up to the
|
||||
OCR question. Compose reads build arguments from the shell or from the
|
||||
`EXTRAS=docling` (or the older `INSTALL_DOCLING=true`) in `.env` (or the
|
||||
shell) bakes docling into locally built backend and worker images; `setup.sh`
|
||||
offers it as a follow-up to the OCR question. Compose reads build arguments from the shell or from the
|
||||
`.env` you pass with `--env-file .env` (not from the containers' `env_file`),
|
||||
so build with `docker compose --env-file .env -f deployment/docker-compose.yaml build`
|
||||
as `setup.sh` does. Pre-built Docker Hub images (`docker-compose-hub.yaml`)
|
||||
|
||||
Reference in new issue
Block a user