Skip to content

Back to the catalog

GigaChad GRC
github.comrepo

GigaChad GRC

GigaChad GRC is a self-hosted, containerized Governance, Risk & Compliance platform covering compliance tracking, risk management, policy lifecycle, third-party risk management (TPRM), audit management, and a trust center/questionnaire module. It runs entirely via Docker Compose (Node.js/NestJS microservices, React frontend, PostgreSQL, Redis, Keycloak for SSO/RBAC with a dev-auth bypass, Traefik gateway), and is licensed under Elastic License 2.0 (free for internal use, not for resale as a hosted service).

TL;DR Open-source, self-hosted, Docker-based GRC platform under Elastic License 2.0.
Open original ↗
Document

What it is

GigaChad GRC's quick-start flow, run via ./start.sh (or start.bat on Windows). The security-relevant detail the summary omits: the default startup path enables an authentication bypass. start.sh sets VITE_ENABLE_DEV_AUTH=true, which surfaces a "Dev Login" button on the frontend that logs in with no username or password, bypassing Keycloak SSO entirely and using a local development account.

How it works

start.sh auto-generates a .env with random secrets, builds all containers, and sets VITE_ENABLE_DEV_AUTH=true. The page frames this as necessary because "Keycloak requires HTTPS, which is not available in local Docker development." The Dev Login button only renders when that flag is true and the frontend is rebuilt (docker compose up -d --build frontend). If you skip start.sh and hand-write .env, you must set the flag yourself for Dev Login to appear.

Preconditions / Affected

Any instance started with ./start.sh, or any manual .env with VITE_ENABLE_DEV_AUTH=true. The service listens on http://localhost:3000 by default. The bypass is a real login path, not just a UI convenience — it means anyone able to reach the frontend can authenticate. Nothing on the page states this flag is disabled for production; it is silently enabled by the documented onboarding path.

What to do

For anything beyond local testing, verify the flag is unset before exposing the frontend. Manual secret generation (the non-start.sh path) uses:

# ENCRYPTION_KEY
openssl rand -hex 32
# JWT_SECRET, SESSION_SECRET
openssl rand -base64 64
# POSTGRES_PASSWORD, REDIS_PASSWORD, MINIO_ROOT_PASSWORD,
# GRAFANA_ADMIN_PASSWORD, KEYCLOAK_ADMIN_PASSWORD, PHISHING_TRACKING_SECRET
openssl rand -base64 24

DATABASE_URL must be updated to match the generated POSTGRES_PASSWORD. Compose refuses to start with any of these empty. For production, consult the linked Deployment Guide and Production Deployment Checklist (the page references but does not reproduce them).

Caveats

  • The page treats Dev Login as expected local behavior and does not flag it as a risk — that assessment is the reason to read this before deploying.
  • Ports 5433 (Postgres), 6380 (Redis), 8080 (Keycloak), 9000/9001 (RustFS), and 3001–3007 (services) are exposed; check for conflicts and unintended exposure.
  • docker compose down -v deletes all database data, evidence files, and cached sessions — back up first.
  • Requirements: Docker Desktop 4.0+, 8 GB RAM / 4 cores / 10 GB disk minimum (16 GB / 8 cores / 20 GB recommended).

Technologies named here

Related in GRC