AingDesk: a local AI assistant with a knowledge base, shipped as a desktop app or Docker container

What AingDesk actually assembles for you

Running a local model is the easy part. The work sits around it: a place to put documents so the model can retrieve them, a way to reach hosted APIs when the local model is not good enough, a search tool for questions the model cannot answer from its weights, and some mechanism for letting the model call external tools. AingDesk packages those pieces into a single application. The README lists one-click deployment of local models and mainstream model APIs, a local knowledge base, agent creation, online sharing, web search, a server-side deployment option, and an MCP client. The target user is stated plainly: beginners, described in the README as "beginner-friendly for AI newcomers." That framing matters when you evaluate the rest. This is not a library you embed in your own service. It is an application with a UI, and the repository layout reflects that: electron/, frontend/, cmd/, build/ and public/ sit at the top level alongside package.json. The package description calls it "Simple and easy-to-use AI big model deployment and usage software." If your problem is that you have documents, a model endpoint, and no interface connecting them, AingDesk is aimed at exactly that gap.

Electron shell, Go and Python sidecars, and a 7071 port

The architecture is visible in package.json rather than in prose. The Electron entry point is ./public/electron/main.js, and the scripts reveal a multi-runtime build: dev-go, dev-python, build-go-w, build-go-m, build-go-l, build-python. So the shipped application is an Electron front end over Go and Python components, with a frontend/ directory built separately and moved into place by ee-bin, the project's own build tool. Persistence is SQLite: the re-sqlite script runs electron-rebuild -f -w better-sqlite3, which tells you the knowledge base and conversation state live in a local SQLite file rather than in an external database. The server version exposes port 7071, and the Docker command mounts five host directories into the container: /data, /uploads, /logs, /aingdesk/bin and /sys_data. Those mount points are the real deployment surface. /data and /sys_data hold state, /uploads holds uploaded documents for the knowledge base, /logs holds output, and /aingdesk/bin is where the runtime binaries land. If you back up one thing, back up /data and /sys_data together; the README does not say which holds what.

Installing AingDesk from Docker and running the first conversation

The README gives two server install paths and one client path. For desktop, it points to the official website, a CNB mirror, and GitHub releases. For a server, the Docker run command is the shortest route to something running. It publishes port 7071 and bind-mounts the five directories listed above into the current working directory.

docker run -d \
  --name node \
  -v $(pwd)/data:/data \
  -v $(pwd)/uploads:/uploads \
  -v $(pwd)/logs:/logs \
  -v $(pwd)/bin:/aingdesk/bin \
  -v $(pwd)/sys_data:/sys_data \
  -p 7071:7071 \
  -w /aingdesk \
  aingdesk/aingdesk

After the container starts, the application should be reachable on port 7071 of the host. The README does not document a health endpoint or a default login, so treat the first visit as exploratory. If you prefer Compose, the README fetches a compose file from the CNB mirror rather than from GitHub, which is worth noting if you build in an environment that only allows GitHub egress.

mkdir -p aingdesk
cd aingdesk
wget https://cnb.cool/aingdesk/AingDesk/-/git/raw/server/docker-compose.yml
docker compose up -d

Building from source follows the README's own sequence. There is a platform caveat the README states explicitly: macOS users should remove the @rollup/rollup-win32-x64-msvc dependency from package.json first.

git clone https://github.com/aingdesk/AingDesk.git
cd AingDesk
cd frontend
yarn
cd ..
yarn
yarn dev

The frontend dependencies install separately from the root dependencies, so running yarn once at the top level is not enough. The README does not describe what a successful yarn dev looks like, which port the dev server binds, or whether the Go and Python components start automatically or need dev-go and dev-python in separate terminals.

Where the release cadence and documentation leave you exposed

The repository is not archived, and the last push to main was on 2026-06-04. The most recent release listed is v1.2.4 from 2025-05-27, with v1.2.3 and v1.2.2 shortly before it in April 2025. That gap between commits and tagged releases is the practical risk. You can run main, but you are then running untagged code, and the README offers no guidance on which branch or tag corresponds to the published Docker image. The Docker command uses the bare aingdesk/aingdesk tag, which by convention floats; pinning is not discussed. The README also does not document rollback, database migration, or what happens to /data and /sys_data when the container image changes. For a tool that stores a knowledge base in SQLite on a mounted volume, that omission is the one to resolve before you put real documents in it. There is a second, smaller failure mode: the README's feature list includes a note that simultaneous conversations with multiple models in a single session is "coming soon," so if that is the capability that drew you in, it is not in the shipped release.

AingDesk against Open WebUI and plain Ollama

The nearest comparison is Open WebUI, which also provides a browser interface over local and remote models with retrieval over uploaded documents. The difference is packaging. Open WebUI is a Python web application you deploy and reach through a browser; AingDesk ships an Electron desktop client for macOS and Windows in addition to a server container, so a user who wants a local app with no browser tab can install it directly. The second comparison is running Ollama on its own. Ollama gives you a model server and an API, and nothing else: no document store, no agent builder, no MCP client. AingDesk's value is the assembly, and its cost is the same assembly: you inherit its SQLite schema, its directory layout, and its release cadence instead of choosing your own. The topics on the repository (deepseek, electron, llm, localai, nodejs, ollama) confirm the intended position, with Ollama as the local runtime rather than as a competitor.

Licence, upgrades, and what maintenance costs

AingDesk is MIT licensed, and the LICENSE file sits at the repository root. MIT is permissive: you can use, modify and redistribute it, including in commercial settings, provided the copyright notice and licence text are preserved. That is the general shape of the licence, not advice about your situation; read LICENSE yourself and get counsel if the deployment is commercial. The upgrade cost is the part the README does not settle. There is a build pipeline with encryption (ee-bin encrypt) and separate Go and Python builds, which suggests the maintainers carry real release engineering. What is missing is the operator-facing half: no documented migration between versions, no stated compatibility between a running container and a newer image, no version pinning guidance. Practically, that means an upgrade is a manual exercise. Snapshot the /data and /sys_data mounts, pull the new image, start it against a copy of the data first, and confirm the knowledge base still opens before touching the original. None of those steps are in the README.

Editorial conclusion

AingDesk fits engineers and small teams who want a self-hosted assistant with a knowledge base and MCP tool calling without assembling the stack themselves, and who are comfortable reading source when the documentation stops. It does not fit anyone who needs a documented upgrade path, a published API reference, or a project with recent releases: the newest release listed is v1.2.4 from 2025-05-27, while the last push to main was 2026-06-04. Before adopting it, verify the licence file at the repository root, confirm the Docker image tag you intend to pull, and check whether the knowledge base and agent features you need are covered by the docs at docs.aingdesk.com rather than only by the screenshots in the README.

Frequently asked questions

Official sources

1. aingdesk/AingDesk on GitHub
2. License: MIT
3. Project website
4. README
5. Releases