Skip to content

Akshaya Project Registry

This portal is hosted from the AkshayaBazaar repository, but it also records the operational boundary between the active Akshaya projects so deployment ownership is not confused.

Project Repository / location Runtime model Primary deployment path Notes
AkshayaBazaar Thirunk/AkshayaBazaar React/Vite + .NET 8 + MySQL + Redis Docker locally; K3s/Helm for shared environments; Terraform for Hetzner + Cloudflare This repository owns this MkDocs portal.
Akshaya Group Global Thirunk/akshaya-group-global React/TypeScript/Vite apps + Cloudflare Workers API + D1 + R2 GitHub Actions to Cloudflare Workers/Static Assets Corporate, software, logistics, commerce, embroidery, admin, and API surfaces. Investors source is inactive and not deployed.
Akshaya Logistics surface apps/logistics-* / logistics application inside Akshaya Group Global Cloudflare-first web application Same production workflow as Akshaya Group Global Keep its operational runbooks with the monorepo unless a dedicated repository is created later.

Ownership rule

A runbook may describe another Akshaya project, but commands must be executed from the repository that owns the deployment. Do not copy Terraform, Wrangler, Kubernetes, or GitHub Actions commands between projects unless the target repository contains the corresponding configuration.

Repository-specific source of truth

For AkshayaBazaar use this portal and the repository files under:

terraform/
helm/
.github/workflows/
scripts/
environments/
docker-compose*.yml

For Akshaya Group Global use that repository's own:

.github/workflows/ci.yml
.github/workflows/deploy-cloudflare.yml
docs/DEPLOYMENT.md
wrangler configuration
D1 migrations

Its production main workflow validates first, then applies D1 migrations, deploys the API Worker, deploys the six active web applications, and finally runs production smoke tests. The manual Cloudflare workflow is the recovery/one-off path.

Change-control rule

  1. Identify the owning repository.
  2. Create a feature/docs branch from its default branch.
  3. Run that repository's required validation.
  4. Open a PR and wait for required checks.
  5. Merge only after validation.
  6. Treat production deployment as a separate operational decision unless that repository intentionally auto-deploys its default branch.