Deployment architecture
Private AI Deployment
Plan a controlled Pulsar deployment across application services, private model runners, media workflows, storage, and network boundaries.
Key considerations
Compute node
Frontend, API, workers, Postgres, SeaweedFS object storage, and Valkey run in an isolated application environment.
External runtimes
Primary models and ComfyUI can run on dedicated hosts sized and governed separately.
Controlled exposure
Public traffic terminates at the approved proxy while internal dependencies remain private.
Architecture at a glance
Start with the deployment boundary
A Pulsar deployment begins by identifying which network receives users, where application services run, where model inference is allowed, and who operates storage and backups. The application does not require every workload to share one host. Pulsar uses Valkey for queues, rate limits, concurrency controls, and ephemeral coordination. Valkey supports the Redis-compatible protocol used by Pulsar’s application clients.
- The compute node contains the web application, API, workers, metadata database, queue/cache, and object storage.
- vLLM or LM Studio is selected as the primary OpenAI-compatible model runner.
- ComfyUI can remain a separately managed media host.
- An optional Ollama service can run internal utility work without appearing in the user model picker.
Separate environments without accidental overlap
Environment labels, compose project names, port plans, volumes, and Docker networks keep development, QA, and production peers distinct. Multiple environments may share approved external model infrastructure while retaining separate application data.
- Each environment uses its own Postgres data, Valkey state, SeaweedFS bucket, and Docker network.
- Runtime endpoint changes preserve unrelated environment configuration.
- Health probes verify the selected runner before the deployment is accepted.
Keep internal services internal
The recommended shape exposes the approved web entry point and binds databases, queues, and object storage to internal interfaces. Operators should place TLS, access policy, and request controls at the reverse proxy and avoid publishing dependency ports directly.
- Generate unique application, database, and storage secrets.
- Restrict configuration files to the service account.
- Allow only required network paths between the compute node and approved runtime hosts.
- Use secure cookie and origin settings that match the production hostname.
Validate before promotion
A deployment is not complete when containers start. The release gate verifies frontend and API readiness, database and queue health, object storage, configured model reachability, optional utility service health, and ComfyUI availability when enabled.
Back up data and rehearse recovery
Postgres, object storage, configuration, and environment-specific secrets require separate backup policy. Restore tests belong in the operating schedule, and production promotion should always retain a known rollback point.
Exact installation remains gated
Public documentation explains the architecture and evidence an evaluator needs. Current package contents, exact installer steps, and environment-specific configuration are provided during a deployment review so they can be matched to the target infrastructure.
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.