HoneyNotify Docs

HoneyNotify - implementation plan

Repository status

The production release covers the control plane, versioned API, strict payload validation, priority queue contract, acknowledged worker delivery, atomic retry promotion, recipient claim locking, retries/DLQ, dashboard workflow, team invitations and role management, iOS and Android SDK clients, usage metering, owner TOTP MFA, cancellable privacy workflows, legal documents, encrypted backups, restore verification, Stripe integration and scale-out configuration described below. The current production worker processes are co-located on the cPanel host under Supervisor with separate Redis and database identities; moving them to a dedicated Ubuntu push-01 remains an infrastructure scaling step. Live APNs, FCM and Stripe acceptance tests require operator-owned provider credentials. Cloudflare onboarding requires access to that vendor account; see DEPLOYMENT.md and OPERATIONS.md.

Phase 0 - foundations

  1. Choose product name/domain.
  2. Create Git repositories or a monorepo for webapp, worker, SDKs and docs.
  3. Provision push-01 with Ubuntu 24.04.
  4. Create WireGuard tunnel between WHM and push-01.
  5. Put web/API behind Cloudflare; keep database and Redis private.
  6. Establish dev, staging and production environment variables and secrets.

Phase 1 - control plane on WHM

Build the customer-facing SaaS application in PHP 8.3. The control plane owns identity and persistent business data:

Initial UI pages:

Do not allow provider private keys to be redisplayed after upload. Allow replacement/revocation instead.

Phase 2 - public developer API

Implement versioned JSON endpoints under /v1:

Requirements:

Phase 3 - queue contract

The web server must not send APNs/FCM requests itself. It creates a notification row and publishes an expand_notification job.

Job contract:

{"type":"expand_notification","notification_id":123}

The worker resolves the target and splits it into fixed-size batches. Each batch becomes:

{"type":"deliver_batch","notification_id":123,"batch_id":456,"device_ids":[1,2,3]}

Use separate priority queues:

Never let a huge marketing blast share all capacity with transactional sends.

Phase 4 - worker node

push-01 owns transient processing infrastructure:

Worker rules:

Phase 5 - dashboard MVP

Build the customer workflow:

  1. Sign up.
  2. Create organisation.
  3. Create application.
  4. Configure iOS/Android credentials.
  5. Generate API key.
  6. Follow SDK/API setup instructions.
  7. Device appears in Audience.
  8. Send test notification.
  9. Create broadcast.
  10. View accepted/failed counts.

This workflow is the real MVP milestone.

Phase 6 - SDKs

Start with thin SDKs rather than recreating every OneSignal feature.

iOS

Android

Do not embed a server/REST API secret in apps. Issue a separate public app identifier/client key with limited device-registration permissions before shipping SDKs publicly.

Phase 7 - reliability hardening before paying customers

The queue, retry, idempotency, request-rate, audit and production recovery foundations are included:

Phase 8 - billing

Record usage independently from Stripe:

Create a usage_daily aggregate table rather than calculating monthly bills by scanning every delivery row.

Stripe handles plan/subscription/payment state; your own database remains authoritative for measured usage.

Phase 9 - scale-out

When push-01 becomes constrained:

  1. Add push-02 with the same worker code and .env.
  2. Point it at the same private DB and Redis service.
  3. Start worker services.
  4. It immediately shares queue load.

Next separation should be Redis/message broker from workers:

Later add DB replication/dedicated DB and ClickHouse/event pipeline when analytics volume justifies it.

Suggested v1 release gates

Alpha

Private beta

Paid v1