Self-hosting
What is hosted, what you can run yourself, and where the line is drawn and why.
| pingtower.com | Your box | |
|---|---|---|
| Accounts, sign-in, memberships | always | never |
| Sources, log lines, templates, alerts | hosted tenants | paired tenants |
| Rules, on-call, integrations, actions, incidents | yes | yes |
| Status pages, maintenance windows, uptime reports | yes, at {slug}.ptwr.net or your own domain | yes, at /status/{slug} or your --status-host |
| Log search, secret detection | yes | yes |
| Webhook, Slack, Telegram, Discord delivery | yes | yes, directly from the box |
| Hosted checks | yes, from Pingtower’s servers | assigned to your own agents instead |
| AI assistants (MCP) | yes | no |
| Push to the iOS app | yes | through the relay only |
| Plans and quotas | yes | your own flags |
Why push is the line
Apple accepts a push for a bundle id only from a key issued under the team that owns it. A daemon you run cannot hold that key, so it cannot page the App Store app directly. That is a code-signing boundary, not a setting.
The relay closes it. Your box asks pingtower.com, over an outbound connection it opens itself, to forward a page to the paired devices of the members allowed to see that alert’s project. Sources, log lines, rules and alert history never leave the box.
What running the daemon gives you
The whole inbound half: ingest, template dedup, rules, alert state, escalation, on-call, and every outbound integration that is not Apple push. It is the same daemon that serves pingtower.com, built without the phone registry and the push sender, signed, with no runtime and no external database.