Documentation

Install HUPI, set it up, and pick a tier.

Everything below is the condensed version, verified against the actual code. The full reference — every flag, every migration, troubleshooting — lives in the repo.

Quick install

The fast path: install.sh

Tiers 1 and 2 run from the same install and the same free, MIT-licensed build — there's no separate build or package between them. Tier 3 needs one additional thing this installer alone doesn't provide: the commercially-licensed hupi-t3extension, built in on top — see "Tier 3 licensing" below.

./install.sh                     # fully interactive — asks as it goes
./install.sh --tier=1 --yes      # non-interactive; fails loudly instead of
                                  # guessing when something has no safe default
./install.sh --help              # every flag, including pointing it at
                                  # Postgres/providers you already run

Safe to re-run — schema migrations, hupi.env, the encryption key, and the app role's password are all re-detected and reused rather than reapplied or rotated.

Prerequisites: PostgreSQL 16+ with pgvector, Go 1.25+ to build the binaries, and at least one LLM provider API key.

Manual setup

What install.sh automates, step by step

01

Postgres with pgvector

Any Postgres works as long as the pgvector extension can be enabled on it — managed or self-hosted, nothing else about your setup is special-cased.

                    docker run -d --name hupi-pg \
  -e POSTGRES_PASSWORD=hupi \
  -e POSTGRES_DB=hupi \
  -p 5432:5432 \
  pgvector/pgvector:pg16
                  
02

Apply the schema, in order

The migrations in schema/ are numbered and must be applied in that order — later ones depend on tables and columns earlier ones create.

                    export HUPI_ADMIN_DATABASE_URL='postgres://postgres:hupi@localhost:5432/hupi?sslmode=disable'

for f in schema/0*.sql; do
  psql "$HUPI_ADMIN_DATABASE_URL" -f "$f"
done
                  
03

Write providers.yaml

Name which AI vendor(s) to use for live chat, for consolidation, for the independent grounding check, and for embeddings — these can all be different vendors, or the same one. See providers.yaml.example.

04

Set the required environment variables

HUPI_APP_DATABASE_URL should point at the restricted hupi_app role (not the admin role), not the superuser you used to apply migrations.

                    export HUPI_APP_DATABASE_URL='postgres://hupi_app:pick-a-real-secret@localhost:5432/hupi?sslmode=disable'
export HUPI_KEK=$(head -c32 /dev/urandom | base64)
export HUPI_PROVIDERS_CONFIG=./providers.yaml
                  
05

Start the gateway

Listens on 127.0.0.1:8787 by default and speaks the standard OpenAI-compatible chat completions API — point any existing client at it.

                    ./bin/hupi
                  
06

Schedule consolidation

Run hupi-consolidate once daily (cron) so conversations get distilled into searchable, fact-checked summaries overnight. Optionally hupi-selfcheck weekly once you have a few probe questions.

Deployment tiers

One install, three ways to run it.

Tiers 1 and 2 run the exact same free software — which one you're using is purely operational (self-managed vs. IT-managed), not a different build. Tier 3 is a real architectural addition: real users/teams, authentication, and workspace routing — shipped as a separate, commercially-licensed extension rather than a config flag.

Tier 1 — Personal

One person, self-hosted

The base install. No Authorization header required or checked — every request resolves to a single built-in identity. Point any OpenAI-compatible client at your gateway and it works immediately.

Tier 2 — Professional (Single)

One person, deployed by an organization

Architecturally identical to Tier 1 — same binary, same install. The difference is operational: IT-managed rather than self-managed, secrets pulled from a real KMS instead of a local env var, an org retention policy enforced around the install rather than inside it.

Tier 3 — Professional (Shared)

A team, sharing some memory while keeping personal memory private

Real users/teams, HUPI_REQUIRE_AUTH=true, and the /v1/team/... routes. Team conversations consolidate into shared, third-person team knowledge visible to every member — while each member’s own private history, and their personal self_model, stay theirs alone. Identities come from hupi-admin-provisioned API keys or, via OpenID Connect, straight from your existing directory (Azure AD/Entra ID and other standards-compliant IdPs) — team membership included. Unlike Tiers 1/2, this isn’t part of the free build: it’s a separate, commercially-licensed extension — see "Tier 3 licensing" below.

Tier 3's data isolation — per-team encryption keys, row-level security, audit logging — is covered in detail on the FAQ page.

Tier 3 licensing

Free core, licensed team layer.

This repo — Tiers 1 and 2, everything most people run — is MIT-licensed and free forever. Team/shared-workspace support (Tier 3) is developed in a separate, privately-held repo (hupi-t3) under a commercial license — not free, not open source. It has to be built in on top of this repo (its own build.shdocuments exactly how, once you have a license); without it, this repo alone runs Tier 1/2 completely, with zero dependency on the extension at all — HUPI_REQUIRE_AUTH=truewith no license in place fails loudly at startup rather than silently doing nothing.

Team sizePriceBilled seats
1-9 members$50 / member / monthFlat minimum of 10 seats
10-200 members$40 / member / monthRounded up to the next multiple of 10 (e.g. 10-19 members bills as 20 seats), capped at 200
200+ membersContact work@hupi.dev

Contact work@hupi.dev to set up a Tier 3 commercial license.

Full reference

Every doc, on GitHub.

Using the VS Code extension instead of the raw API? It's on the Marketplace.

Give your AI product memory it doesn't have to trust blindly.

Self-hosted, open, and provider-independent — read the code, run it on your own infrastructure, point your own Postgres at it.