wacrm/docs/deployment-alternatives.md
Arnas Donauskas 7cd0f46369
docs: README polish + architecture + alt hosts
Finishes the template-readiness sequence. All docs — nothing runtime.

README.md
  Rewrites the landing page of the repo to actually sell what it is
  to someone finding the repo cold on GitHub search.
  - Shields.io badges: MIT, CI status, Next.js 16, Supabase, GitHub
    stars.
  - "What you get out of the box" bullet list — inbox, contacts,
    pipelines, broadcasts, automations, dashboard, account
    management — so the feature surface is visible before the reader
    scrolls.
  - "Why fork this?" section: full ownership, full customisation,
    zero ops to start, real security primitives. Frames WaCRM as a
    template, not an SDK.
  - Docs section reorganised into Setup / Deploy / Reference to
    match the in-app /docs viewer and docs/README.md.
  - Contributing section rewrites the stale "Pull requests welcome"
    line to match the fork-first framing from PR #73.

docs/architecture.md  (new)
  One-page tour for forkers: stack table, full folder layout,
  two ASCII request-lifecycle diagrams (inbound webhook + outbound
  send), security primitives rundown, and a "where to change things"
  index that maps common customisation tasks to source files. This
  is the thing I wish I'd had the first time I opened a forked
  template.

docs/deployment-alternatives.md  (new)
  Short blocks for Vercel, Railway, raw VPS, and Docker. Each covers
  env-var setup, cron strategy (Vercel cron without custom headers
  is a footgun worth calling out), and trade-offs. Keeps Hostinger
  as the primary recommendation — this page is for people whose
  constraints rule it out.

docs/README.md
  - Reading order grouped as Setup / Deploy / Reference, adding the
    two new pages.
  - Stack-at-a-glance updated: encryption is AES-256-GCM, not CBC
    (the PR #71 change that earlier docs hadn't caught up to).

src/lib/docs/content.ts
  Registers the two new markdown files in the ORDER map so they
  appear in the in-app /docs sidebar under the Reference section,
  with prev/next pagination wiring.

Verified: /docs, /docs/architecture, /docs/deployment-alternatives,
and /docs/getting-started all return 200 from the dev server.
Sidebar shows 9 pages grouped Setup / Deploy / Reference with the
new entries. Typecheck clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-20 21:43:42 +03:00

4.8 KiB

Alternative hosts

Hostinger Managed Node.js Hosting is the recommended default — zero-ops, Git deploy from hPanel, AutoSSL. But WaCRM is a plain Next.js app; any host that runs long-running Node.js 20+ will work. This page is a quick sketch for the common alternatives. Each block assumes you've already completed Supabase setup and WhatsApp setup.

Vercel

  1. Push your fork to GitHub.
  2. https://vercel.com/new → Import Git Repository → pick the fork.
  3. Environment Variables: paste every value from environment-variables.md. Mark the NEXT_PUBLIC_* ones as available at build time (Vercel does this automatically).
  4. Deploy. Vercel handles HTTPS, preview URLs, and edge routing.
  5. Attach your domain (Vercel → Project → Settings → Domains).
  6. Update Meta → WhatsApp → Configuration → Webhook to https://<your-domain>/api/whatsapp/webhook.

Automations cron: Vercel has built-in cron (Pro plan). Add to vercel.json:

{
  "crons": [
    { "path": "/api/automations/cron", "schedule": "* * * * *" }
  ]
}

Vercel cron hits the endpoint server-to-server but doesn't let you send custom headers. The simplest path is to skip x-cron-secret and gate on Vercel's x-vercel-cron header instead:

// adjust src/app/api/automations/cron/route.ts
if (request.headers.get('x-vercel-cron') !== '1' &&
    request.headers.get('x-cron-secret') !== process.env.AUTOMATION_CRON_SECRET) {
  return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
}

Trade-offs:

  • ✅ Fastest onboarding, preview URLs per PR, global CDN.
  • ⚠️ Serverless functions have cold starts — inbound webhooks from Meta may occasionally take an extra second on the first hit.
  • ⚠️ The in-memory rate limiter is per-function-instance, so effective limits multiply across regions. Swap for Upstash Redis if that matters.

Railway

  1. https://railway.app/new → Deploy from GitHub repo → pick your fork.
  2. Railway detects Next.js automatically. Default build + start commands are correct.
  3. Variables: add every value from environment-variables.md.
  4. Generate Domain under Settings, or attach a custom domain.
  5. Update Meta webhook URL, same as above.

Automations cron: Railway has built-in cron. Services → + Cron:

  • Schedule: * * * * *
  • Command:
    curl -s -H "x-cron-secret: $AUTOMATION_CRON_SECRET" https://<your-domain>/api/automations/cron
    

Trade-offs:

  • ✅ Long-running processes (no cold starts), built-in Redis if you need one, usage-based pricing.
  • ⚠️ No preview deploys per PR out of the box (paid feature).

Raw VPS (any provider)

Any Ubuntu 22/24 or Debian 12 VPS with 2 GB+ RAM works. The Hostinger VPS walkthrough in deployment-hostinger.md (at the bottom, "When to reach for a VPS instead") gives the exact commands — PM2 + nginx + certbot. Same commands apply on DigitalOcean, Hetzner, Linode, AWS Lightsail, OVH, etc. Only the billing dashboard changes.

Systemd cron is the obvious scheduler:

* * * * * curl -s -H "x-cron-secret: $AUTOMATION_CRON_SECRET" https://<your-domain>/api/automations/cron > /dev/null

Trade-offs:

  • ✅ Most control (custom binaries, private networking, your own observability stack), cheapest at scale.
  • ⚠️ You are the ops team. Patching, TLS renewal, log rotation, backup to S3 — all you.

Self-hosted Docker / Kubernetes

No official image is shipped. If you containerise, the app is a plain Next.js standalone build:

FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

FROM node:20-alpine AS build
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/.next ./.next
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/package.json ./
COPY --from=build /app/public ./public
EXPOSE 3000
CMD ["npm", "start"]

Pass env vars via --env-file or a Kubernetes Secret. The cron ping stays an external concern (K8s CronJob, a sidecar, or an external uptime monitor).

Which should I pick?

If you want… Pick
Zero-ops, lowest-friction deploy Hostinger Managed Node.js
Preview URLs per PR, global edge Vercel
Long-running processes, simple cron Railway
Full control, cheapest at scale, you're OK on ops VPS / self-host
Air-gapped or multi-region with your own K8s Docker / Kubernetes

None of these are one-way doors — they all run the same fork of the same Next.js app.