What Squiddy processes
This page describes the data Squiddy holds, why it holds it, how long it keeps it, who else can reach it and where it runs. It is a description of how the software behaves, checked against the source it describes — not legal advice and not a data processing agreement.
What is held
| Category | Personal data | What it contains | Why | How long |
|---|---|---|---|---|
| Account identity | Yes | For each person with access: the subject identifier issued by the identity provider, an email address, a display name, their role, when they joined and when they were last seen. | Authenticating a person and deciding what they may do. The email address is also how invitations and service notices reach them. | For as long as the account has access to at least one organisation. When the last of a person's organisations is purged, their application record is removed with it. |
| Organisation | No | The organisation's slug and display name, its plan, the timestamps of its creation and last change, and — where they apply — the reason and author of a suspension or of a deletion request, plus how far it got through first-run setup. | Separating one customer's data from another's, deciding what a plan allows, and being able to say why an organisation is out of service. | Until the organisation is purged. A deletion request takes it out of service immediately and the data stays recoverable for the window below. |
| Configuration | No | Projects, environments, and each configuration with every one of its versions: the JSON body, whether a version is published, and who published or archived it and when. | This is the product. It is the data the service exists to store and to serve to a customer's applications. | Until the customer deletes it, or until the organisation is purged. Versions are kept so that a change can be rolled back. |
| API credentials | No | For each API key: its name, its non-secret prefix, the project and environment it belongs to, and when it was created, last used and revoked. The key itself is never stored — only a hash of it, which cannot be turned back into a usable credential. | Letting an application authenticate to the serving endpoint, and letting a customer see which of their keys is in use before revoking one. | Until revoked or until the organisation is purged. A revoked key's record is kept so that a past request in the audit trail can still be attributed. |
| Audit trail | Yes | One record per administrative action: what was done, to which resource, by which person (their subject identifier and email address), whether they acted as platform staff, and what changed. | Answering who changed what, which is both what a customer's own security review asks and how we investigate an incident. | Records older than the audit window are removed by a maintenance pass; the window is stated below. The trail is otherwise append-only — the application cannot delete from it at all. |
Retention windows
Both windows below are the values the code enforces, rendered from the constants that enforce them — this page cannot state a window the software does not apply.
An organisation whose deletion was requested, before it is purged for good: 30 days
A deletion request takes the organisation out of service at once and records when the purge becomes possible. Until then an administrator can restore it. The purge is a separate, explicit maintenance action — it does not run on a timer, so nothing is destroyed without someone asking.
_Declared in domain.TenantDeletionRetention._
Records in the audit trail: 365 days
A maintenance pass removes records older than the window, in batches, and reports how many it removed. It runs as maintenance and not as the application: the application role holds no delete privilege on the trail at all, which is what makes append-only a guarantee rather than a convention.
_Declared in domain.AuditLogRetention._
Who else can reach the data
- Database — no third party. PostgreSQL runs as part of the deployment, on its own storage. It is not a managed service and no third party administers it.
- Cache — no third party. Redis runs as part of the deployment and is optional: with no cache configured, every request is served from the database. It holds published configuration only, and never credentials or personal data.
- Identity provider — no third party. Zitadel is self-hosted, as a container in the deployment with a database of its own — it is not the vendor's hosted service. Account credentials are held there rather than by us, and they never reach Squiddy's database.
- Outbound email — a third party is involved. Squiddy sends invitations and service notices through an SMTP server named by configuration. Whoever operates that server necessarily handles the recipient's address and the message. Which provider that is has not been decided for a production deployment, so this document cannot name one; the operator of a given deployment is the one who can. With no SMTP host configured, no mail is sent at all.
- Telemetry — no third party. Traces can be exported to a collector of the operator's choosing, and are off unless an endpoint is configured. Spans carry procedure names and outcomes, not request bodies, tenant identifiers or credentials.
Where it runs
Squiddy is self-hostable, and that is the case this section can describe precisely. When you run it yourself, your data is where you run it: the database, the cache and the identity provider are all containers in your own deployment, and nothing leaves it except the mail you configure it to send and the traces you configure it to export.
For a hosted service, there is nothing to declare yet. No production deployment of Squiddy exists at the time of writing, so there is no region, no data-centre and no provider to name. A page claiming otherwise would be describing an intention.
Per-customer residency is not offered. Giving a customer their own database — which is what a choice of location would require — is designed but deliberately deferred until after launch. Until it ships, a hosted deployment would keep every customer's data in one place, and a promise of anything else would be one we could not keep.
What a customer can do about it
- Get a copy of everything. A single command exports one organisation's whole record as a JSON document: the organisation, its projects, environments, configurations and every version of them, its members and their roles, its API-key metadata, and its audit trail. No secret is included — not a key, not a hash of one, not session material.
- Leave, reversibly. Requesting deletion takes the organisation out of service immediately: the serving endpoint stops answering for it and its members lose access. Nothing is destroyed yet.
- Be erased for good. After the deletion window, a purge destroys the organisation's data — projects, environments, configurations, keys, memberships and its audit trail. What survives is a record that the purge happened: the organisation's slug and name, who asked and when, and how much was removed. It contains no personal data about the organisation's people, which is why it can be kept.
- Read the trail. Every administrative action on an organisation is visible to its own administrators, including actions taken by platform staff.
What is not offered
- A data processing agreement. This page is a description, not a contract, and no DPA is on offer here.
- A legal review. Nothing on this page has been reviewed by a lawyer. It was written by reading the source code.
- An external penetration test. None has been carried out. An internal security review of the code has.
- Per-customer retention windows. The windows above apply to every organisation alike and cannot be shortened or extended per customer.
- Archiving before deletion. When data is removed it is removed; it is not moved to cold storage first. The export below is how a customer keeps their own copy.
- A choice of data location. See the residency section above.