Breeze: An AGPL RMM and PSA That Puts an AI Operator Inside the Ticket Queue

What Breeze Actually Combines

Breeze is a remote monitoring and management (RMM) platform fused with a professional services automation (PSA) system. The README is explicit: monitoring, patching, remote access, scripting, and network discovery sit next to ticketing, quotes, billing, invoicing, and a service catalog. The pitch is that you do not need a separate PSA and a sync job. The ticket, the time entry, the quote, and the invoice all live in the same place. The target user is an MSP managing multiple clients, or an internal IT department that wants one pane of glass. The multi-tenant architecture is built in from day one, not retrofitted. That matters because many RMM tools start single-tenant and bolt on client separation later. Breeze claims to avoid that legacy. The platform is written in TypeScript, with a lightweight agent shipped as a single Go binary. The README says the agent is cross-platform and has a minimal resource footprint. No benchmark numbers are given, so treat that as a design goal rather than a measured fact.

The AI Operator Is Not a Chatbot

The central differentiator is the AI operator that uses the platform itself. The README describes it as an agent, not a chatbot. It investigates alerts, remediates issues, resolves tickets, and documents what it did. It only interrupts a human when a decision is required. The safety mechanism is a risk-classified action engine. Dangerous operations require human approval, and critical operations are blocked entirely. This is a meaningful distinction from a simple LLM wrapper. The agent has built-in tools to act on devices and tickets. The README does not specify which actions fall into which risk class. That is a gap. You would need to read the source or the security whitepaper to know whether a patch deployment is 'dangerous' or 'critical'. The approval workflow is the core of the product, so the lack of a public list of risk classifications is a real documentation gap.

Security Claims and the Architecture Behind Them

The README includes a detailed security table. Authentication uses Argon2id passwords, JWT with a 15-minute expiry, TOTP MFA, and SHA-256 hashed tokens. Authorization is RBAC with scope-based multi-tenancy. The most striking claim is forced PostgreSQL row-level security on every tenant table, with no app-layer-only fallback. The README states that even table owners cannot bypass it. That is a strong claim. Row-level security in PostgreSQL can be circumvented by a superuser, so the implementation must be careful about roles and privileges. The encryption story is AES-256-GCM at rest, TLS 1.2+ in transit, and HSTS preload. Rate limiting uses a Redis sliding window on all auth endpoints and agent APIs, and it fails closed if Redis is unavailable. That fail-closed behavior is good for security but has an operational cost: if Redis goes down, auth and agent APIs stop working. The README also lists five automated scanners in CI: CodeQL SAST, Gitleaks, npm audit, govulncheck, and Trivy CVE scanning. That is a concrete supply chain practice, not a vague promise.

Getting It Running: Quick Start and Configuration

The README points to a quick start section, but the provided material does not include the actual commands. That is a limitation of this review. The homepage and the repository are the reference. Based on the stack described, a self-hosted deployment likely requires PostgreSQL, Redis, and the Breeze server. The agent is a single Go binary, so installation on a managed device is a matter of placing the binary and setting a bearer token. The README mentions that the agent config file uses 0600 permissions and bearer token auth with SHA-256 hashing. Optional Cloudflare mTLS is available for agent connections. The repository has releases like v0.108.0, which suggests a CI pipeline produces installable artifacts. To get a real answer, you would clone the repository and read the quick start file. The live demos at breezermm.com/features are the fastest way to see the UI without installing anything.

The PSA Side: Billing Where the Work Happens

The PSA module is not an afterthought. The README describes tickets with SLA tracking, time and parts logged on the ticket as work happens. Quotes are generated from the ticket, priced from the service catalog with markups applied. Invoicing takes the time and parts from the ticket and turns them into an invoice. No export, no re-entry. That is a specific workflow that many MSPs want. The customer portal is a branded self-service hub where end-users open tickets. The service catalog is priced once and used everywhere. This integration is the main reason to choose Breeze over a separate RMM and PSA pair. The trade-off is that you are locked into Breeze's PSA model. If you already use a mature PSA like ConnectWise or Autotask, migrating your billing history and workflows into Breeze is a project in itself. The README does not provide an import path or migration tooling. That is a gap to verify before committing.

Where Breeze Is the Wrong Tool

The AGPL-3.0 license is the first filter. If you are a vendor who wants to embed Breeze in a proprietary product, AGPL requires you to release your modifications and potentially your surrounding code if you offer it as a network service. That is a hard blocker for many commercial projects. For an MSP using Breeze to manage its own clients, AGPL is workable because you are not distributing the software. The second filter is operational complexity. Breeze has a multi-tenant PostgreSQL database with row-level security, Redis for rate limiting, S3 for audit log archival, and a TURN relay for remote access. That is a serious infrastructure footprint. The README claims disaster recovery with RTO under 1 hour and RPO under 15 minutes. Meeting that requires a real backup and failover strategy. If you are a solo IT consultant who just wants to monitor a few dozen devices, Breeze is overkill. A simpler RMM like Tactical RMM or a lightweight agent would be easier to run. The AI operator also assumes you want an agent taking actions. If your compliance regime requires a human to approve every patch, the risk-classified engine might still allow automated remediation for low-risk actions, and you would need to configure it to be more conservative.

Alternatives and How They Differ

The most direct alternative is Tactical RMM, an open-source RMM written in Go and Vue. It focuses purely on remote monitoring, scripting, and remote access. It has no PSA, no billing, and no AI operator. You would pair it with a separate ticketing system like osTicket or a full PSA. The difference in approach is fundamental: Tactical RMM gives you the tools and leaves the workflow to you, while Breeze gives you an integrated workflow with an AI agent that does the work. Another alternative is the commercial RMM+PSA suites like NinjaOne or ConnectWise, which are closed-source and per-device licensed. Breeze's 'never metered' claim means self-hosting with unlimited devices is possible, but you pay with operational effort and AGPL obligations. The AI operator has no direct open-source equivalent in the RMM space. That is the unique selling point, and also the riskiest part to trust.

Editorial conclusion

Adopt Breeze if you are an MSP or internal IT team that wants a single system for monitoring, patching, remote access, and billing, and you are comfortable with the AGPL-3.0 license and self-hosting a multi-tenant platform that holds privileged access to every managed device. Do not adopt it if you need a per-device commercial license, a turnkey cloud with a free tier, or if you prefer a separate PSA that your technicians already know. Before production, verify the AI approval workflow against your own risk tolerance: test what happens when Redis is unavailable, confirm your backup meets the stated RPO of 15 minutes, and run the security scanners in CI on your fork. Also confirm the row-level security enforcement works with your PostgreSQL setup, because the README claims even table owners cannot bypass it, and that claim needs practical validation on your infrastructure.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes