Pairing & remote access
How a remote client gets a network token, the reach model that limits where it works, and how to keep it safe.
Nothing leaves the machine, except when it does
That guarantee holds for loopback calls only. The moment you point a client at a LAN address, or approve a webhook destination, meeting data leaves this machine and travels to wherever that target runs.
Reach: computer vs. network
Every token is minted for one of two reach levels, and it stays there:
computer- loopback only, plain HTTP, same machine. This is what the built-in CLI key and a self-issued app key get by default.network- LAN only, over HTTPS with a self-signed certificate pinned at pairing. This is what a paired device gets.
A computer-reach token is refused if it's presented over the network. Turning on LAN access for the install doesn't retroactively widen what an existing loopback token can do. To reach the app from another machine at all, you pair a client and get a network-reach token minted for that purpose.
No relay, no NAT traversal
Meetily doesn't run a relay server and doesn't do NAT traversal (no STUN/TURN). "Remote" means one of two things: the client is on the same LAN as the host, or it's on a VPN that puts it virtually on that LAN. There's no third way to reach it from an arbitrary point on the internet.
The pairing lifecycle
On the host, open Pair a device under Settings > Integrations > Apps & scripts. A window opens for about 10 minutes; while it is open, Meetily listens on your network at https://<host>:8421 so the device can reach it, and it closes by itself.
The panel shows the LAN address, the host's certificate fingerprint (once it is available), a one-time pairing code, and the exact command to run on the other computer. Copy that command and run it on the client within the window.
Use the command the panel shows you
The pairing command is generated per session - copy it from the panel. Note that in current builds the in-app command form (... pair --server https://<host>:8421 --code <pairing-code>) differs from the standalone CLI's own pair subcommand (meetily-pro pair <host> [--fingerprint <sha256>], no --code/--server). Use whatever the panel gives you for your build.
Completing the pairing within the window mints a 90-day network token for that device. Scopes are only ever narrowed from what the client requested, never widened.
If the window closes first, the request expires and you start over.
Trust bootstrap: pinning the certificate
LAN access is served over HTTPS with a self-signed certificate. There's no CA chain behind it, so pinning the certificate's fingerprint is the only trust anchor. Get the fingerprint out-of-band from the host, for example by running:
openssl x509 -fingerprint -sha256 -noout -in <cert-file>against the certificate Meetily persists for LAN access on the host . In the common case you don't need openssl at all: the Pair a device panel displays the host fingerprint once the cert is available, so you can read it there and verify it out-of-band. Pin it before the first request either way - the pairing command the panel gives you carries the trust for that session, and the standalone CLI also accepts an explicit --fingerprint <sha256>. The client then trusts only the exact certificate you verified, not whatever answers at that address.
Safe-posture checklist
- Loopback is the default reach, and it's enough for anything running on this machine. A local CLI or MCP client never needs the network.
- If you do turn on LAN, pin the certificate fingerprint out-of-band before you pair. Only pin a fingerprint you verified yourself.
- Keep the API Pro-gated and off by default. Turn it, and LAN, on only when you actually need remote or paired access, and turn LAN back off when you don't. See Governance & administration.
Threat model
The bearer token is the real authentication boundary here. Reach, the pairing window, and certificate pinning all narrow how a token can be obtained, or the blast radius if the network layer is misused - none of them replace keeping the token itself secret.
A couple of residual caveats are worth knowing rather than assuming away:
- Anyone who can run code as your local user account can generally read what that account can read, including a token file on disk. File permissions stop other OS users, not other processes running as you.
- Meetily doesn't manage your OS firewall or router. Turning on LAN access opens a listening port; whether another device on your network can actually reach it is still up to that configuration.
Related
Last updated on