Alex/eng 10 internal oss offering have bad documentation hard to setup

[Marfuen]

What does this PR do?

• Fixes #XXXX (GitHub issue number)
• Fixes COMP-XXXX (Linear issue number - should be visible at the bottom of the GitHub issue description)

Visual Demo (For contributors especially)

A visual demonstration is strongly recommended, for both the original and new change (video / image - any one).

Video Demo (if applicable):

• Show screen recordings of the issue or feature.
• Demonstrate how to reproduce the issue, the behavior before and after the change.

Image Demo (if applicable):

• Add side-by-side screenshots of the original and updated change.
• Highlight any significant change(s).

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

• Are there environment variables that should be set?
• What are the minimal test data to have?
• What is expected (happy path) to have (input and output)?
• Any other important info that could help to test that PR

Checklist

• I haven't read the contributing guide
• My code doesn't follow the style guidelines of this project
• I haven't commented my code, particularly in hard-to-understand areas
• I haven't checked if my changes generate no new warnings

[linear]

ENG-10 [Internal] OSS offering, have bad documentation, hard to setup

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
app	Ready	Preview	Comment	Oct 31, 2025 10:05pm
portal	Ready	Preview	Comment	Oct 31, 2025 10:05pm

[comp-ai-code-review]

🔒 Comp AI - Security Review

🔴 Risk Level: HIGH

No OSV CVEs found in scanned packages. Documentation (SELF_HOSTING.md) references plaintext .env secrets and credential names.

---

📦 Dependency Vulnerabilities

✅ No known vulnerabilities detected in dependencies.

---

🛡️ Code Security Analysis

View 1 file(s) with issues

🔴 SELF_HOSTING.md (HIGH Risk)

#	Issue	Risk Level
1	Sensitive secrets in service .env files (AUTH_SECRET, OPENAI_API_KEY, etc.)	HIGH
2	DATABASE_URL contains plaintext DB credentials	HIGH
3	Root .env may be accidentally committed to version control	HIGH
4	NEXT_PUBLIC_* build args can expose secrets to client bundles	HIGH
5	Docker build args may leak secrets into image layers	HIGH
6	AWS keys stored in env may be exposed if container compromised	HIGH
7	Shared API keys (RESEND_API_KEY) used across app and portal	HIGH
8	No guidance to use Docker secrets or external secret manager	HIGH
9	No file permission guidance for .env files	HIGH
10	No default rate limiting or input validation configured	HIGH
11	Trigger.dev keys lack least-privilege / scoping guidance	HIGH
12	Portal auth secret stored in portal .env without rotation guidance	HIGH

Recommendations:

1. Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager) or Docker secrets to inject secrets at runtime rather than storing them in plaintext .env files or passing them as build args.
2. Do not expose secrets in NEXT_PUBLIC_* variables. Only put truly public values in client-accessible build/time env vars. Keep all API keys, DB credentials, and private secrets server-side.
3. Avoid passing secrets as Docker build args. If build-time secrets are required, use Docker BuildKit --secret or a secrets manager integration so secrets are not baked into image layers.
4. Ensure DATABASE_URL does not contain superuser or long-lived credentials. Use a least-privileged DB user and limit its network access (VPC, IP allowlist). Prefer ephemeral or rotated credentials where possible.
5. Give each service its own API key/credentials (do not share RESEND_API_KEY between app and portal). Use scoped keys and rotate them regularly.
6. Use IAM roles / instance/task roles (ECS, EKS, EC2) or workload identity (GCP) instead of long-lived AWS access keys when running in cloud environments. Restrict S3 IAM policy to the minimum required actions and prefix.
7. Add .env and other secret files to .gitignore, add pre-commit hooks (git-secrets, commit-guard) and CI scanning to prevent accidental commits of secrets. Remove any committed secrets and rotate credentials if they were ever committed.
8. Set strict filesystem permissions on .env files (e.g., chmod 600, owned by the service user) and document secure storage/transfer procedures for secrets.
9. Provide guidance and examples for using runtime secret injection for Docker Compose (external env files mounted at deploy time, or use docker swarm/kubernetes secrets) rather than building them in.
10. Document and enforce key rotation policies (how to rotate AUTH_SECRET, BETTER_AUTH_SECRET, TRIGGER_SECRET_KEY, AWS keys, OpenAI keys, etc.), and provide guidance for rolling secrets without downtime.
11. Enforce least-privilege on Trigger.dev and other 3rd-party keys; create scoped project-level tokens; document what scopes are required and recommend short-lived credentials where supported.
12. Add security-hardening checklist: enable DB SSL enforcement, restrict DB user privileges, enable S3 bucket policies & versioning, network restrictions for services, monitoring/alerts for failed auth attempts and suspicious usage patterns.
13. Recommend implementing rate limiting (server-side) and input validation for public endpoints; include examples or references to middleware/libraries used by the project for throttling and validation.
14. Recommend CI/CD scanning: secret scanning, dependency vulnerability scans, and image scanning to detect secrets in images and known vulnerable packages before deployment.

---

💡 Recommendations

View 3 recommendation(s)

1. Verify the repository does not contain committed secret values: search for patterns like DATABASE_URL=, OPENAI_API_KEY=, AUTH_SECRET=, RESEND_API_KEY= and remove any real values. Ensure .env files with real secrets are not tracked.
2. If secrets were committed, remove them from the repository and its history (e.g., git rm --cached, then rewrite history with git filter-repo/git-filter-branch) and replace with placeholders; rotate any exposed credentials.
3. Replace any real example env files in the repo with .env.example using clearly fake placeholders (e.g., <REPLACE_ME>) and update docs to reference only example filenames, not files containing real secrets.

---

Powered by Comp AI - AI that handles compliance for you. Reviewed Oct 31, 2025