Skip to main content


Antimatter strongly believes in transparency, so this section covers how Antimatter works internally. This can better help you understand where your data flows and under what conditions.

Data in Antimatter is contained within capsules that logically exist in a domain. The domain is where all of your configuration is stored (including encryption settings, policy, etc). A domain exists within an instance of Antimatter called a cell. The cell handles everything for a domain, including data classification and storage of encrypted Key Encryption Keys. Antimatter runs cells in several clouds, in several regions, so that you can use Antimatter's data control plane for high-performance low-latency services. Every cell is independent, which allows Antimatter to horizontally scale as required. A domain can peer with any other domain, regardless of what cell the peer is assigned to. In addition, domains can be transparently migrated between cells.

Antimatter's architecture
Antimatter's architecture

All of our libraries talk to, which is served by the Antimatter global tier. Similar to cells, we run instances of the global service set in multiple cloud regions, but unlike cells, all instances of the global tier have shared state. The global tier is only responsible for mapping from a domain to a cell. It does not handle or store any customer configuration or data other than the list of domains a user has added on (as this is cross-domain state tied to a particular email address, not tied to a domain).

One of the advantages of this architecture is that the Antimatter libraries and plugins "just work" regardless of where the cell handing their domains actually runs. You can interact with data in the US and not even know that the key material is kept in the EU. We even allow customers to start using Antimatter as a SaaS (using a cell we run) and transparently migrate their domains to a cell that they are running in their own infrastructure later. This lets you get the rapid adoption of SaaS but know that at any point you can move on-premise with no downtime. Contact Us for more information about running Antimatter cells on-premise.


At present, when you create a new domain, the cell is chosen for you. In the future, we will extend the API to permit you to specify where you would like your data to be hosted. Domains can also be moved between cells if required.

Flow of data

When encapsulating data, the flow of data is determined by which hooks are specified in the write and read contexts. The following hooks are run client-side and do not send data to Antimatter servers:

  • data-structure-classifier

The following hooks are run on Antimatter servers. We never store the data that is sent to us, but it does exist in memory during processing and inference:

  • regex-classifier
  • accurate-pii
  • fast-pii

A capsule not using a write context or read context with any of the above three hooks configured will not transmit any data. The only data sent to and from the Antimatter servers will be:

  • The capsule ID
  • Any manually supplied capsule and span tags (but not the data that has been tagged)
  • The key material for the capsule
  • The read parameters supplied during read (for the audit log)