BidMaster Pro: a self-hosted tender pipeline from announcement to docx

What BidMaster Pro actually automates in a tender workflow

The problem is not writing prose. It is that a tender response is assembled from a招标 announcement, a scoring matrix, a set of mandatory qualification clauses, and a company's own history, and every one of those pieces lives in a different file format. BidMaster Pro's answer is a four-stage pipeline the README names as Interpret, Generate, Check and Format, with a fifth auxiliary loop for opportunity monitoring. The stated output is a deliverable docx, and the README calls docx the only intermediate format, with doc and PDF exported from it.

The audience is narrow and specific. A single bid writer with a ChatGPT tab does not need PostgreSQL, Redis, MinIO and a Celery worker. A bid team that already keeps a knowledge base of past submissions, and that has to prove to an internal reviewer that clause 14 of the announcement was answered, is the reader this project is written for. The check stage is the part that carries the weight: the README lists 21 compliance rules covering bid bonds, signatures and seals, validity periods, consistency, duplication rate and price reasonableness. Those are the checks a human reviewer does by hand and misses at 11pm.

The four-stage pipeline and the engines behind it

The README's architecture diagram shows a React and Electron desktop client talking over REST to a FastAPI server on Python 3.12 or newer. Behind the router layer sit five named engines: an Agent Engine built on LangGraph, a Skill Engine described as a plugin system, a RAG Engine on ChromaDB, an LLM Gateway on LiteLLM, and a Doc Engine with multiple parsers. Infrastructure is PostgreSQL 16 through AsyncPG, Redis 7 as the Celery broker, MinIO for object storage, and a Celery worker for async tasks.

That layout explains the data flow. A tender document enters through the Doc Engine, which the dependencies suggest is a combination of pdfplumber, PyMuPDF, Mammoth and BeautifulSoup4, with chardet for encoding detection. Scanned pages can be routed to MinerU instead, either the cloud SaaS or a self-deployed OpenAPI service, configured under a MinerU OCR tab with API key, endpoint, timeout and polling settings. Text is then embedded and stored in ChromaDB, and the LLM Gateway calls whichever provider is configured. Multi-model switching is real rather than a marketing line: .env.example sets BMP_LLM_DEFAULT_MODEL to deepseek/deepseek-chat and BMP_LLM_FALLBACK_MODES to ollama/qwen2.5, so a local model can absorb a failure from the hosted one. BMP_TENDER_TEXT_MAX_CHARS defaults to 32000 and exists to truncate LLM input, which tells you the authors expect long tender files to overflow a context window.

Installing BidMaster Pro with Docker and running a first interpretation

The README gives two paths, Docker Compose as the recommended one and a local development setup. The Docker path clones the repository, copies .env.example to .env, and starts the stack. Note that the README writes the clone URL as a placeholder, so substitute the repository address yourself.

git clone <repository-url>
cd BidMaster-Pro
cp .env.example .env
docker-compose up -d

After that command the README says PostgreSQL on 5432, Redis on 6379, MinIO on 9000, FastAPI on 8000 and a Celery worker start automatically. The API documentation is served at http://localhost:8000/docs and the MinIO console at http://localhost:9001. If those two pages load, the infrastructure is up; if the API docs fail, the problem is almost always the database URL rather than the application code.

Before any LLM call works you need to edit .env. The minimum set the example file implies is the model key and the embedding key, because embedding mode defaults to api rather than a local model.

BMP_LLM_DEFAULT_MODEL=deepseek/deepseek-chat
BMP_LLM_API_KEY=
BMP_LLM_API_BASE=https://api.deepseek.com
BMP_EMBEDDING_MODE=api
BMP_EMBEDDING_MODEL=text-embedding-v3
BMP_EMBEDDING_API_KEY=

The local development path instead creates a virtual environment, installs the package in editable mode, installs the desktop client under packages/desktop, and brings up only the infrastructure containers.

python -m venv venv
source venv/bin/activate
pip install -e .
cd packages/desktop
npm install
docker-compose up -d postgres redis minio

The README's quick start section is truncated at the point where it would explain the remaining environment variables, so treat the .env.example file itself as the authoritative list. For a first real run, upload one tender PDF through the Interpret stage and check whether the scoring matrix it returns matches the one in the document. That single test tells you more about whether the parsing and extraction layers suit your document formats than any feature list.

Where BidMaster Pro breaks down or is the wrong tool

The first limitation is stated by the project's own metadata. The README carries an MIT licence badge, while the repository's LICENSE file and the project metadata both say AGPL-3.0. Those are not compatible positions, and AGPL-3.0 carries network-service obligations that matter if you plan to expose this to users outside your organisation. Resolve that discrepancy before you build anything on top of it.

The second is maturity. The only release is V0.1.0, published on 2026-06-04, and the last push to the default branch was on 2026-09-03. The README does not document a migration path between versions, and while alembic.ini and Alembic appear in the dependency list, the README is silent on rollback. A 0.1.0 schema under active change is a different risk class from a settled one.

The third is operational weight. This is not a script. It needs PostgreSQL 16, Redis 7, MinIO, a Celery worker, Python 3.12 or newer and Node 18 or newer, plus at least one paid LLM key and, if you use the default embedding mode, an embedding API key. A team that wants to draft one bid a month will spend more time on the stack than on the bid.

Finally, the compliance checks are only as good as the rules behind them. The README lists 21 checks by category but does not publish the rule definitions, the false-positive rate, or any evaluation against human review. Treat the check output as a second reader, not as a substitute for the person who signs the bid.

How BidMaster Pro differs from generic document AI and from procurement suites

The obvious alternative is a general document assistant: feed the tender into a hosted chat model and ask for a draft. That approach is cheaper and needs no infrastructure, but it has no persistent knowledge base, no per-project state, and no fixed rule set. BidMaster Pro's RAG engine over ChromaDB with company-profile filtering is the part a chat session cannot reproduce, because it retrieves from your own historical submissions rather than from a general corpus.

The other alternative is an established procurement suite, the kind used by construction and infrastructure buyers. Those products centre on the buyer's side: publishing tenders, tracking bidders, managing clarifications. BidMaster Pro sits on the supplier's side and works backwards from a document you already downloaded. It does not publish tenders, and the opportunity monitoring feature only scrapes announcements and scores them by keyword and AI-assessed value. If your problem is finding work, that monitoring loop is a weak reason to run the stack. If your problem is answering a tender you have already decided to pursue, the four-stage pipeline is the reason.

Licence, maintenance and the cost of keeping it running

The licence question is the one to settle first. Repository metadata and the LICENSE file state AGPL-3.0; the README badge says MIT. Under AGPL-3.0, if you modify the software and let users interact with it over a network, you take on source-disclosure obligations for your modified version. Nothing here constitutes legal advice, and a deployment entirely inside one company is a different situation from a hosted service, but the badge conflict is a real defect in the repository that a legal reviewer will find.

Upgrade cost comes from three directions. The dependency surface is wide: FastAPI, SQLAlchemy, LiteLLM, LangGraph, LangChain-Core, ChromaDB, ONNX Runtime, Celery, sentence-transformers and WeasyPrint all appear in pyproject.toml, and each of those moves on its own schedule. Schema changes run through Alembic, and the README documents no rollback procedure, so a backup before any upgrade is the practical safeguard. The third cost is provider drift: because the LLM Gateway is LiteLLM and the default model is deepseek/deepseek-chat with ollama/qwen2.5 as fallback, a provider deprecation is a configuration change rather than a code change, which is the design working as intended. Budget for the embedding API separately, since BMP_EMBEDDING_MODE defaults to api.

Editorial conclusion

Adopt BidMaster Pro if you already run PostgreSQL, Redis and object storage and want the four-stage tender pipeline inside your own network, with your own LLM keys. Do not adopt it if you need a hosted product with published benchmarks or a packaged desktop installer: the repository ships a Docker Compose file and a V0.1.0 release, nothing more. Verify three things first: that the README's MIT badge does not match the AGPL-3.0 LICENSE file, that .env.example's BMP_LLM_API_KEY and BMP_MINERU_API_KEY point at providers you are allowed to use, and that a single test tender document survives the interpret, generate, check and format stages end to end on your hardware.

Frequently asked questions

Official sources

1. guangshu100/BidMaster-Pro on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases