Technical guides
Pulsar Guides
Practical guidance for designing, deploying, and operating a private Pulsar workspace.
Pulsar guides explain how the product is assembled, where its responsibilities begin and end, and how to make deployment decisions without relying on hidden assumptions. They are written for people who need to evaluate or operate a private AI workspace, not only for readers looking for a feature tour.
Choose a starting point
Read the collection in order for a first deployment. Begin with Pulsar Architecture to understand the application, state, coordination, runtime, tool, and external-service boundaries. Continue with Planning a Pulsar Deployment to select hardware, runtime placement, storage, and network responsibilities. Finish with Operating a Private AI Workspace to define health checks, backups, recovery, approvals, and routine review.
| Guide | Use it when | Decision you should leave with |
|---|---|---|
| Pulsar Architecture | You need a reliable system model before a security or infrastructure review. | Which components own durable records, transient coordination, objects, and model execution. |
| Planning a Pulsar Deployment | You are sizing or placing a new environment. | Whether the deployment is self-contained, external-runtime, or hybrid, and who owns each dependency. |
| Operating a Private AI Workspace | You are preparing a release gate or operating runbook. | How to observe, back up, recover, and approve changes without overstating automation. |
Use the guides with field evidence
Guides describe the stable product model. Field Notes narrow the lens to a reviewed topology or workflow and state their evidence limits. The split-compute note is useful when model GPUs live on another host. The Pulsar Code note is useful when a repository change must remain isolated until a reviewer grants an exact publication action.
Capacity is calibrated, not promised
Model fit, context length, and useful concurrency depend on available CPU memory, GPU memory, runtime overhead, model format, and workload. Treat the published system requirements as planning ranges. Installation validation and workload testing determine the final operating envelope.
What these guides do not claim
The collection does not claim built-in high availability, automatic runtime failover, universal zero-egress behavior, encrypted backups, audited compliance, or fixed performance. Those outcomes require deployment-specific controls and evidence. Each guide calls out the boundary between verified Pulsar behavior and infrastructure choices that remain with the operator.
Pulsar Architecture Guide
A practical system model for Pulsar application services, durable state, transient coordination, AI runtimes, tools, and external trust boundaries.
Read more
Planning a Pulsar Deployment
Choose a deployment pattern, model runtime, storage profile, network boundary, and verification plan before installation.
Read more
Operating a Private AI Workspace
Build an operating routine around health checks, logs, queues, backups, controlled recovery, approvals, and evidence.
Read morePrivate 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.