diff --git a/pb_migrations/1792000000_session_lifetime.js b/pb_migrations/1792000000_session_lifetime.js
new file mode 100644
index 0000000..8bdaa1c
--- /dev/null
+++ b/pb_migrations/1792000000_session_lifetime.js
@@ -0,0 +1,37 @@
+/// <reference path="../pb_data/types.d.ts" />
+
+// Keep a television signed in across a holiday.
+//
+// **Why.** The auth token lasted five days. The app refreshes it on every
+// launch, so a device used regularly never noticed, but a device that is simply
+// not switched on has nothing to refresh with. A family went away for a week,
+// came back, and the television asked them to sign in again, on a remote, with
+// no keyboard.
+//
+// Five days is a sensible default for a service people log into from a laptop.
+// It is the wrong shape for the machines this app runs on: a box in a living
+// room that might sit untouched over a holiday, or a grandparent's television
+// used a few times a month. For them a sign-out is not a small inconvenience,
+// it is a phone call to somebody who can type an email address on a D-pad.
+//
+// Ninety days is chosen against that, not against a security model that would
+// prefer shorter. The tokens live in the OS secure store, the threat here is not
+// somebody exfiltrating one, and a password change still rotates tokenKey and
+// invalidates every outstanding token. The cost of the old value was being paid
+// by the least technical people in the house.
+//
+// Applied to the live database by hand on 2026-08-29 before this file existed;
+// recorded here so restoring the backend from migrations does not quietly put
+// it back to five days.
+migrate(
+  (app) => {
+    const users = app.findCollectionByNameOrId("users");
+    users.authToken.duration = 7776000; // 90 days
+    app.save(users);
+  },
+  (app) => {
+    const users = app.findCollectionByNameOrId("users");
+    users.authToken.duration = 432000; // 5 days, the previous value
+    app.save(users);
+  },
+);