Workers¶

Purpose¶

Every Worker in this repository, its bindings, and what run_worker_first actually changes.

The 8 Workers¶

Worker name	Source	Bindings	`run_worker_first`
`akshaya-group-global-api`	`workers/api/`	`DB`, `FILES`, `NOTIFY_EMAIL`	n/a - dedicated Worker, no static assets
`akshaya-group-global`	`apps/corporate-web/`	`DB`, `FILES`	`["/customer-portal", "/api/customer/"]`
`akshaya-software`	`apps/software-web/`	`DB`, `FILES`	`["/freelancer-portal", "/api/freelancer/"]`
`akshaya-admin`	`apps/admin-web/`	`DB`, `FILES`	`true` (every path)
`akshaya-logistics`	`apps/logistics-web/`	none	not set (pure static)
`akshaya-commerce`	`apps/commerce-web/`	none	not set
`akshaya-embroidery`	`apps/embroidery-web/`	none	not set
`akshaya-investors`	`apps/investors-web/`	none	not set

What `run_worker_first` actually does¶

By default, a Worker with Static Assets serves a matching file from assets.directory without ever invoking your Worker code - faster, and the common case for a plain SPA. run_worker_first is an allowlist of path patterns (or true for everything) that skip the static-asset shortcut and always run the Worker's own fetch handler first, which then decides whether to serve an API response, do its own routing, or fall through to a static file. This is what makes corporate-web/software-web's portal auth routes and admin-web's entire app work as server-rendered/API logic rather than static files.

Configuration (`vars`, API Worker only)¶

"vars": {
  "APP_ENV": "production",
  "ALLOWED_ORIGINS": "https://software.akshayagroupglobal.com,https://logistics.akshayagroupglobal.com,https://commerce.akshayagroupglobal.com,https://embroidery.akshayagroupglobal.com,https://akshayagroupglobal.com",
  "NOTIFICATION_EMAIL": "<NOTIFICATION_EMAIL>"
}

ALLOWED_ORIGINS is parsed into a Set and checked against the incoming request's Origin header - the API's own CORS allowlist (see Cloudflare → Troubleshooting "CORS" for what happens when an origin isn't in this list). Note: investors.akshayagroupglobal.com is not in this list - confirmed, not just consistent with, Investors being outside the automatic deploy/smoke-test pipeline (see Architecture → Applications): Investors is currently excluded / inactive by explicit platform-scope decision, and apps/investors-web makes no calls to this API today, so ALLOWED_ORIGINS intentionally omits it. admin.akshayagroupglobal.com is also absent, for a different reason - Admin never calls this Worker at all, it has its own separate Worker/D1 access (see Applications → Admin).

Email (`send_email` binding, API Worker only)¶

"send_email": [{
  "name": "NOTIFY_EMAIL",
  "destination_address": "<NOTIFICATION_EMAIL>",
  "allowed_sender_addresses": [
    "software@akshayagroupglobal.com", "logistics@akshayagroupglobal.com",
    "commerce@akshayagroupglobal.com", "embroidery@akshayagroupglobal.com",
    "support@akshayagroupglobal.com", "freelancers@akshayagroupglobal.com"
  ]
}]

Cloudflare Email Workers - every notification email the API sends goes to one fixed destination address, from one of the allowlisted sender addresses only.

Observability¶

"observability": { "enabled": true, "head_sampling_rate": 1 } on the API Worker - 100%-sampled Cloudflare Workers Logs, no third-party APM. See Operations → Logs.

Compatibility¶

Every Worker in this repo: "compatibility_date": "2026-08-16", "compatibility_flags": ["nodejs_compat"] (Node.js API compatibility shim, needed for parts of the API Worker's code).

Local development¶

npm run dev:api                       # workers/api, via wrangler dev
cd apps/corporate-web && npx wrangler dev   # exercises run_worker_first routes locally

Deployment (MUTATING, production)¶

npm run deploy:api
npm run deploy:corporate     # etc. - see Applications pages for the full per-app command

Troubleshooting¶

See Troubleshooting.

Security considerations¶

No Worker secret value is ever committed - confirmed by repository-wide scan (see Infrastructure → Security).
ALLOWED_ORIGINS is the API's only CORS boundary - there is no additional auth-based origin check beyond it for unauthenticated endpoints.
ADMIN_BOOTSTRAP_TOKEN gates the only way to create the first Admin account - treat it with the same care as a root credential.