trycompai/comp: self-hosting the AGPL compliance platform
AI Native platform to get companies compliant - Vanta & Drata Alternative
At a glance
- What is it?
- Comp AI is an open source alternative to Vanta and Drata, built as a Bun and Turborepo monorepo with Next.js, Prisma and Trigger.dev. Here is how it installs, what it automates, and where self-hosting gets expensive.
- Who is it for?
- Adopt Comp AI if your team already runs Postgres and Docker and wants compliance evidence to stay inside infrastructure you control, and if the AGPL-3.0 licence is acceptable for how you plan to distribute or modify it. Do not adopt it if you have no one to operate Trigger.dev, Upstash Redis, S3 buckets and Resend, because the README's setup path assumes all of them.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Comp AI solves, and for whom
Compliance work for SOC 2, ISO 27001, HIPAA or GDPR is mostly evidence collection and policy upkeep. Someone has to prove that access reviews happened, that policies were acknowledged, and that controls are still in place at audit time. Comp AI aims to automate that collection and the policy management around it, while the README states the platform keeps you in control of your data and infrastructure. That last phrase is the actual pitch. Vanta and Drata are hosted services, so your evidence lives in their tenancy. Comp AI is AGPL-3.0 and ships a Dockerfile, docker-compose.yml and a SELF_HOSTING.md, so the same workflow can run on your own Postgres.
The audience is narrower than the tagline suggests. A two-person startup chasing its first SOC 2 report will get to value faster on a hosted product, because Comp AI's local setup requires Node 20 or newer, Bun 1.1.36 or newer, and Postgres 15 or newer before you see a single control. The better fit is an engineering-led company that already runs its own infrastructure and treats compliance data as sensitive enough to keep in-house, or a team that wants to read and modify the code that decides whether a control passes.
The monorepo layout behind Comp AI
The repository is a Turborepo workspace. The top level holds apps/ and packages/, plus turbo.json, bun.lock and a syncpack config for keeping dependency versions aligned across packages. The README names the stack directly: Next.js, Trigger.dev, Prisma, Tailwind CSS, Upstash and Vercel. The topic list adds Auth.js and Zod.
The split that matters operationally is between the app and the portal. docker-compose.yml defines two long-running services: app on port 3000 and portal on port 3002. The portal is the employee-facing surface, and the README's environment example sets NEXT_PUBLIC_PORTAL_URL to http://localhost:3002 as its default. Background work does not run inside those containers. It runs on Trigger.dev, which is why the compose file only lists migrator, seeder, app and portal. Evidence collection and scheduled jobs therefore depend on an external service unless you point TRIGGER_API_URL at a self-hosted instance, which the .env.example notes is the only reason to set that variable.
Prisma sits underneath both apps. The README's development steps run db:generate separately in apps/app, apps/portal and apps/api, which tells you each app consumes generated client types rather than sharing one generated output. The Dockerfile takes a different route for containers: it installs the published @trycompai/db package instead of the local packages/db workspace, and the migrator stage builds a minimal package.json around prisma, @prisma/client and @trycompai/db. Local development and container deployment do not use the same database package, and that asymmetry is worth knowing before you debug a migration that behaves differently in Docker.
Installing Comp AI locally with Bun and Postgres
The README's prerequisites are Node.js >= 20.x, Bun >= 1.1.36 and Postgres >= 15.x. Start by cloning and installing at the root.
git clone https://github.com/trycompai/comp.git
cd comp
bun installNext, create the three environment files. The README gives separate commands for Linux and macOS, Windows Command Prompt, and PowerShell.
cp apps/app/.env.example apps/app/.env
cp apps/portal/.env.example apps/portal/.env
cp packages/db/.env.example packages/db/.envThe README warns that if you copy from .env.example, it may be missing NEXT_PUBLIC_PORTAL_URL and REVALIDATION_SECRET, so add both manually to apps/app/.env. AUTH_SECRET and REVALIDATION_SECRET are generated with openssl rand -base64 32. DATABASE_URL follows the postgresql://user:password@host:port/database form.
Database setup happens inside packages/db, which brings up a Docker container and runs migrations.
cd packages/db
bun run docker:up
bun run db:migrateThen generate Prisma types per app, as the README instructs.
cd apps/app
bun run db:generate
cd ../portal
bun run db:generate
cd ../api
bun run db:generateFinally, run everything in parallel from the root. The app serves on port 3000 and the portal on 3002; the compose file healthchecks the app at /api/health. Before any of this produces a usable instance, the README also requires a Trigger.dev project ID set in apps/app/trigger.config.ts, Google OAuth credentials with the listed redirect URIs, and an Upstash Redis database.
Where self-hosting Comp AI gets awkward
The dependency list is the honest limitation. Comp AI is open source, but a working local instance needs Trigger.dev for background jobs, Upstash for Redis, Google OAuth for sign-in, Resend for email, and S3-compatible storage for attachments. The .env.example marks the AWS variables as recommended, then notes that APP_AWS_QUESTIONNAIRE_UPLOAD_BUCKET is required for the Security Questionnaire feature and APP_AWS_KNOWLEDGE_BASE_BUCKET is required for its Knowledge Base. OPENAI_API_KEY powers AI chat and auto-generated policies, risks and vendors; FIRECRAWL_API_KEY covers research. None of those are optional if you want the features the README advertises.
The README also admits a configuration failure mode in plain text: some environment variables may not load correctly from .env, and the suggested workaround is to hard-code the values directly in the relevant files. It repeats this for Google credentials, pointing at apps/portal/src/app/lib/auth.ts. Hard-coding secrets into source is a real operational risk in a repository you intend to keep pulling from, and it makes rotation a code change rather than a config change. Treat that workaround as a symptom to investigate, not a permanent pattern.
Maintenance is not the problem. The last push was on 2026-09-09, and the most recent release listed is v3.111.1 on 2026-08-05, with a device agent staging build the same period. The repository is not archived. The cost is operational instead: four external services, three .env files, and a Trigger.dev project to keep running.
Comp AI against Vanta and Drata
The README positions Comp AI as the open-source alternative to Vanta and Drata, and the difference is not the framework list. All three cover SOC 2, ISO 27001, HIPAA and GDPR. The difference is where the evidence lives and who can change the logic that collects it.
With Vanta or Drata, you connect your cloud accounts to a vendor-hosted platform, and the integration catalogue and control mappings are theirs. You get a support contract and someone else carries the uptime. With Comp AI, you run the database, you own the Postgres instance holding the evidence, and you can read the integration code. The repository ships an integrations-catalog/ directory and separate packages/integrations and packages/integration-platform, so integrations are a first-class part of the codebase rather than a black box.
That trade runs both ways. A hosted vendor absorbs the Trigger.dev, Redis and storage plumbing. Comp AI hands it to you, along with the upgrade work that comes with a project releasing at v3.111.x. If your reason for choosing open source is data residency or auditability of the control logic, the trade is worth it. If it is only licence cost, the engineering hours likely erase the saving.
Licence and upgrade cost for Comp AI
Comp AI is licensed under AGPL-3.0, shown in the README badge and the LICENSE file at the repository root. AGPL-3.0 is a strong copyleft licence with a network clause: if you modify the software and let users interact with it over a network, the licence's terms about offering the corresponding source apply. Running an unmodified instance internally is a different situation from building a modified product on top of it. This is a description of the licence, not legal advice; if you plan to redistribute or offer a modified version as a service, have counsel read the actual terms.
Upgrade cost is visible in the release cadence. Releases listed run from v3.111.0 on 2026-07-29 to v3.111.1 on 2026-08-05, and the root package.json carries version 1.50.0, so the app and the workspace do not version in lockstep. The repository uses semantic-release with commitlint and conventional commits, which means changes land frequently and the changelog is generated. For a self-hoster, that means pinning to a tag rather than tracking main, and reading CHANGELOG.md before each bump. The Dockerfile pins oven/bun:1.2.8 while package.json declares packageManager bun@1.3.4, so container builds and local builds use different Bun versions; check that before assuming a build behaves identically in both.
Editorial conclusion
Adopt Comp AI if your team already runs Postgres and Docker and wants compliance evidence to stay inside infrastructure you control, and if the AGPL-3.0 licence is acceptable for how you plan to distribute or modify it. Do not adopt it if you have no one to operate Trigger.dev, Upstash Redis, S3 buckets and Resend, because the README's setup path assumes all of them. Before committing, verify the hardcoding workaround the README describes for environment variables that do not load, and confirm which of the required variables your .env.example copy is missing.
Frequently asked questions
What is trycompai/comp?
It is an open source compliance platform that the README describes as an alternative to Vanta and Drata, covering frameworks such as SOC 2, ISO 27001, HIPAA and GDPR. It automates evidence collection, policy management and control implementation, and is licensed under AGPL-3.0.
How do I install Comp AI locally?
Clone the repository, run bun install, copy the three .env.example files into apps/app, apps/portal and packages/db, then run bun run docker:up and bun run db:migrate inside packages/db. The README requires Node.js >= 20.x, Bun >= 1.1.36 and Postgres >= 15.x, and notes you may need to add NEXT_PUBLIC_PORTAL_URL and REVALIDATION_SECRET manually.
Which external services does Comp AI need to run?
The README's setup requires a Trigger.dev project for background jobs, Google OAuth credentials, and an Upstash Redis database. The .env.example also lists Resend for email, S3-compatible storage for attachments, and OPENAI_API_KEY for AI chat and auto-generated policies, risks and vendors.
Is Comp AI a replacement for Vanta or Drata?
The README positions it as an open source alternative, and the framework coverage overlaps. The practical difference is that you host the Postgres database and the integration code yourself, and you take on running Trigger.dev, Redis and storage rather than paying a vendor to operate them.
Community notes