security

Last updated 23 September 2026

Tissue runs untrusted code from many customers on shared infrastructure, so isolation and least privilege are built into the architecture rather than bolted on. This page is written in the order a security questionnaire asks its questions, so that it can be the answer. Where we do not do something, it says so.

01 Who we are

Tissue Systems, Inc. is a Delaware corporation operating from Washington State. The platform is run by a single named operator. We do not hold a SOC 2 report or an ISO 27001 certificate, and we will tell you that rather than let you find out from a questionnaire that comes back half empty. Everything below is what you can check for yourself or ask us to show you.

02 Where your data is

Everything runs on bare-metal and virtual servers we operate ourselves, on the providers named in section 03 of the Privacy Policy. Nothing is stored in a hyperscaler's account.

• Cells, databases (c3) and account data live in the United States: Los Angeles and Kansas City. Every c3 database has one home server in Los Angeles with a continuously shipped replica in Kansas City.
• Objects (g7) are stored in three copies across Los Angeles, Kansas City and Quebec, and a write is acknowledged only once two of the three have it.
• Mast pages, keys and delivery records live on a separate cluster in Chicago and Virginia, with a third replica and quorum witness in Germany. Pages are handed to Apple's push service from those hosts and nowhere else.
• Monitoring and staging run in Germany. Staging holds no customer data. Monitoring holds request counts and error rates, not request content.

We do not offer region pinning: an account cannot choose to keep its data in one of those locations only.

03 Encryption

In transit. All traffic to tissue.systems and to your Cells is served over TLS, with certificates issued automatically by Let's Encrypt. Traffic between our own servers crosses a WireGuard mesh, and the internal services behind the edge are reachable only over that mesh or from the host itself.

At rest. Vault bindings (type = "vault") are encrypted with a key held only in memory on the serving hosts and are injected into a Cell at dispatch time, so plaintext secrets never live in your deployed bundle or in a backup. API tokens are stored as SHA-256 hashes, passwords as salted hashes. Databases, objects and deployed code are stored on plain disks: we do not use full-disk encryption, because the provider already controls the hardware and the threat it would answer, a stolen drive, is one the providers handle physically. If your data needs to be unreadable on disk, encrypt it in your Cell before you store it.

04 Workload isolation

Every Cell runs inside its own V8 isolate: a lightweight, per-request sandbox with no ambient filesystem, network, or process access. A Cell can only reach the platform services it is explicitly bound to (c3 databases, g7 buckets, vault secrets), and only its own account's resources. Cells never talk to storage backends directly; all access is brokered by our internal services, and outbound connections from a Cell to our own infrastructure addresses are refused.

05 Authentication & access control

Passwords are hashed with a modern, salted algorithm. Sessions use short-lived, signed JWTs. API tokens (tok_…) carry an explicit, least-privilege scope allow-list across 25 scopes, so you can issue a token that can, for example, read Cells but not delete databases. Tokens can be revoked at any time from the dashboard.

You can turn on two-factor authentication with an authenticator app, backed by single-use recovery codes. Signing out every other session and CLI login is one action, and it takes effect on the API within fifteen seconds rather than waiting for those sessions to expire. We email you when a recovery code is spent, and unless you turn the notice off, when your account signs in from a device and network it has not been seen on in the last 30 days.

An account can have more than one person on it. Each membership records a role, owner, admin, or member, and that role caps what the member's sessions and tokens are permitted to do, so nobody can mint a token carrying a scope they do not hold themselves. Removing a member ends the sessions they hold and deletes the API tokens they issued on that account; moving a member to a narrower role re-cuts their tokens to what the new role allows. Every change of this kind is written to the account's activity record, which you can read in the dashboard or export.

Our own access. Production is reached over an operator-only overlay network with SSH keyed to one named person; there is no password login, and the one break-glass host that still answers on a public port takes that key only. Nobody at a hosting provider holds a login to our systems. We do not read customer content except to investigate abuse or a support request you have opened.

06 Backups & recovery

• The registry that holds accounts, Cell metadata, tokens and Mast records is a replicated cluster with a snapshot taken every hour into replicated object storage. Snapshots are kept on a tiered schedule for about a year.
• Every c3 database is backed up hourly into the same object storage, thinning to one copy a day and kept for 30 days, on top of the live replica described in section 02.
• Objects in g7 are not backed up separately: their three copies across three sites are the durability story, and a deleted object is gone.
• Deployed Cell code is kept on every serving edge, so the loss of one does not lose a deployment.

Restore procedures are scripted and have been run against real snapshots. A single serving edge failing does not take the platform offline; the loss of the Los Angeles site promotes each database's replica automatically once the nameservers agree the site is down.

07 Data retention & deletion

The full schedule is in section 05 of the Privacy Policy. In short: content stays until you delete it or close the account; per-request access logs, the account activity record and Mast page history are kept for 30 days; traffic statistics for 90 days at hourly resolution and 400 days daily. Closing an account starts a seven-day grace period, after which every table and bucket the account owns is deleted, on both the platform and the Mast cluster, and the auth record last. Backups age out on their own schedule and are never restored in part.

08 Monitoring & incident response

The fleet is monitored from a separate site with alerting on availability, error rates, certificate expiry, replication lag and DNS reachability, and an independent per-minute round trip through each serving edge. Alerts page the operator directly. Operational status is published at tissue.systems/status.

If we learn that your data was exposed to someone it should not have been, we will email the account's owners within 72 hours of confirming it with what we know, what we have done, and what you should do. Incidents that affect availability are written up on the status page.

09 Change management

• Infrastructure is managed as code, with changes reviewed before they are applied.
• Releases are built on a dedicated build server, signed on the operator's machine with a key the build server never held, and verified before a byte reaches a server.
• The runtime, its dependencies and the operating systems are updated on a regular schedule to pick up security fixes.

10 Sub-processors

The providers that handle your data on our behalf, with what each one sees, are listed in section 03 of the Privacy Policy. We will update that list before adding one. On Colony, on Sovereign and on the top Mast plan we sign our standard data processing agreement on request.

11 Your responsibilities

Security is shared. Keep your account credentials, API tokens and Mast channel keys secret, scope tokens narrowly, store your own secrets in vault bindings rather than in code, and keep your Cell's dependencies up to date.