Step 7
Verify, back up, and operate
Prove the complete path, document recovery, and give IT a repeatable operating checklist.
Acceptance test
Run this with an owner and a second test member:
- Open the dashboard’s
/settingsURL directly and sign in. - Create an organization and pair Relay.
- Confirm Relay reports ready in both the Mac app and dashboard.
- Select one low-risk conversation for access and sync a small history window.
- Open the conversation on desktop and mobile-sized browsers.
- Send a unique test message and verify it appears in Apple Messages.
- Receive a reply and verify it appears in the dashboard.
- Open a received image and download an attachment.
- Invite the second member, accept the invitation, and confirm the member sees only allowed conversations.
- Remove the member and confirm their existing session loses access.
Do not use customer or personal conversations for acceptance testing.
Health checks
GET https://<api-origin>/healthreturns 200.- Direct dashboard routes return the application with status 200.
- The API preflight passes with real production configuration:
/preflight --check-storage. - Redis is reachable and search returns expected recipients after a contact snapshot.
- Relay remains ready after a Mac restart and user login.
Back up four things
| Asset | Why |
|---|---|
| PostgreSQL | Organization, access, message, and synchronization records |
| Object storage | Encrypted attachment bytes |
| Encryption keys | Required to decrypt protected database fields and attachments |
| Configuration record | Required to reconnect providers and rebuild services |
Redis contains derived search data and can be rebuilt. The Relay’s local journal supports resumption but does not replace server backups.
Test recovery
At least quarterly, restore PostgreSQL and object storage into an isolated environment, retrieve the matching encryption key through the documented recovery process, run migrations, and confirm that an authorized test account can read synthetic restored data. A provider’s “backup enabled” badge is not a recovery test.
Updates
Record the deployed release version and archive checksum. Preserve an unchanged copy of the release archive. Review later releases before upgrading. Database migrations run before each API release. Back up production before large upgrades and keep the previous application image available for rollback. Never roll the database down unless the migration’s data-loss impact has been reviewed and explicitly authorized.
Incident notes
Diagnostics must not contain message bodies, contact addresses, account IDs, credentials, tokens, pairing grants, raw preferences, or raw platform errors. Record bounded operational states, timestamps, deployment versions, and whether each dependency was reachable.