Data storage policy.

01Where data lives

Customer data is hosted on DigitalOcean infrastructure in three regions: SFO3 (San Francisco), NYC3 (New York), and FRA1 (Frankfurt). Each workspace is pinned to one of these regions at signup and the data does not leave that region for any reason without explicit customer action.

AI inference runs on Message-owned GPU hardware co-located in Houston, Texas. The hardware is on the same Tailscale tailnet as the production application tier, never exposed to the public internet. Customers can disable Message-owned AI inference and run only on third-party fallback (DeepInfra, Featherless) if they prefer; the inverse, locking inference to Message-owned hardware with no third-party fallback, is available to Enterprise.

The marketing site (message.com) and KB-hosting sites for AI grounding are served by Cloudflare-fronted CDN. No Personal Data lives in that layer.

02Storage classes

Data lives in one of three storage classes, chosen automatically based on age and access pattern:

• Hot. Postgres clusters (Managed Postgres with a primary and a read replica per region). Holds active conversations, contacts, tickets, calls in flight, agent state, RBAC, billing, audit log, and KB embeddings (pgvector). Sub-50ms read latency.
• Warm. DO Spaces object storage (S3-compatible). Holds file uploads (chat attachments, ticket attachments), call recordings, exported transcripts, KB source documents, and on-demand customer exports.
• Cold. Encrypted off-site backup archives. Holds nightly full-cluster snapshots and incremental WAL archives. Restorable within hours, not minutes.

There is no "tape" tier. Cold storage uses an S3-compatible store with the same encryption regime as hot and warm.

03Retention defaults

Retention is set per category of data. Defaults can be tightened by the customer in Settings > Data > Retention. Enterprise can also request custom retention windows (longer or shorter, including legal hold).

When a retention window expires, the affected rows are deleted from the hot tier and the corresponding object-storage entries are removed. Backups containing the data are aged out on the standard rolling schedule (typically within 30 days of expiry).

04Data minimization

We do not store more than we need to operate the service. Concretely:

• We do not log message bodies in application telemetry. Sentry stack traces are PII-scrubbed at ingest.
• We do not retain inference payloads beyond the request lifecycle. AI completions are streamed back to the client; the request body is not persisted by the inference layer.
• We do not maintain shadow copies of customer data in support tools. Support staff query the same production database under audit, not a copy.
• We do not enrich customer Personal Data with third-party data brokers. We do not buy data; we do not sell data.

Where we hold derived data (embeddings, aggregate counts, search indexes), it is rebuilt from source on deletion of the underlying records.

05Enterprise custom retention

Enterprise customers can negotiate retention windows beyond the defaults, in either direction:

• Longer windows for regulated industries (financial services, healthcare, public sector). Maximum is bounded by storage cost and engineering tractability; we are happy to discuss 7-year audit log retention.
• Shorter windows for highly sensitive workloads where the customer wants conversation bodies purged within hours of close.
• Legal hold: a switch that prevents any retention-driven deletion for a named subset of conversations until the hold is released.
• Per-channel overrides: different retention for chat vs phone vs ticket inside the same workspace.

These are configured in writing as part of the Enterprise order form. Talk to [email protected].

06Hardware security

DigitalOcean infrastructure inherits the physical security controls of their SOC 2 Type II-attested data centers. Disk encryption is on by default on every block device underpinning a Managed Postgres cluster or DO Spaces bucket.

The Message-owned AI inference hardware in Houston is racked in a colocation facility with 24/7 staffed access control, biometric entry, surveillance, and locked racks. The host operating system runs full-disk encryption (LUKS) with keys held outside the data center.

Office hardware used by Message staff (laptops, phones) is enrolled in MDM with disk encryption, screen-lock enforcement, automatic OS updates, and remote-wipe capability. No customer data is allowed on a personal device.

07Decommissioning and media destruction

When hardware is retired, we follow NIST SP 800-88 Rev. 1 media sanitization guidelines:

• Cloud storage: cryptographic erasure of the data-encryption keys, followed by the cloud provider's standard block reclamation.
• Self-hosted hardware: cryptographic erasure of LUKS keys, then a multi-pass overwrite of the underlying media. Drives that fail the wipe step are physically destroyed (shredded or degaussed) by the colocation facility and a certificate of destruction is retained.
• Office hardware: remote wipe via MDM, followed by donation or destruction. Drives that previously stored unencrypted data (none in current inventory) are physically destroyed.

A media destruction certificate is available on request from [email protected] for assets that touched customer data.

08Backups

The backup regime is:

• Postgres point-in-time recovery (PITR) within a rolling 30-day window. Restore granularity is to the second.
• Hourly full-cluster snapshots retained for 30 days.
• Daily snapshots replicated to a separate region within the same continental zone for disaster recovery.
• DO Spaces buckets are versioned; deletes leave a recoverable shadow for 30 days.
• Backups are encrypted with KMS-managed keys, separate from the keys protecting production data.

A restore drill runs monthly into a clean environment, with the resulting database verified against checksums of the source. Stale backups never get exercised; we treat backups that have not been restored as if they do not exist.

Restore time objective (RTO) is 4 hours for a full single-region disaster. Restore point objective (RPO) is 15 minutes.

09Deletion on customer request

Customers can delete data on three levels:

• Per-record. Any record in the dashboard has a delete action. The delete is immediate from the hot tier and the corresponding object-storage entries are scheduled for removal within 24 hours.
• End-user erasure (GDPR Article 17). Customers can action an end-user's right to be forgotten from the dashboard. Affected PII is purged from the hot tier within 30 days, including embeddings derived from that PII.
• Workspace deletion. Closing the workspace triggers deletion of all workspace data within 30 days. A 14-day soft-delete window allows recovery before the irreversible purge.

Backups containing already-deleted data are aged out on the standard rolling schedule. Within 30 days of the deletion event, the data no longer exists in any tier under our control, except where retention is required by law (for example, retained audit logs for security-relevant events).

10Contact

Questions about storage location, retention defaults, custom retention windows, or specific compliance regimes should go to [email protected]. We respond from a named human within two business days.

Security-specific questions (encryption, hardware destruction, restore procedures) go to [email protected].