Skip to content

Back to the catalog

GigaChad GRC
github.comrepo

GigaChad GRC

GigaChad GRC is a self-hosted, containerized Governance, Risk, and Compliance platform covering controls/evidence, framework assessments, policy lifecycle, third-party risk management (TPRM), a trust center, and audit management. It's built as Node.js/NestJS microservices behind a Traefik gateway with PostgreSQL, Redis, Keycloak SSO, and RustFS storage, deployable via a one-command Docker Compose script, and licensed under Elastic License 2.0.

TL;DR Open-source, Docker-deployed GRC platform for compliance tracking, risk management, TPRM, and audits.
Document

What it is

GigaChad GRC's setup and troubleshooting documentation, which surfaces one security-relevant detail the summary omits: the platform ships with a Dev Login auth bypass that skips Keycloak SSO entirely, requiring no username or password and logging in as a local account.

How it works

The bypass is gated by a single frontend build-time variable, VITE_ENABLE_DEV_AUTH=true. When set, a "Dev Login" button appears on the login screen at http://localhost:3000 that authenticates with no credentials. The bundled ./start.sh (and start.bat on Windows) sets this variable automatically, so the default one-command install path enables the bypass out of the box. The page frames this as necessary because Keycloak requires HTTPS, which "is not available in local Docker development" — so the documented fix for any SSO failure is to fall back to Dev Login rather than configure TLS.

Preconditions / Affected

  • Any instance built with VITE_ENABLE_DEV_AUTH=true. Because it is a Vite build variable, toggling it requires rebuilding the frontend (docker compose up -d --build frontend), not just a restart.
  • Anyone reachable on port 3000 of such an instance can log in with no credentials.
  • Manual .env setups do not get this automatically — .env.example holds placeholders that "will not work as-is," and Compose refuses to start with missing/empty secrets.

What to do

If deploying beyond a throwaway local box, do not use ./start.sh unmodified — build the .env by hand and leave VITE_ENABLE_DEV_AUTH unset (or false), then rebuild the frontend so the button is absent. Generate real secrets rather than relying on the script:

# 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

Update DATABASE_URL to match the generated Postgres password. Note the non-default ports it exposes: Postgres 5433, Redis 6380, Traefik 80/443, RustFS 9000/9001, plus per-service ports 3001–3007. Grafana credentials (GRAFANA_ADMIN_USER/GRAFANA_ADMIN_PASSWORD) must be added manually if not using the script.

flowchart TD
    A[Install] --> B{Path?}
    B -->|"./start.sh"| C[VITE_ENABLE_DEV_AUTH=true set]
    B -->|manual .env| D[flag unset]
    C --> E[Dev Login button: no-credential access]
    D --> F[Keycloak SSO enforced]

Caveats

The page presents Dev Login purely as a local-development convenience and does not claim it is safe for shared or production use; it also points to a separate "Production Deployment Checklist" and "Deployment Guide" not reproduced here. Whether the bypass can leak into a production build depends entirely on the build-time flag, so verify the compiled frontend, not just the runtime config.