On-prem first: the case for local agents in dental software

Pulse runs a small Windows service on your Open Dental server. We call it the Pulse Connector. Every byte of data we use, we read through it. There's no inbound port. There's no copy of your PMS sitting in our cloud. This essay is why we built it that way — and why most of our category didn't.

The shape of the agent

Twelve megabytes. Outbound mTLS. One uninstall button.

The Connector is a Go binary. It runs as a Windows service on the same box as Open Dental (or a near peer on the same LAN). It authenticates outbound to connector.pulse.alfoai.com over mTLS — client certificate per practice, rotated automatically. No inbound ports. No firewall holes to punch.

It talks to Open Dental two ways: the OD API Service on port 30223 (writes), and read-only SQL against the OD database (reads it can't do over the API yet). That dual access is the whole reason we picked OD over a multi-PMS surface — see the comparison page for the long version.

Why on-prem at all

Three reasons, in priority order.

PHI sovereignty. The default Insights tier (Tier 1) ships only aggregated, de-identified rollups to our cloud. Patient names, chart numbers, clinical detail — never leave your network. That's only possible because the aggregation happens at the source, on the Connector. A cloud-only architecture would have to read full rows to compute the same numbers; on-prem doesn't.

Latency on writes. Remit posts a 50-claim ERA in 25-35 seconds, end-to-end. Most of that window is the OD API responding to write calls (it doesn't batch). A cloud-only architecture adds 200-400ms of round-trip per call, multiplied by however many writes a typical ERA generates — for a 50-claim payment that's a 2-3 minute walltime delta. The Connector is on the same LAN as OD, so the writes finish at LAN speed.

Revocability. The Connector ships a one-click uninstall path. Run it from the OD server and every Pulse credential is wiped, the mTLS cert is revoked server-side, and our access to your network is gone in under thirty seconds. You don't need a support ticket to leave. That matters to compliance officers.

The trade-offs we accept

This architecture is not free.

A Windows service to maintain. We ship auto-updates over the same mTLS channel, with rollback if a version misbehaves. But the Connector is one more thing on your server. We bias toward it being boringly stable — Go binary, no runtime dependencies, single-process, restartable. It's never a vector we want our customers debugging.

Multi-PMS is harder. A cloud-only multi-PMS vendor can stand up a new PMS connector in a quarter. We'd need to ship and support a new on-prem agent per PMS. We picked depth over breadth — Pulse goes deep on Open Dental and we don't pretend otherwise. Different practices need different vendors. That's OK.

Offline behavior is your problem to know about. If the OD server loses internet, the Connector queues outbound aggregates locally and ships them once the link comes back. But Remit writes (ERA posting, denial appeals) can't flow until you're online. We surface that state explicitly in the UI; we don't hide it.

What you actually feel

Day-to-day, you don't see the Connector. It's a service icon in your Windows tray that says "Pulse Connector — running, synced 14s ago." The auditor likes that there's no inbound port. The IT person likes that it auto-updates. The compliance officer likes the uninstall path. The owner likes that the writes land in OD instantly.

The architecture isn't a marketing flourish. It's the shape of the answer when you take HIPAA, write latency, and customer revocability seriously. Cloud-only would have been easier for us to ship. On-prem-first was the right call for the customer.

On-prem-first means "your data stays in your network unless you explicitly ask it not to." That should be the default in healthcare. It isn't. We made it ours.