pacod-demo

Try it

The demo runs at demo.pacod.io. Its home page lists every product, with what it is, a screenshot, and the links to its administration and its websites. Each product lives on its own subdomain:

One sign-in covers every product: signing in to one signs you in to all of them.

Why it exists

Each pacod project runs on its own, with its own copies of what it needs: a database, an edge, a sign-in, a gateway. That is the right way to try one. It is not how they are meant to be used together, and it does not show what they add up to.

pacod-demo is the other way round. It puts the five products on one machine, as one platform, with one of each shared component, and shows the things that only appear when they run together: one sign-in that every product honours, one gateway that every model call goes through and that prices them all, and one set of dashboards for the whole stack.

How it is put together

• One network, unique names. All five repositories follow one convention: every container joins the external Docker network pacod-net under a name unique across the repositories. Shared components are called pacod-*; everything else carries its owner's prefix (gw-, ap-, cms-, kb-).
• The repositories' own compose files. Each repository splits its compose setup into an app file, with its own services, and a standalone file, with its own copies of the shared components for running it alone. The demo includes the five app files unchanged. A small overlay per repository only removes published ports, points settings at the demo's files and sets the public addresses.
• One of each shared component. One Caddy, one PostgreSQL with a database and owner role per product, one Qdrant, one embeddings service, one pacod-id, one gateway, one mail sink, and one monitoring stack (Prometheus, Alertmanager, Grafana, the OpenTelemetry collector). Each builds on the definition a repository already ships, and takes the products' contributions from their platform/ directories: Caddy site blocks, database scripts, Prometheus jobs, rules and dashboards.
• Product-owned stores stay with their product. The gateway's ClickHouse, the CMS's MongoDB (one database per website) and Gotenberg, and the agent platform's Redis and pgbouncer.
• The bootstrap drives the products' own scripts: pacod-ap's gateway and identity bootstrap and pacod-cms's provisioner. It creates the gateway keys and service tokens the products use to reach each other.

Configuration

Two files. demo.env is the configuration, and it is committed: the domain and ports, the certificate, the first administrator's email, the models each product uses, the embedding backend and the optional components. demo.local.env holds the machine's secrets, the administrator's password and the LLM provider keys; git ignores it, and what it sets wins.

# demo.local.env
DEMO_ADMIN_PASSWORD=a-long-passphrase
ANTHROPIC_API_KEY=sk-...

LLM providers. With no key set, every model call goes to the gateway's mock provider: the demo runs offline and make verify is deterministic, but chat answers are canned. Add a key and run make bootstrap, and the gateway is set up with the real provider.

The embedding backend is fixed at the first make up, because the stored vectors depend on it. The default, auto, uses the real BGE-M3 model when Docker has the memory for it and a light stand-in otherwise.

The optional ingestion component runs the agent platform's document ingestion and loads the starter agent's knowledge base. It is a large image and wants 16 GB of memory for Docker.

On a domain, or on a laptop

With a certificate for the domain and its subdomains, the stack answers on HTTPS and plain HTTP only redirects. Published beyond the machine, the demo closes what is only safe on a laptop: the mail viewer, Prometheus and Grafana ask for the administrator's email and password, the home page does not name the administrator, and the agent platform's development tokens are off.

For a demo on one machine only, set DEMO_DOMAIN=localhost and DEMO_HTTP_PORT=8800, and leave the certificate empty. Everything is then plain HTTP at http://<name>.localhost:8800, which browsers resolve without any DNS.

What it needs

• Docker with Compose 2.24 or newer, and make. Everything else, from secret generation to the checks, runs in containers.
• The five project repositories checked out next to this one.
• About 8 GB of memory for Docker. The whole stack with the real embedding model uses about 5 GiB; with the light stand-in, about 4 GiB.
• About 30 GiB of disk for the images. The first make up builds every image from source, two Rust workspaces, a Maven build, several Python images and two SvelteKit apps, and takes 30 to 60 minutes. Later starts take about two minutes.

make down stops the stack and keeps the data; make clean removes everything the demo made. The README has the full list of settings and a troubleshooting table.