PACOD is a family of open-source projects for building AI products on machines you control: an AI gateway, an identity provider, an agent platform, a content management system and a RAG knowledge base. Each is a complete product with its own repository, documentation and Docker setup. They are also designed to run together, and a sixth project, pacod-demo, runs all five as one platform. This post is the overview. The posts after it take the projects one at a time.
The projects
| Project | What it is |
|---|---|
| pacod-gw | An AI gateway. It holds the provider keys, prices every call and enforces quotas. |
| pacod-id | An OpenID Connect provider with accounts, organisations and role bindings. |
| pacod-ap | An agent platform: many self-contained agents on one deployment. |
| pacod-cms | A CMS for editorial websites. One installation hosts many sites. |
| pacod-kb | A RAG knowledge base: ingestion, hybrid search, every version kept. |
| pacod-demo | The five together on one machine, from one configuration file. |
Two of them are infrastructure. pacod-gw sits between applications and the language-model providers. pacod-id signs people and machines in. The other three are products built on top of them, for agents, content and knowledge.
How they fit together
Two rules hold across the platform. Every LLM call goes through the gateway. Every person signs in through the identity provider.
The first rule means the products on top never hold a provider's key. The agent platform, the CMS studio and the knowledge base call the gateway with a gateway key. The gateway decides which model serves a call, what it may cost and who it is attributed to, so usage and cost are counted in one place.
The second rule means no product runs its own passwords, account mails or account pages. pacod-id records who may do what. Each product follows its feed of role bindings and decides access locally, without a round trip per request.
Run together, the projects share one of each common component: one edge, one database server, one
vector store, one set of dashboards. Every container joins one Docker network, pacod-net, under a
name that is unique across the repositories. That convention lets the projects' own compose files
be combined without editing them.
A few firm ideas
- Open source. The code is under the Apache-2.0 licence, with the source, the tests and the threat models in the open. The CMS studio bundles the TinyMCE editor, which is GPL-licensed, so the studio as built is redistributed under GPL-3.0 terms as a whole.
- Self-hosted. Docker Compose for a laptop, Helm charts where it matters. Your data stays on your machines.
- One sign-in. pacod-id signs people in to every product and records what they may do.
- One gateway. pacod-gw holds the keys, prices the calls and enforces the quotas, for every product.
- Limits written down. The documentation says what has not been tested yet, next to what has.
Issues and ideas are welcome on GitHub. Code contributions are not accepted for now.
Run one, or all of them
Each project runs alone. Its standalone compose file brings its own copies of the shared parts, and the projects that call a model use the gateway's mock provider, so nothing leaves the machine until you add a real provider key. That is the right way to try one project.
pacod-demo is the other way round. It puts the five products on one machine, behind one address and one sign-in, with one gateway that every model call goes through. Signing in to one product signs you in to all of them.
Start with the projects and how they fit together, browse the code on GitHub, or open the live demo.
Update, 28 October. Since this post, a sixth project has joined the family: pacod-benchmark, which measures what the gateway adds to a call, in many configurations at once. pacod-demo now runs all six. What the gateway really adds walks through its first run.
