ImpulseCore

Required for every module

The shared addon every Impulse module depends on for project membership, hook dispatch, the cron runner, the audit log, and the Security & Maintenance pipeline. Install once; every module reads from the same surface.

1. What ImpulseCore is

ImpulseCore (slug impulsecore) is a WHMCS addon that owns the cross-cutting concerns shared by every Impulse module — ImpulseObjects, ImpulseDB Postgres, ImpulseAuth (GoTrue), ImpulsePlesk, ImpulseCpanel, ImpulseVPS, ImpulseValkey (Valkey), ImpulseSecrets, ImpulseSearch (Meilisearch / Typesense), and ImpulseNotify. Modules register with Core via a JSON manifest at install time and call into a static ImpulseCore::* facade for everything cross-cutting.

Projects & service membership

Group multiple WHMCS services (a Postgres DB + an object-storage bucket + a search instance) into a single customer-facing project. Modules read project membership through Core to render “related services” UI.

Cron runner

A single Core cron entry replaces per-module crontabs. Modules register named cron tasks; Core’s runner dispatches them and logs every run so missed crons surface in diagnostics.

Hook dispatcher

Cross-module hooks (service suspended in module A → do something in module B) flow through Core’s hook subscription registry. Modules subscribe by event name; Core fans each event out to every subscriber and audits handler failures.

Audit log

Every state-changing action across every module writes to a single mod_impulsecore_audit_log. One pane to search and filter by level, module and event. 90-day retention.

Security & Maintenance

CVE feeds (Ubuntu USN + CISA KEV + NVD), critical-CVE auto-scheduling, snapshot-protected patching, customer maintenance windows.

Licensing client

Shared XML licensing client. You paste each module’s key once in Core; caching, grace periods, and domain detection are uniform across modules.

Core also carries the shared service lifecycle (suspension and termination grace windows), an Email Center for the modules’ customer emails, monitoring and alert destinations, and one place for VPS provider credentials that modules creating servers can share.

2. How modules register with Core

Every Impulse module ships a small JSON manifest, impulse_module.json, that Core reads on activation. An excerpt:

{
  "slug": "impulsepostgres",
  "display_name": "Managed PostgreSQL",
  "version": "1.10.5",
  "core_min_version": "1.61.13",
  "service_type": "database",
  "cron_tasks": [
    {"name": "provision", "cadence": "2min"},
    {"name": "usage",     "cadence": "hourly"}
  ],
  "security": {
    "collector": "ImpulsePostgres\\Security\\Collector",
    "actuator":  "ImpulsePostgres\\Security\\Actuator"
  },
  "cve_products": ["cpe:2.3:a:postgresql:postgresql"]
}

When a module is activated, Core reads its manifest, records it in mod_impulsecore_modules, installs its hook handlers and cron tasks, and records its lifecycle handler; Security classes are found in the module’s lib/Security/ directory. Modules go through the ImpulseCore::* facade for all cross-cutting writes — never touch mod_impulsecore_* directly. Details: Module manifest & registration.

3. The tables Core owns

Table	Purpose
mod_impulsecore_modules	Installed module registry (manifest cache).
mod_impulsecore_projects	Project records (client groupings of services).
mod_impulsecore_project_services	Service-to-project membership.
mod_impulsecore_licenses	License verification cache and grace state (XML licensing client).
mod_impulsecore_hook_subscriptions	Registered hook handlers per module.
mod_impulsecore_cron_tasks	Registered cron tasks per module + last/next run timestamps.
mod_impulsecore_cron_log	Cron run history (status, duration, context).
mod_impulsecore_audit_log	Cross-module audit trail.
mod_impulsecore_secrets	Encrypted secret storage for env contributor reveal.
mod_impulsecore_service_lifecycle	Services in a suspension or termination grace window.
Security & Maintenance
mod_impulsecore_security_snapshots	Per-service security snapshot (pending updates, kernel, service version, defensive posture).
mod_impulsecore_server_snapshots	Per-server snapshot for shared/managed infrastructure.
mod_impulsecore_security_events	Append-only patch / reboot / CVE / snapshot / deferral event log.
mod_impulsecore_maintenance_windows	Per-service customer-configured window.
mod_impulsecore_maintenance_schedules	Future maintenance rows.
mod_impulsecore_cve_feed	Upstream advisory cache (USN + KEV + NVD).
mod_impulsecore_patch_snapshot_holds	Pre-patch snapshots held after a failed patch, awaiting your decision.

Core also keeps tables for projects and regions, monitoring and alerting, the Email Center, VPS provider credentials, and its own settings — all prefixed mod_impulsecore_.

4. Hard dependency, not optional

ImpulseCore is a hard dependency for every Impulse module. Modules without Core registration don’t ship. The relationship is one-way: modules register with Core; Core never reaches into module tables.

Install Core first

If you activate a module before Core is installed and active, the module either stops with a message telling you to install Core, or activates without registering with Core and doesn’t work. Install and activate impulsecore first, then the module.

5. Versioning & the contract

Core publishes its public surface (the ImpulseCore::* facade + the manifest contract + the table schemas) as a single integration contract, and Core’s own version moves with that contract. Every consuming module pins the minimum Core version it needs in its manifest’s core_min_version field — each module’s install guide names it. When the surface evolves, the version bumps (semver) and modules raise their minimum when they start using something new.

If a module needs a newer Core than you have, Core won’t make it active (“Module ‘…’ requires ImpulseCore >= X, but installed Core is Y” — shown when you activate the module), and Modules & Licensing → Modules lists any module release waiting for a newer Core. Update Core first, then the modules.

6. Where to go next

This page is a high-level overview. For the full guide series — install steps, manifest contract details, the cron runner, the audit log, the Security & Maintenance pipeline, and troubleshooting — see the dedicated ImpulseCore docs:

• Installation & activation — install Core first, before any module.
• Module manifest & registration — how modules register with Core.
• Cron runner — the single Core cron that dispatches every task.
• Audit log — one searchable surface across every module.
• Security & Maintenance pipeline — CVE feeds, scheduled patching, customer maintenance windows.
• Troubleshooting — common Core issues.