Want to know when your own machine boots, logs in, or starts a shell? Create a key, then install one of the generated snippets on the host you want to watch: Get the installer for a key via:
The snippets are designed to be unobtrusive — backgrounded execution, 3–10s timeouts, output redirected to /dev/null. They won’t slow your shell startup or hang your boot if the mantis server is unreachable. Boot and wake alarms get one chance per event, often before the network is back, so they retry up to five times over about a minute. On Windows, the logon task runs as the Users group, in the session of whichever account logs on. The wake and network tasks run as LOCAL SERVICE, so they fire with nobody logged on. Example: alert me on every SSH login
Example: alert me when my Mac boots
These keys behave identically to a normal HTTP key server-side — the difference is the install helpers that wire the trigger to host events. The same key can serve any installer type, so you can reuse one key for shell + login + boot if you don’t want to discriminate.

​
Web-embed snippets (CSS / JS)

In addition to host-event installers, the same /install endpoint generates two web-embed snippets you can paste into your own website:
Both are also visible as tabs (“web CSS”, “web JS”) on the key detail page in the dashboard, with the JS tab exposing an inline hostname input field. The dashboard tab regenerates the snippet whenever you change the hostname. Your own site loads the CSS on every page view. Add your site’s origin (for example https://www.example.com) under “your own site” on the key page, or as self_origins in the API. Hits whose Referer comes from those origins are ignored, so your own visitors can’t occupy the dedupe window and hide a cloned site’s hit. This needs your pages to send at least an origin Referer — the browser default does; Referrer-Policy: no-referrer or same-origin does not — and a clone that hot-links your stylesheet instead of copying it is not detected. The CSS uses partial escape-sequence obfuscation on the URL (\00006c for l, etc.) so the canary URL is less obvious to a casual reader of the stylesheet. Snippets generated before 0.3.0 used short escapes that usually decoded to a different URL and never fired — regenerate and re-paste them. The JS snippet sends explicit ?l=<location>&r=<referrer> query params alongside the canary URL so you can identify the cloning site even when the Referer header is stripped (strict referrer policies, mixed-protocol downgrades, etc.). They are stored with the hit as x-mantis-page-url and x-mantis-page-referrer.

​
Physical snippets (NFC)

The /install endpoint also generates an NFC URL record:
Write the generated URL to a blank tag with any NFC writer app. Mantis appends ?src=nfc, which the trigger endpoint promotes into host_context.source = "nfc" when the tag is tapped. The printable nfc-label PDF is a QR/sticker companion for the same key; it only fires when scanned or tapped, not when the PDF itself is opened.

​
Smart-home snippets (Home Assistant / Scrypted)

The /install endpoint also generates smart-home snippets:
Use --profile on the install command to decide which server the generated snippet reports to. The snippet stores a literal URL, so changing the CLI’s current profile later does not affect already-installed Home Assistant or Scrypted automations.

​
Drive an action when a hit fires

The snippets above let Home Assistant trigger a mantis. The reverse also works: a home_assistant notification destination lets a hit drive HA — flip a switch, cut a VLAN, fire a scene, or push a phone notification. Point it at an HA webhook automation:
Every hit then POSTs a mantis.hit JSON payload (memo, IP, user-agent, and the full host_context) to that webhook. The target URL must end in /api/webhook/<id>. To scaffold the HA side, generate a ready-to-paste automation skeleton — it listens on the webhook, drops the activation ping, and shows example actions (switch toggle, mobile push, logbook entry). The file carries an unguessable webhook id; treat it like a secret, because it is the only credential between Mantis and Home Assistant:
If Mantis reaches HA over a private/Tailscale address, the SSRF guard blocks it unless you set ALLOW_PRIVATE_WEBHOOKS=1 (an instance-wide switch — prefer restricting egress at the network layer). A refused destination always reports “destination refused: it does not resolve to a public address”; the server log has the reason. Receivers generated before 0.3.0 used a webhook id derived from the key id (mantis-<8 hex>). Generate the file again and re-register the destination to move to an unguessable id. For devices that do not expose useful webhooks, iot-helper/ can watch LAN neighbor tables and log files, then fire the same Mantis URL for unexpected online/login events. On main, regenerated Scrypted scripts report rejected HTTP responses and delivery timeouts in the Scrypted script console. Reinstall the generated script to pick up this behavior. For Home Assistant OS or Supervised, use the local add-on packaging guide to package the helper and copy the complete add-on folder into Home Assistant.

​
What information each installer captures

Each installer sends X-Mantis-* headers alongside the hit, which the server parses into a structured host_context object exposed on the API + dashboard + CLI. (Boot-time installers don’t include X-Mantis-User because no user is logged in yet. The Windows wake and network tasks run as LOCAL SERVICE, not as a person, and don’t send it either.) The big win is $SSH_CLIENT — when someone SSHes into your machine and the shell snippet fires, the mantis records the SSH client’s IP, not just the machine’s own public IP. The dashboard surfaces this prominently as ← <client-ip> next to the user/host context. The CLI shows the same:
Empty / missing X-Mantis headers (e.g., a non-SSH local shell, or a boot event with no user) are simply not displayed, so the chip stays compact.