@helyx/platform

Database-backed Helyx platform services for configuration, permissions, installations, sessions, audit events, rate limits, subscriptions, durable scheduled work and module records.

Requirements

• Node.js 24–26
• npm 11 or newer
• PostgreSQL 17 for production deployments

Applications create these services from an owned PostgreSQL pool and expose only the bounded interfaces declared by @helyx/sdk to feature modules.

Scheduled-task metadata, leases and coalesced delivery lanes remain inside the core database boundary. Modules can schedule, cancel or signal only their own declared task kinds and receive no repository, lease or worker-topology access.

Record quota guards use canonical, deterministically ordered PostgreSQL transaction advisory locks so concurrent parent creation cannot pass the same shared cap. Guarded high-volume relationship writes may use the reviewed 100,000-row ceiling without a parent insertion. Required-row locks, module-enabled fencing and database-time predicates serialize entry, Privacy, disablement and lifecycle races. Result transactions remain bounded to 20 child rows.

Required module audits, one-shot scheduling and allowlisted retention descriptors can share the record transaction that establishes the related domain state. The core retention lane performs only prevalidated, guild-scoped, bounded deletes and does not execute removed module code.

The platform secure-random service uses operating-system entropy, unbiased bounded-integer rejection sampling and versioned weighted reservoir selection without replacement. Weighted operations use a random opaque operation reference and a configured server-held 32-byte key. Domain-separated HMAC derivation produces independent scoring and checkpoint-integrity keys, so the reference alone cannot predict outcomes or forge state. Deterministic framed scoring and tie-breaking then allow the same reservoir to resume safely across bounded scheduled-task pages. A serialisable checkpoint contains only validated operation metadata, the canonical cursor, counts and totals, a hash-chain audit digest and at most the requested 20 candidate IDs and weights. It never contains raw entropy, raw scores or server keys. The service enforces a maximum 100,000-candidate stream, never expands weights into tickets and returns audit-safe references/digests. The server key must not rotate while a checkpointed selection remains in progress.

Publication status

Published on npm under HSAL 1.0.