Re-applies PR #182's next-intl scaffold with defensive measures aimed at the most-likely-but-unconfirmed causes of the 503 that hit prod after that PR merged. PR #183 reverted #182 to restore service; this branch carries the same i18n payload plus the safeguards below. Defensive changes vs PR #182: 1. **`outputFileTracingRoot: __dirname`** in next.config.ts. Builds were warning that Next.js inferred the workspace root as the parent GHWebhosting directory (because of a stray lockfile there). With the wrong root, file tracing for the production artifact can include the wrong files or skip ours. Pinning the root to the wacrm directory silences the warning and makes tracing deterministic across local / CI / Hostinger. 2. **`outputFileTracingIncludes: { "/**/*": ["./messages/**/*.json"] }`**. Belt-and-suspenders: explicitly force the i18n message dictionaries into the production artifact even if static-import tracing somehow misses them in Hostinger's build environment. 3. **Static locale import map in `src/i18n/request.ts`**. Replaces `import(\`../../messages/\${locale}.json\`)` with an explicit `{ en: () => import(...), es: ..., lt: ... }` map. Template-literal dynamic imports are well-supported by Turbopack's tracer but the static form leaves zero room for the tracer to skip a locale. 4. **Try/catch around the intl middleware call**. If `intlMiddleware(request)` ever throws at runtime, fall through to auth-only handling and log the error rather than 503-ing every page request behind a single bad call. 5. **Try/catch around `LOADERS[locale]()`** with English fallback. Same idea: a missing locale bundle at runtime returns English content instead of crashing the render path. 6. **`engines.node: ">=20.10.0"`** (was `>=20.0.0`). Next 16.2's actual minimum. Tells Hostinger's Node.js app picker not to land us on a too-old subversion. Verified locally: - npm run lint → 0 errors (same 18 pre-existing warnings) - npm run typecheck → clean - npm run test → 366 passing - npm run build → 62 prerendered pages across en/es/lt; workspace root warning gone; messages bundled into `.next/server/chunks/ssr/ messages_{en,es,lt}_json_[json]_cjs_*.js` - npm start probes: / → 307 → /en /en/login → 200 /es/login → 200 /lt/login → 200 /en/dashboard → 307 → /en/login (signed out) /api/whatsapp/templates → 401 If 503 reappears in prod after this lands, the local repro is clean, so the next step is hPanel build/runtime logs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .github | ||
| messages | ||
| public | ||
| src | ||
| supabase/migrations | ||
| .editorconfig | ||
| .env.local.example | ||
| .gitignore | ||
| .prettierignore | ||
| .prettierrc | ||
| AGENTS.md | ||
| CHANGELOG.md | ||
| CLAUDE.md | ||
| components.json | ||
| CONTRIBUTING.md | ||
| eslint.config.mjs | ||
| LICENSE | ||
| next.config.ts | ||
| package-lock.json | ||
| package.json | ||
| postcss.config.mjs | ||
| README.md | ||
| tsconfig.json | ||
| vitest.config.ts | ||
wacrm — CRM Template for WhatsApp
Self-hostable CRM template for WhatsApp® — shared inbox, contacts, sales pipelines, broadcasts, and no-code automations. Fork it, brand it, host it.
The marketing site and self-host docs live in a separate repo: ArnasDon/wacrm-site (wacrm.tech). This repo is the product — clone or fork it to run your own CRM.
What you get out of the box
- Shared inbox on the official WhatsApp Business API — multiple agents working one number, per-conversation assignment, status, and notes.
- Contacts + tags + custom fields, CSV import, deduplication.
- Sales pipelines (Kanban) with deals linked to conversations.
- Broadcasts with Meta-approved templates, delivery + read tracking, per-recipient variable substitution.
- No-code automations — triggers on inbound messages, new contacts, keywords, or schedule; conditional branches, waits, tags, webhooks. Visual builder.
- Real-time dashboard — response times, daily volume, pipeline value, cross-module activity feed.
- Account management — email, password, avatar, global sign-out.
Why fork this?
This is a template, not a product. Forking means you get:
- Full ownership — your code, your Supabase project, your domain, your data. No SaaS lock-in, no seat pricing, no trust dance.
- Full customisation — add the fields your team needs, remove the modules you don't, redesign anything. The stack is boring on purpose (Next.js + Supabase + Tailwind) so the learning curve is short.
- Zero ops to start — Hostinger Managed Node.js deploys a fork in a few clicks. No Docker, no Kubernetes, no infra team needed.
- Real security primitives — token encryption (AES-256-GCM), RLS on every table, HMAC-verified webhooks, CSP, rate limiting, CI typecheck/build on every PR.
Not a framework. Not an SDK. A concrete, working CRM you can stand up in an afternoon and make yours.
Quick start
# Fork on GitHub first: https://github.com/ArnasDon/wacrm → Fork
git clone https://github.com/<your-username>/wacrm.git
cd wacrm
npm install
cp .env.local.example .env.local # fill in Supabase + Meta creds
npm run dev
Open http://localhost:3000. You'll be redirected to /login (or
/dashboard if already signed in).
Documentation
Full self-host documentation — Supabase migrations, WhatsApp Business API config, and production deploy — lives at wacrm.tech/docs (source: ArnasDon/wacrm-site).
Key pages:
- Getting started
- Supabase setup
- WhatsApp setup
- Environment variables
- Deploy on Hostinger
- Architecture
- Troubleshooting
Stack
- App — Next.js 16 (App Router), React 19, TypeScript, Tailwind v4.
- Data — Supabase (Postgres + Auth + Storage + RLS).
- WhatsApp — Meta Cloud API (official WhatsApp Business API).
Contributing
This is a template, not a collaborative product — the expected flow is
fork → customise → deploy, not upstream contribution. Bug reports
and security issues are welcome; feature PRs often belong in your fork
rather than here. Details in
CONTRIBUTING.md and
.github/SECURITY.md.
License
MIT. Fork it, brand it, host it.