Build, manage, and grow your connected digital presence from one secure, modular platform.
Build & Security
Technology
Project Links
Issues
·
Pull Requests
·
Actions
·
Project Board
·
Security
Aerealith is a modular platform built to unify the public website, authenticated web application, documentation, developer portal, backend services, automation, and community tooling into one coherent ecosystem.
The project is designed around a simple idea:
Build shared foundations once. Reuse them everywhere. Keep every part understandable.
Aerealith is being developed as a secure, type-safe, maintainable monorepo with clear boundaries between applications, services, shared libraries, infrastructure, and automation.
| Area | Purpose |
|---|---|
| Public Experience | Website, product information, contact flows, and platform discovery. |
| Web Application | Authenticated user experience, account management, platform settings, and future product modules. |
| Documentation | Guides, technical documentation, onboarding, and platform knowledge. |
| Developer Portal | Internal and external developer experience, service documentation, API discovery, and integrations. |
| Platform Services | Authentication, user management, APIs, background processes, and future edge services. |
| Discord Platform | A modular Discord management system with independently configurable server modules. |
| Shared Foundation | Contracts, schemas, errors, validation, types, utilities, configuration, and UI primitives. |
| Security & Operations | Automated validation, quality gates, code scanning, dependency review, observability, and controlled delivery. |
Aerealith/
├── apps/
│ ├── frontend/ # Website, web app, docs, and developer portal
│ └── services/
│ ├── auth/ # Authentication service
│ ├── user/ # User and profile service
│ └── discord/ # Future Discord platform service
│
├── libs/
│ ├── core/ # Shared domain types, contracts, schemas, errors, constants
│ ├── db/ # Database entities, persistence, migrations, and data access
│ ├── api/ # Shared API abstractions and transport support
│ ├── ui/ # Shared user-interface primitives and components
│ ├── utils/ # Shared reusable utilities
│ ├── config/ # Centralized configuration support
│ └── flags/ # Feature-flag support
│
├── .github/
│ ├── config/ # Repository automation and policy configuration
│ ├── instructions/ # Coding-agent and repository instructions
│ ├── workflows/ # CI, security, orchestration, and delivery workflows
│ ├── ISSUE_TEMPLATE/ # Structured issue forms
│ └── PULL_REQUEST_TEMPLATE/ # Pull request templates
│
└── docs/ # Project documentation as the repository grows
apps/* and services/* → libs/*
libs/* → libs/core
libs/* ✕ other libs by default
The default rule is intentionally strict:
Libraries may depend on libs/core.
Libraries should avoid depending on each other unless there is a clear,
intentional reason to do so.
This keeps the platform easier to test, reuse, migrate, and self-host later.
|
Prefer the smallest complete solution over elaborate abstractions. |
Use strict TypeScript, runtime validation, explicit contracts, and predictable errors. |
|
Protect sensitive data, use least privilege, validate inputs, and require human review for high-risk work. |
Place reusable platform concepts in shared libraries instead of duplicating them across services. |
|
Features, services, and Discord modules should be independently understandable and configurable. |
Automate repetitive work, but keep security-sensitive and high-impact decisions under human control. |
- Node.js 25.9.0
- pnpm 11.5.2
- Git
- Optional: Docker for container-focused development and security scanning
git clone https://github.com/SinLess-Games/Aerealith.git
cd Aerealith
pnpm install --frozen-lockfilepnpm exec nx run-many -t lint typecheck test buildpnpm exec nx graphpnpm exec nx lint <project-name>
pnpm exec nx typecheck <project-name>
pnpm exec nx test <project-name>
pnpm exec nx build <project-name>Every meaningful change should begin with a tracked Issue whenever practical.
Issues are used to capture:
- Scope
- Acceptance criteria
- Priority
- Risk
- Milestone
- Area ownership
- Agent eligibility
- Validation expectations
git checkout -b feature/123-short-descriptionKeep changes focused.
Avoid unrelated refactors, dependency churn, generated-file edits, or broad formatting changes unless they are part of the issue.
pnpm exec nx run-many -t lint typecheck test buildUse a Conventional Commit-style title:
feat(frontend): add account settings page
fix(auth): reject expired refresh tokens
refactor(core): simplify error serialization
docs(devportal): document API authentication
ci(repo): add security validation workflow
Use the appropriate Pull Request template and link the related Issue when required.
Aerealith treats security as a product feature, not an afterthought.
The repository security program is designed to include:
- CodeQL language coverage
- SonarQube Cloud quality gates
- Semgrep static analysis
- DevSkim secure-coding checks
- njsscan JavaScript and TypeScript analysis
- Snyk dependency and code analysis
- Trivy filesystem, secret, misconfiguration, and container scanning
- Dockerfile and Compose configuration review
- Dependency automation with human approval gates
- Controlled security remediation workflows
- Human review for sensitive changes
High-risk changes are never automatically merged.
Examples of work that always requires human review:
Authentication and authorization changes
Session, token, credential, and consent handling
Database migrations and schema changes
Dependency and lockfile changes
Dockerfiles, container images, and Compose files
Cloudflare, infrastructure, CI, and GitHub Actions changes
Security-sensitive findings
Breaking API or contract changes
Please do not post exploit details, credentials, sensitive logs, or proof-of-concept attack steps in a public Issue.
Use the repository’s Security tab and private vulnerability-reporting flow when available.
Aerealith uses layered validation to keep changes reliable:
| Gate | Purpose |
|---|---|
| Lint | Enforces code quality, consistency, and maintainable patterns. |
| Typecheck | Verifies strict TypeScript correctness. |
| Test | Validates expected behavior and prevents regressions. |
| Build | Confirms projects can compile and package successfully. |
| SonarQube Cloud | Tracks code quality, reliability, maintainability, and quality gates. |
| Security Scanning | Detects dependency, secret, code, infrastructure, and container risks. |
| Human Review | Protects high-impact changes and verifies automation decisions. |
Repository security behavior is defined through policy files under:
.github/config/
Important policy files include:
security.yaml
routing.yaml
workers.yaml
reviewers.yaml
dependency-policy.yaml
labels.yaml
milestones.yaml
project.yaml
These files define:
- Which scanners can run
- Required security thresholds
- Issue and Pull Request routing
- Human-only work boundaries
- Coding-agent eligibility
- Dependency update policy
- Reviewer policy
- Milestone routing
- Project automation behavior
- Nx monorepo foundation
- Shared library boundaries
- TypeScript-first architecture
- Repository automation policy
- Security scanning policy
- Complete baseline CI validation
- Complete GitHub Project automation
- Sign-up and login flows
- Refresh-token lifecycle
- Email verification
- User profiles
- Preferences and settings
- Consent management
- Secure account recovery flows
- Shared API standards
- Typed service contracts
- Database persistence and migrations
- Observability and structured logging
- Feature flags
- Edge-service support
- Public website
- Authenticated web application
- Documentation experience
- Developer portal
- Shared component system
- Accessibility baseline
- Modular Discord bot architecture
- Per-server module settings
- Moderation tooling
- Role and automation support
- Ticket workflows
- Audit and transcript controls
- Dashboard integration
- CodeQL workflow coverage
- SonarQube Cloud integration
- Semgrep and Trivy reporting
- Snyk dependency reporting
- Container-image scanning
- Controlled remediation workflows
- Observability dashboards
- Deployment automation
Contributions should be intentional, focused, and easy to review.
Before opening a Pull Request:
- Read the relevant repository instructions.
- Keep the change scoped to the Issue.
- Add or update tests where practical.
- Run relevant lint, typecheck, test, and build commands.
- Update documentation when behavior changes.
- Avoid adding secrets, credentials, or private data.
- Include screenshots or recordings for user-interface changes.
- Link the related Issue when required.
- Follow the configured Conventional Commit title format.
| Resource | Location |
|---|---|
| Issue Templates | .github/ISSUE_TEMPLATE |
| Pull Request Templates | .github/PULL_REQUEST_TEMPLATE |
| Repository Automation Config | .github/config |
| Agent Instructions | .github/instructions |
| GitHub Actions | .github/workflows |
| Security Policy Config | .github/config/security.yaml |
| Dependency Policy | .github/config/dependency-policy.yaml |
| GitHub Project | Aerealith Delivery |
Built by SinLess Games.
Aerealith is being built carefully: secure by default, modular by design, and focused on foundations that last.