DataShield is under active development and is not production ready. The database schema, APIs and UI can change without notice, features may be incomplete or unstable, and breaking changes land regularly. Do not point it at real production data yet. Ce projet est en cours de construction.
Self-hosted service that tells a business whether its employees' data has surfaced in known breaches, with severity-based alerting and a customizable security dashboard.
Early development. Things move fast and not everything listed below is finished.
- Breach exposure monitoring per employee (Have I Been Pwned and manual sources)
- Customizable widget dashboard (drag and drop, saved presets)
- Employee directory sync: Microsoft Entra ID (Azure AD), Google Workspace, LDAP / Active Directory, AWS IAM Identity Center, Okta, and inbound SCIM 2.0
- Alerting by severity and status
- Next.js 15 (App Router), React 19, TypeScript in strict mode
- Prisma 7 with PostgreSQL
- Auth.js (next-auth v5)
- Tailwind CSS
The quickest path needs only Docker, no Node on the host. It builds the app, starts PostgreSQL, applies migrations and seeds demo data in one command.
make env # create .env.local with generated secrets
docker compose up # app on http://localhost:3000, database seededPrerequisites: Node.js 22 (pinned via .nvmrc and engines) and Docker for the
local database, or your own PostgreSQL instance. The make targets select the
pinned Node version automatically via nvm, so they work even when your shell's
default Node differs.
make setup # install deps, create .env.local, start DB, migrate, seed
make run # start the dev servermake doctor diagnoses the setup (toolchain, env, Docker, DB, Prisma) and can
auto-fix common issues, including creating .env.local and switching to Node 22.
The underlying npm steps (npm install, npm run db:init, npm run dev) still
work if you prefer them.
Open http://localhost:3000 and sign in with the seeded admin account:
admin@datashield.local / ChangeMe123!
With docker compose up, migrations and the demo seed run on every start, so a
fresh machine is ready right after git pull.
On the host, the Prisma client is regenerated automatically on npm install
(postinstall). The database is not migrated automatically: npm run dev
only warns if migrations are pending (it never applies them on boot). After
pulling changes that add a migration, apply it explicitly before running the app:
npm run db:migrate # prisma migrate deploy, applies pending migrationsWhen you edit prisma/schema.prisma yourself, create the migration instead:
npx prisma migrate dev --name <change>npm run db:initstarts a Postgres container (compose.yml), applies all migrations and seeds demo data (breaches, employees, alerts).npm run db:up/npm run db:downstart and stop the container.npm run db:migrateapplies pending migrations to the current database.npm run seed:devreseeds the demo data;npm run seedseeds only the admin.
No Docker? Point DATABASE_URL at your own PostgreSQL, then run
npx prisma migrate deploy && npm run seed:dev.
All variables live in .env.local (copied from .env.example). AUTH_SECRET
must be set; the rest have working defaults for local development.
Every push and pull request runs an automated pipeline: ESLint (zero warnings
allowed), strict type checking, Prisma schema validation and a production build,
plus CodeQL static analysis, dependency auditing, dependency review and secret
scanning. See .github/workflows. Security policy and
reporting: SECURITY.md.
Contributions are welcome.
Contribution rules are enforced automatically by Git hooks (
.githooks/) and CI (.github/workflows/compliance.yml). Non-compliant PR titles are rejected: invalid conventional commit format, AI attribution trailers, secrets, non-English text, frozen-dependency major bumps, and forbidden code patterns. The hooks activate onnpm install.
Please also read CONTRIBUTING.md and CODE_OF_CONDUCT.md.
See LICENSE.