Skip to main content
Dynamite is a standalone personalization service. It owns runtime delivery, durable workspace data, releases, setup jobs, preview sessions, MCP credentials and analytics. Ion is an authenticated client, not a second runtime host or direct database reader.

​
Package map

​
Request surfaces

​
Serving boundaries

The standard browser decision is one bounded server-side choice call for all relevant slots. Editorial candidate choices can join that call. Setup/research and generative variant authoring run separately from visits. They can be slower and use different model credentials without entering the page’s decision deadline. The CDN hosts shared script assets and release metadata. The application service continues to own configuration, decisions, authentication, billing and data. A static script deployment does not migrate workspace storage or publish new customer content.

​
State and process ownership

Dedicated Postgres stores durable production records. Local development can use files when no database is configured; analytics then uses memory. Preview sessions, active setup execution, caches and some scheduling state remain process-local. Keep one active execution owner. Horizontal replicas or overlapping active deployments are not safe merely because the data is in Postgres. A draining/standby rollout must transfer background ownership deliberately after checking work and connections. Retain the legacy volume for pre-cutover recovery.

​
Ion integration

Ion uses a versioned client with a 60-second HMAC-signed identity bound to the service origin. The shared secret stays server-side. Organization/user checks remain in Dynamite and, where required, its fixed Ion callback. Shared adaptive, UI and client artifacts are exported together with source commit and hashes. Server implementation and private workspace records are not client artifacts. See storage and security, development and the source map.