Folder Structure

HedHog projects are organized as a Turbo monorepo. The generated project starts with a small base, and you expand it by adding libraries and shared packages over time.

The default scaffold created by HedHog includes only:

apps/
  admin/
  api/
libraries/
packages/

This development repository contains additional apps such as hedhog, class, partners, and training, but those are part of the framework workspace itself and should not be interpreted as the minimal structure generated for a new project.

apps/
  admin/
  api/
  ...optional apps in the framework workspace
libraries/
  core/
  your-domain-library/
packages/
  api/
  api-prisma/
  ui/
docs/
scripts/

The apps folder contains runnable applications.

• apps/admin: the Next.js admin panel used to manage data, users, permissions, settings, and custom business flows.
• apps/api: the NestJS entrypoint that loads the business modules defined in libraries/*.
• Other apps may exist in the HedHog development repository, but they are optional examples or internal framework apps, not part of the base project scaffold.

Use apps/* for composition and runtime bootstrapping, not for core business rules.

The libraries folder is the heart of a HedHog project.

Each library represents a business capability or domain, for example core, finance, crm, lms, or a custom module created for your project.

This is where business logic must live:

• NestJS modules, controllers, services, and DTOs
• Domain-specific permissions and route seeds
• HedHog YAML files for tables and seed data
• Dashboard or admin integration owned by that domain

In practice, apps/api imports libraries, but the rules and use cases belong inside libraries/*.

The packages folder contains reusable technical building blocks shared across apps and libraries.

Common examples from this repository include:

• packages/api: shared backend helpers
• packages/api-prisma: Prisma access and integration helpers
• packages/api-pagination: shared pagination behavior
• packages/next-app-provider: frontend app providers and shared client integration
• packages/ui: reusable UI primitives and components

Use packages/* for cross-cutting infrastructure or reusable abstractions that are not tied to a single business domain.

• docs/: documentation sources, schemas, and reference material used by the framework.
• scripts/: repository automation for setup, code generation, schema updates, and maintenance tasks.
• apps/api/prisma/: Prisma migrations and database integration assets for the API app.
• storage/: local runtime storage used by parts of the workspace.

These folders support the monorepo, but they are not where you should place domain behavior.

• Put business logic in libraries/*.
• Put application entrypoints and bootstrapping in apps/*.
• Put shared technical code in packages/*.
• Avoid moving domain rules into apps/admin or apps/api just because those apps consume the feature.

If you add a new billing feature:

• Create or extend a library such as libraries/finance.
• Implement controllers, services, DTOs, YAML, and permissions in that library.
• Expose the module through apps/api.
• Build the admin screens in apps/admin by consuming the API.
• Extract reusable helpers or UI primitives to packages/* only when they are truly shared.

This separation keeps the monorepo scalable as the number of modules grows.