Direct Connectivity and Trust Boundaries
How the TriggerDeck iPhone app separates direct Zabbix browsing from optional push delivery.
Why TriggerDeck keeps browsing direct
TriggerDeck is designed for operators who do not want to hand their monitoring credentials to a hosted proxy. The iPhone app reads monitoring data directly from your configured Zabbix server.
This keeps the browsing path simple:
- the app uses your API token
- the token stays on the device
- browsing data does not depend on push infrastructure
- problems, hosts, items, charts, and dashboards stay on the direct iPhone-to-Zabbix path
What the push service does
The optional TriggerDeck push service is used only for registration and notification delivery.
It does not:
- access your monitoring token
- store your monitoring credentials
- replace in-app browsing
Trust boundary map
| Component | Handles customer Zabbix API token | Reads monitoring data directly | Sends push notifications |
|---|---|---|---|
| TriggerDeck iOS app | Yes, on-device only | Yes | No |
| TriggerDeck push service | No | No | Yes |
| APNs | No | No | Transports notifications only |
Why the split improves operations
This split reduces the blast radius of a hosted service incident. If push delivery is unavailable, operators can still open the app and browse the monitoring environment.
It also keeps responsibilities clear:
- the app is for browsing and triage
- push is best-effort notification delivery
- each path can be tested separately
Practical deployment checklist
Before calling a TriggerDeck deployment ready:
- Confirm direct browsing works from the iPhone even when push is disabled.
- Confirm tokens are scoped and stored only on-device.
- Confirm the push service is used only for registration and APNs delivery.
- Confirm Zabbix media configuration uses the right per-server
UNIQUE_UID.