Trust & Security
A message recorded for a grandchild's wedding ten years from now is one of the most personal things a person will ever entrust to a piece of software. We treat that responsibility seriously. This page summarises how earlier.me protects what residents, families, and facilities place in our care — and what we ask for in return so the system stays trustworthy at scale.
At a glance
- Message bodies and recipient lists are encrypted at rest with AES‑256 at the database layer.
- Audio and video are encrypted at rest in Amazon S3 (SSE‑S3, AES‑256), and accessed only through short-lived signed URLs.
- All traffic is HTTPS only. HSTS is enabled with subdomain inclusion and preload.
- No human at earlier.me reads message contents. Decryption happens at delivery, on the recipient's terms.
- Family-link URLs are signed and revocable per resident, so access can be cut at any time.
- Errors are surfaced to a monitored exception tracker so failures are seen and fixed quickly.
Encryption
At rest
Two independent layers of encryption protect content at rest. The first is application-level: message bodies and trusted-keeper email lists are encrypted with AES‑256‑CBC using Laravel's encryption framework, keyed to a per-environment application key that is held only on our servers. Even a database backup or filesystem snapshot leaks no readable message text. The second is infrastructure-level: the underlying Amazon RDS volume is encrypted with AWS‑managed keys, and uploaded media in Amazon S3 is stored with SSE‑S3 (AES‑256) server-side encryption.
In transit
Every request to earlier.me is served over TLS 1.2 or TLS 1.3. We send a Strict-Transport-Security header that instructs browsers to refuse plain‑HTTP connections to our domain for one year, applied to subdomains and submitted to the HSTS preload list. Internal traffic between our application servers and the database, queue, and storage backends rides over private network links that are themselves encrypted by AWS.
Key management
The application encryption key never leaves the production environment. It is stored as an environment variable provisioned by our hosting provider, not committed to source control. Rotating the key is a planned, audited operation that re-encrypts every affected row, not a hot swap.
Access control
Authentication
We default to passwordless sign-in: a six-digit code emailed to the address on file, plus a single-use signed magic link in the same email. Both expire within minutes of issue. A traditional password is offered as a backup but is never the only option. We rate-limit code-send and code-verify endpoints aggressively to deter automated guessing.
Authorisation
Roles are explicit. A facility admin can manage their facility, residents, staff, and billing, and nothing else. A staff member can record on behalf of residents but cannot see another facility's data. A resident's own messages are tied to their own identifier. Every privileged route is gated by middleware that resolves the organisation from the URL and refuses access to anyone whose record doesn't match.
Family links
When a facility shares a family link, the URL itself carries an HMAC signature plus a per‑resident secret. Either component can be invalidated independently. Rotating the resident's family-link secret immediately revokes every previously-issued URL for that resident — useful when an email account is compromised, a family member should no longer have access, or the resident transfers facilities.
Public message links
A delivered message can be re-viewed via a 32‑character random token in the URL. The token is generated server-side, is not derived from any predictable input, and is only exposed once delivery has actually occurred. Tokens for messages that have not yet been delivered are not visible to anyone, including the recipient.
Subprocessors
The following services process data on our behalf. We do not use any others.
- Amazon Web Services — primary application hosting, database (RDS), and media storage (S3). U.S. region. SOC 2 Type II, ISO 27001, HIPAA-eligible.
- Laravel Cloud — deployment and operations layer over AWS. Inherits AWS controls.
- Stripe — payment processing for individual message purchases and facility subscriptions. PCI DSS Level 1. We never see or store card numbers.
- Postmark — transactional email delivery for sign-in codes, message-saved confirmations, and the actual delivery of messages to recipients. SOC 2 Type II.
- Sentry — application error tracking. We deliberately scrub message bodies and personal-message content from any reports that reach Sentry; only stack traces and request metadata are sent.
Data retention & deletion
Scheduled messages are retained until they are delivered, at which point a single delivered copy remains so the recipient can re-open the public link. Drafts that have not been activated are kept for thirty days and then automatically pruned. Unattached uploaded media is pruned daily.
A facility administrator can deactivate a resident, in which case no new messages can be scheduled for that resident, but already-scheduled messages are honoured to their delivery date. A facility may request full deletion of its account — including all residents, scheduled messages, and undelivered media — by emailing hello@earlier.me. Personal users may do the same.
Once a message has been delivered, the copy in the recipient's inbox is outside our control. We can remove our stored copy on request, but cannot recall an email already sent.
Operational controls
Backups
The production database is backed up automatically every day, with point-in-time recovery covering the previous seven days. Backups are encrypted with AWS-managed keys and live in a separate availability zone from the primary. We periodically perform restore drills against a non-production environment to confirm backups are usable.
Monitoring
Uncaught exceptions are forwarded to a dedicated error-tracking service (Sentry) within seconds of occurring. Delivery jobs — the part of the system that actually emails messages on the day they're due — are queued, idempotent, and retried with exponential backoff for up to roughly one day. A permanent delivery failure raises an alert so an operator can intervene before the family notices.
Change management
All code changes pass an automated test suite before they reach production. Database migrations are reversible where reasonable, and destructive operations (e.g. demo‑environment seed resets) are gated by both an environment match and an explicit configuration flag, so a misconfigured server cannot accidentally wipe customer data.
Incident response
If we detect — or are notified of — a security incident affecting customer data, we will: (1) contain the incident, (2) determine which facilities and individuals are affected, (3) notify affected facility administrators within seventy-two hours of confirming the impact, with a description of what happened, what data was involved, what we have done in response, and what (if anything) the facility should do, and (4) publish a public post-mortem when the underlying cause is shareable without compromising further security.
HIPAA & PHI
earlier.me is built for personal messages — birthday wishes, milestone messages, legacy notes — not for clinical communications. Personal messages of this kind are typically not Protected Health Information under HIPAA, even when they originate inside a care facility.
We do not currently sign Business Associate Agreements. If your facility's policy requires a signed BAA before any resident-related data can be stored on a vendor, earlier.me is not the right tool for you today. We are happy to discuss your specific requirements; in many cases the messages residents record fall outside the BAA scope and we can document that clearly for your compliance team. The technical posture above (AES‑256 at rest, TLS in transit, audited subprocessors) is intentionally aligned with HIPAA's Security Rule expectations even where formal coverage is not in place.
Responsible disclosure
If you believe you've found a security issue affecting earlier.me, please email security@earlier.me with a description of the issue and steps to reproduce. We commit to acknowledging your report within two business days, working with you in good faith on a remediation timeline, and not pursuing legal action against researchers acting in good faith under coordinated disclosure.
Questions?
Procurement teams, IT directors, and family members are all welcome to reach out. We'll answer specific questions about our controls, including ones not covered above, and provide additional documentation where it helps. Email hello@earlier.me.