Why this layer
Built into the platform, not bolted on
Every module in this layer solves the same class of problem the same way — regardless of who implements it.
01
No separate job infrastructure
Background processing, serverless handlers, and cron jobs run on Conflux runtime — not a separate Redis cluster, Lambda account, and cron server you operate.
02
Events and data share one auth model
Functions and workers access tenant data through the same SDK and authorization policies as your application code. No service account sprawl.
03
Realtime without WebSocket plumbing
Live subscriptions and presence channels are platform-managed. Subscribe to data changes with one API — not a custom socket server per feature.
Canonical implementation
One path for every author
Junior developers, senior engineers, and AI agents produce the same standard output.
How Conflux does it
Runtime modules share observability and tenancy
Every job, function, and schedule is registered in the platform. Retries, dead letters, execution history, and failure alerts are defaults — not per-team additions.
Canonical path
conflux.jobs.list() / retry / cancel for platform job queues
Functions deploy via conflux push with handler bundles
Cron schedules in conflux.config.ts with execution history
Realtime subscriptions align to schema types and auth policies
What you get
Process background work without operating queue infrastructure
Add live UI updates without custom WebSocket servers
Schedule business operations with built-in monitoring
Debug runtime issues from one observability surface
01 · Runtime Layer
Live data without WebSocket plumbing
Subscribe to data changes, presence, and channel messaging through platform-managed connections. Realtime respects the same auth policies as your API.
Realtime · One canonical path
SDK
await conflux.realtime.connect(); conflux.realtime.subscribe('orders', handler)CLI
# Console Realtime page + SDK realtime.connect
Config
# channels are app-defined at subscribe time
What's possible with Realtime
01
Live subscriptions to data changes
02
Presence and channel-based messaging
03
WebSocket connections managed by the platform
02 · Runtime Layer
Background jobs with retries built in
Platform job queues with list/retry/cancel/purge. Workers process sync, webhooks, cron, and retention — enqueue is platform-internal, not a public SDK verb.
Queue · One canonical path
SDK
await conflux.jobs.list({ status: 'failed' })CLI
conflux doctor # queue depth hints; Console Queues for retry/cancel
Config
# jobs are enqueued by platform (webhooks, cron, prune)
What's possible with Queue
01
Background job processing with retries and dead letters
02
Named queues with one enqueue API per job type
03
Workers scale with platform runtime — not separate infra
03 · Runtime Layer
Serverless handlers on platform events
Deploy typed functions with shared auth and data access. Trigger via RPC HTTP — environment binding and observability included.
Functions · One canonical path
SDK
await client.functions.invoke('sell', { … })CLI
conflux push # bundles schema/handlers
Config
fn('sell', { handler: 'inventory.sell', … })What's possible with Functions
01
Serverless and edge functions on platform events
02
Typed handlers with shared auth and data access
03
Deploy through CLI with environment binding
04 · Runtime Layer
Schedules that respect business timezones
Cron expressions, recurring tasks, execution history, and failure alerts as platform defaults. Timezone-aware scheduling for operations that run on business hours.
Cron · One canonical path
SDK
// defined in conflux.config cron block
CLI
conflux doctor # lists cron via API; Console Cron page
Config
cron: [{ name: 'scan', schedule: '0 9 * * *', function: 'scanLowStock' }]What's possible with Cron
01
Scheduled and recurring tasks with cron expressions
02
Timezone-aware scheduling for business operations
03
Execution history and failure alerts built in
Explore
Continue through the platform
Nine layers, one cohesive stack. Browse adjacent layers or return to the full registry.