# AIdea Server: a Go backend for GPT, Qwen and Stable Diffusion in one API

> AIdea Server is the Golang backend behind the AIdea mobile app, exposing an OpenAI-compatible API on top of many Chinese and Western chat models plus image generation. It is a self-hosted product backend, not a library, and the README warns that code comments and technical documentation are still limited.

**mylxsw/aidea-server** — AIdea 是一款支持 GPT  以及国产大语言模型通义千问、文心一言等，支持 Stable Diffusion 文生图、图生图、 SDXL1.0、超分辨率、图片上色的全能型 APP。

- Repository: https://github.com/mylxsw/aidea-server
- Website: https://ai.aicode.cc
- Stars: 1,761 · Forks: 474
- Language: Go
- License: not declared
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/mylxsw-aidea-server

## What AIdea Server actually is, and who it is built for

AIdea Server is the server half of AIdea, an application that combines chat with large language models and image generation. The README describes it as "a fully open-source APP server built with Golang that integrates mainstream large language models and image generation models", and it lists a separate client repository (mylxsw/aidea), this server repository, and a Docker deployment repository (mylxsw/aidea-docker). So the intended user is not someone who wants a chat library to call from their own code. It is someone who wants to run the backend that an existing mobile or desktop client talks to.

That distinction matters when you evaluate it. A large part of this codebase exists to serve product concerns rather than model concerns: user accounts, token accounting, payment, SMS verification, file upload and a task queue. The repository layout confirms this. Under pkg you find sms, mail, uploader, token, rate and proxy packages, and under internal you find queue, queue/consumer, payment and coins. The coins package is where service pricing and billing policies live, and there is a coins-table.yaml example pricing table at the repository root. If your problem is "charge users for model calls and generate images for them", this is closer to what you need than a thin SDK wrapper. If your problem is "call a model from a Go service", most of this repository is overhead.

## The two API surfaces: OpenAI-compatible and client-specific

The code structure table in the README splits the HTTP layer in two. The api directory is described as an "OpenAI-compatible API" whose "endpoints here can be used directly by any third-party software that supports the OpenAI API protocol". The server directory holds "API endpoints provided for the AIdea client application". That is a useful separation to understand before you deploy anything, because it tells you which endpoints you can point existing tooling at and which ones are effectively private contract between this server and the AIdea app.

The compatibility claim is backed by how chat models are wrapped. The README says the pkg/ai/chat package is an "abstract chat model interface" and that "all chat models are wrapped here to be compatible with the OpenAI Chat Stream protocol". In other words, the abstraction is not a lowest-common-denominator request object; it normalises providers to an OpenAI-shaped streaming chat response, which is why third-party OpenAI clients can be aimed at the api endpoints. The go.mod file shows the provider breadth behind that wrapper: Alibaba Cloud (dysmsapi, green content safety), Tencent Cloud (aiart and hunyuan), Stripe, WeChat Pay, Apple sign-in, and the sashabaranov/go-openai client. Note the direction of that last dependency: this server is also a consumer of OpenAI's API, not just a re-exporter of it.

One naming trap is documented explicitly. The README warns that "Room" and "Advisory Group" in the code both refer to "Digital Persona", the result of multiple revisions, and that the v1 version of "Creation Island" is entirely different from v2, with v1 serving App versions up to 1.0.1 and unused from 1.0.2 onward. Read the code with that in mind, or the domain model will look inconsistent when it is only historically layered.

## Building and running it from source

The README points self-hosters at docs/deploy.md for the deployment guide, and the repository ships a Dockerfile, a Makefile, an example config.yaml, an example nginx.conf and a systemd.service file. The Dockerfile is a two-stage build: a golang:1.21 builder with GOPROXY set to https://goproxy.io,direct, then an ubuntu:22.04 runtime that installs tzdata, ca-certificates and ffmpeg, copies the resources directory, exposes port 8080, and starts the binary with a configuration file.

The entrypoint line is the part to notice, because it tells you where the config is expected to be mounted:

```dockerfile
ENTRYPOINT ["/usr/local/bin/aidea-server", "--conf", "/etc/aidea.yaml"]
```

So a container run needs /etc/aidea.yaml present, and the repository's config.yaml is the example to base it on. The image also expects a resources directory at /data/resources, which the Dockerfile creates and populates from the build context.

If you prefer to build the binary yourself, the Makefile defines the targets. The default build target runs the swagger documentation step first, then compiles with race detection and debug flags:

```bash
make build
```

That target depends on the doc target, which runs swag init. The Makefile notes that swag must be installed first via go install github.com/swaggo/swag/cmd/swag@latest. For a plain Linux binary without the race and debug flags, use the narrower target:

```bash
make build-linux
```

The Makefile writes the build version as a date string in YYYYMMDDHHMM form and embeds the git commit through linker flags, which is why the release tags in this repository look like 202404071800 rather than semantic versions. There is also an orm target that regenerates the model layer from pkg/repo/model/*.yaml using the eloquent generator, and then runs gofmt over the generated files. If you edit those YAML definitions, run make orm rather than hand-editing the generated Go.

## What the README does not tell you

The most honest sentence in the README is the one about documentation: "Code comments and technical documentation are currently limited and will be supplemented over time." Treat that as a real constraint rather than boilerplate. The deployment guide is referenced but its contents are not reproduced in the README, so the required database, the Redis configuration and the set of mandatory environment values are things you will discover from docs/deploy.md and config.yaml, not from the front page.

The dependency list also tells you something the README does not spell out. A large share of the provider integrations are Chinese cloud services: Alibaba Cloud SMS and content safety, Tencent Cloud speech-to-text, SMS and the hunyuan and aiart model APIs, Qiniu Cloud Storage for uploads and text-to-speech, Youdao for translation, DingTalk for notifications, plus WeChat Pay and Alipay. The pkg/voice package is described as text-to-speech backed by Qiniu Cloud and "currently disabled", so that capability is not available in the current tree even though the package exists. If you are deploying outside mainland China, expect to either replace these integrations or accept that several features will be inert.

Finally, the licence is the largest open question. The repository metadata does not identify one, and the README does not state one either. "Fully open-source" in the description is a claim about the source being available, not a grant of rights. Until you find a licence file, you cannot assume you may redistribute this code or run it as a commercial service, and that uncertainty affects the billing and payment code most of all, since that is the part you would be monetising.

## How it compares with LiteLLM and OpenRouter

The obvious alternative for the same problem is LiteLLM, a Python proxy that presents one OpenAI-compatible endpoint in front of many providers. The difference in approach is scope, and it is not a small one. LiteLLM is a router and a cost-tracking layer: you give it provider keys, it gives you a unified chat completions endpoint, and it stays out of the way of your application. AIdea Server is an application backend. It owns users, sessions, token consumption records, queue consumers for asynchronous work, file uploads, SMS login and payment flows, and its OpenAI-compatible surface is one directory among several.

That means the two are not really substitutable. If you already have an app and you want to stop rewriting provider adapters, LiteLLM solves your problem in an afternoon. If you are building the app itself and do not want to write account, billing, queue and payment code, AIdea Server gives you a starting point that is much further along, at the cost of adopting someone else's domain model and deployment assumptions. A hosted router such as OpenRouter is a third position: no deployment at all, but also no control over keys, no self-hosted data path, and no billing logic you own.

The practical question is which half of AIdea Server you actually need. The pkg/ai directory is the part that resembles LiteLLM, and it is the part most likely to be reusable on its own, since the README describes pkg as "public packages that can be imported by other projects". The server, internal/queue and internal/payment directories are the parts that make it a product rather than a router, and they are also the parts with the least documentation.

## Maintenance, releases and what upgrading costs

The last push to the default branch was on 2026-03-18. The most recent tagged release is 202404071800 from 2024-04-07, described as covering Stripe, stopping output, and model channels; before that came 202402201630 (WeChat login, common-model improvements, a large batch of new language models) and 202401311800 (new art-text support served by Alibaba Cloud Jinshu). The gap between the last commit and the last release is the number you should plan around: there is no published release cadence to rely on, and version strings are timestamps rather than semantic versions, so you cannot infer compatibility from a version number.

Upgrading therefore means reading commits or rebuilding from a pinned commit hash rather than bumping a tag. The Makefile embeds the git commit into the binary, which helps you identify what is actually running, but there is no documented migration path between releases and no documented rollback procedure. The migrate directory holds SQL migration files, so schema changes are applied as migrations, and the practical upgrade step is to run those against your database before starting the new binary. The README does not document rollback, so if a migration is destructive you will need your own database backup step.

On licensing, the position is simply unknown. No licence identifier appears in the repository metadata or the README. That is not a legal opinion, but it is an operational fact: without a licence you have no stated permission to modify, redistribute or run the software commercially, and the presence of Stripe, WeChat Pay and Alipay integration code suggests the authors intended commercial deployment for someone. Ask the maintainers directly, through the WeChat group or the assisted-deployment contact in docs/deploy-vip.md, before you build a business on it.

## Conclusion

Adopt AIdea Server if you want a ready-made backend for a chat and image-generation app that already speaks the OpenAI protocol and already has billing, queueing, SMS and payment code written. Do not adopt it if you need a documented, stable API surface or a library you can embed: the README states that code comments and technical documentation are currently limited, and the last push was on 2026-03-18 with the most recent release dated 2024-04-07. Before committing, verify three things: that the repository actually carries a licence file, that docs/deploy.md covers the database and Redis you intend to run, and that the models you need are reachable from your network, because the provider list is dominated by Chinese cloud services.

## FAQ

### How do I install and self-host AIdea Server?

The README directs self-hosters to docs/deploy.md, and the repository provides a Dockerfile, an example config.yaml, an example nginx.conf and a systemd.service file. The container starts the binary with --conf /etc/aidea.yaml on port 8080, so that config file must be mounted.

### Does AIdea Server expose an OpenAI-compatible API?

Yes. The README describes the api directory as an OpenAI-compatible API whose endpoints can be used directly by third-party software that supports the OpenAI API protocol, separate from the endpoints under server that serve the AIdea client.

### Which models and providers does AIdea Server support?

The description names GPT, Tongyi Qianwen and ERNIE for chat, plus Stable Diffusion text-to-image, image-to-image, SDXL1.0, super-resolution and image colourisation. The dependency list shows Tencent Cloud hunyuan and aiart, Alibaba Cloud SMS and content safety, Qiniu Cloud Storage, Youdao and the go-openai client.

## Sources

- [Issues](https://github.com/mylxsw/aidea-server/issues)
- [mylxsw/aidea-server on GitHub](https://github.com/mylxsw/aidea-server)
- [Project website](https://ai.aicode.cc)
- [README](https://github.com/mylxsw/aidea-server/blob/main/README.md)
- [Releases](https://github.com/mylxsw/aidea-server/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mylxsw-aidea-server