we would rather show you how this works than ask for trust.

• we don't store your cloud credentials
• what we can and cannot see
• what we don't do
• subprocessors
• what we collect and how long we keep it
• a billing problem cannot lock you out
• open source split
• verify it yourself
• this marketing site
• reporting a problem

we don't store your cloud credentials

You never hand us a password, a key, or anything else that could be copied and used elsewhere. You grant access using your cloud's own mechanism for letting an outside party in: AssumeRole with an external id unique to your workspace on aws, lighthouse on azure, workload identity federation on google cloud. What we keep is your account number and a record of what you granted.

One thing we store is unencrypted and could be mistaken for a secret: the aws external id. On its own it opens nothing. Your account has to recognize our scanner as well, and both have to match before anything is allowed through — which is exactly why it is safe for it to sit there in plain text.

Revocation is on your side, takes effect immediately, and works one account at a time rather than all or nothing:

• delete the cloudformation stack on aws
• remove the lighthouse delegation on azure
• delete the workload identity pool on google cloud

On aws we ask for the two standard read-only permission sets, and then take some of it back: the permissions we grant ourselves explicitly forbid reading the contents of your secrets, your stored parameters, your encrypted data, your files in storage, and the rows in your databases. We can see that those things exist and how they are configured. We cannot open them.

There is no write access anywhere. All of this is in the template you apply yourself, so you can read it before you agree to it rather than take our word from this page.

What that read-only access is used for is on the coverage page.

what we can and cannot see

• credential-less cloud access (aws assumerole, azure lighthouse, gcp workload identity federation) — no customer cloud credentials are stored
• each workspace's data is separated by the database itself rather than by application code remembering to ask — the rule is enforced one level below anything we write
• each google cloud account you connect gets its own secret, unguessable identifier, and access granted for that account is rejected by every other one — including accounts belonging to other customers
• single sign-on cannot be switched on until a real administrator sign-in has completed through those exact settings, and switching it off is never blocked
• a log of what was done that can only be added to — each entry is sealed against the one before it, so a later edit or deletion cannot be hidden
• sign-in by emailed link — we store no passwords, so there are none to leak
• no third-party analytics or trackers; the application's content security policy allows one outside origin, the diagram library named in the table below
• your data is encrypted where it is stored, on top of the separation above; encrypting individual fields so that even our own application could not read them has been looked at and is not yet implemented

On the last line: encrypting the stored data protects you against a lost disk or a stolen copy of the database. Encrypting individual fields would keep them unreadable even to our own application. That is a real difference, and we have not built the second one.

what we don't do

• no analytics
• no third-party trackers
• no data sold, ever
• no ad tech

Those four are published as machine-readable settings, permanently off, and an automated test fails the application's build if any is ever switched on. The only outside code it loads at all is the library that draws the relationship diagrams. discocloud.io goes further: zero javascript, zero cookies.

subprocessors

The other companies that handle any of your data on our behalf, what each one does, and what it can see. This is the whole list. Paid plans are open, and our payment processor is on it: it takes the payment and is the merchant of record, so your card details go to it and never to us.

discocloud.io adds amazon s3 and amazon cloudfront, for static hosting and tls, and nothing else.

what we collect and how long we keep it

The audit log is kept for 365 days unless your organization chooses otherwise — anything from 30 days to a hundred years. Deleted accounts and workspaces are held for 14 days before they are removed for good. Sign-in links and sessions expire on their own schedules.

a billing problem cannot lock you out of your own data

If an organization ends up over its plan's cloud-account limit, it goes read-only until someone chooses which accounts to keep. Nothing is deleted while that is outstanding, and the ways out stay open the whole time: exporting your data, revoking sessions, removing an account, and deleting the organization outright all keep working. The limit exists to settle what is billable, not to hold anything hostage, and it is built so that it cannot.

open source split

The scanner engine — the component that assumes roles in your cloud and reads from it — is open source under the mit license at github.com/icearp/disco-cli. The web application, the guided connection flows, and the control plane are proprietary. The split is deliberate: the part you are being asked to trust with access to your infrastructure is the part you can read.

verify it yourself

• /.well-known/trust.json — subprocessors, data collected, retention, tracking flags, the content security policy, and the build sha
• /.well-known/security.txt — rfc 9116 contact and disclosure policy for this site. The application publishes its own at the same path.
• /livez reports the build sha of the running application. It should match build.sha in trust.json, and both should match a tagged commit in the repository.

this marketing site

discocloud.io is a set of static objects in amazon s3, served through cloudfront: no origin server, no database, no form handler. The bucket is private, and cloudfront reaches it through an origin access control that nothing else can use.

The response headers policy sends this content security policy:

default-src 'none'; base-uri 'none'; form-action 'none';
frame-ancestors 'none'; img-src 'self'; font-src 'self';
style-src 'self'; script-src 'none'; connect-src 'none';
manifest-src 'self'; upgrade-insecure-requests

The build fails if any javascript reaches the output directory, which is what lets the header say script-src 'none' rather than allow a hash or a nonce.

Cloudfront writes access logs to a bucket we own: client ip, user agent, the requested path and query string, timestamp, and the connection metadata /privacy lists in full. They are kept for 180 days, enforced by an s3 lifecycle rule rather than by intention, and queried only in aggregate — traffic volume, broken links, cache and latency health, crawler activity, and which tagged campaigns sent people. The queries are in the repository. The logs are never joined to an account, never enriched, and never leave that bucket.

reporting a problem

Email security@discocloud.io. We publish a security.txt because we read the mailbox behind it.