System architecture
Pulsar Architecture Guide
Understand how Pulsar separates the web workspace, API policy, workers, stateful services, model runtimes, media workflows, and operator controls.
Key considerations
Workspace layer
User workflows and administrative surfaces.
Policy layer
Authentication, routing, rate limits, queues, and approvals.
Runtime layer
Model, media, database, queue, and object-storage services.
Architecture at a glance
The web workspace is not the model server
Pulsar keeps the product experience, identity, policy, workflow, and data model separate from the selected chat and media runtimes.
State has explicit owners
Postgres stores users, configuration, metadata, and workflow records. Valkey handles queues, rate limits, concurrency controls, and ephemeral coordination. SeaweedFS, an Apache-2.0 S3-compatible object store, retains attachments, images, videos, exports, and other large objects.
Workers make long-running work durable
Scheduled tasks, generated media, and background processing use queue-backed workers with bounded retries and visible status instead of relying on a browser request to remain open.
Administrative evidence crosses every layer
Operators need health, queue, runtime, database, storage, log, audit, and configuration views to understand the system as one deployment.
Private deployment consultation
Review Pulsar against your environment.
Bring the infrastructure, security boundaries, model runners, and use cases. The Pulsar team will map the appropriate deployment path.