Add Device modal: per-link expiry picker

[bdunncompany]

What's missing

The "Add New Device" modal lets the admin choose a Site, Platform, and Number of devices, but not the lifetime of the generated installer link.

Today the link's TTL is set globally by CHILD_ENROLLMENT_KEY_TTL_MINUTES (and the parent by ENROLLMENT_KEY_DEFAULT_TTL_MINUTES). Default 24h for child, 60min for parent. That's reasonable for an admin who's rolling out devices same-day. It's too short for an MSP who's onboarding a remote site where some endpoints are intermittently online — a kiosk that's powered on once a week, a satellite location with a roaming laptop fleet, a remote contractor who picks up the link a few days later.

The current workaround is to bump those env vars globally on the server. That over-corrects: it gives every link, in every partner / org / site, the same long lifetime, including cases where a short-lived bootstrap token would actually be the right security posture.

Proposed change

Add a "Link expires in" picker to apps/web/src/components/devices/AddDeviceModal.tsx (and matching surface on the install-link generator route). Options like:

• 1 hour
• 24 hours (current default)
• 7 days
• 30 days
• 90 days
• 1 year
• Never

The server side already supports it. enrollment_keys.expires_at is nullable on the schema, the create-endpoint zod accepts an explicit expiresAt, and the read path already handles null as "never expires" (existing keys named "Thorne Deployment" on this MSP have expires_at = NULL and work fine). Only the modal lacks the input.

Implementation could either:

• Send expiresAt (absolute ISO timestamp) computed client-side from the picked option.
• Or send a small enum/TTL-in-seconds value and have the server resolve it. Probably the cleaner of the two since it keeps timezone math out of the browser.

Optional: partner-level cap

For partners that want to enforce shorter-lived install links as a security default — even when an individual admin tries to pick "Never" — the partner-settings layer could expose partners.settings.maxEnrollmentLinkTtlMinutes. The Add Device modal would clamp the picker options to that ceiling. Not blocking; just worth flagging since the inheritable-settings shape is already in place from the launcher / org-reorder work.

Why now

Real MSP scenario: rolling out to a remote office where machines come online sporadically. With the 24h default, the link expires before half the fleet has even checked in. Bumping the global env to 30 days fixes that customer, but breaks the principle of least privilege for every other link the same admin generates. Per-link override is the obvious lever.

Happy to PR if there's interest. Tiny diff, no DB or schema change — only UI + payload addition.

[ToddHebebrand]

Green light — PR welcome. Real MSP pain and the server already supports it; only the modal needs work.

A couple of preferences:

• Wire format: send a TTL-in-seconds (or a small enum) and have the server resolve to expiresAt. Keeps timezone math out of the browser, and means we can change the option set later without coordinating client+server.
• "Never" option: include it, but only show it to users with partner scope. Org-admin scope should be capped at something finite (suggested ceiling: 90 days). We can revisit if anyone complains.
• Partner-level cap (partners.settings.maxEnrollmentLinkTtlMinutes): worth adding in the same PR since the inheritable-settings shape is already there from the launcher / org-reorder work. Clamping the picker against it is the right UX. If you'd rather scope it to two PRs (UI first, cap second) that's fine too — just don't ship "Never" without the cap landing soon after.
• Default: keep 24h. Users who need longer will see the picker.

Mention the install-link generator route in the PR description if you wire it on that surface too — easy to forget there's a second entry point.

[ToddHebebrand]

Shipped — the per-link expiry picker on the Add Device modal landed on main in #739 (merged 2026-05-17), including the follow-up that makes the picker drive the child-key TTL.

Thanks @bdunncompany. Closing as resolved — please verify in your environment and reopen if needed.