Hydrate Enterprise compliance one-pager
This page is written for procurement, security review, and legal review. It describes the current product posture, not a future managed service.
Hydrate at a glance
Hydrate is local-first by design. Free, Pro, Team, and self-hosted Enterprise deployments do not send customer code, session memory, extracted facts, or canon to a Hydrate-operated SaaS. The vendor never receives customer code or memory unless the customer explicitly opts in to a future managed Sync Hub product. No managed Sync Hub is available today.
The Enterprise Sync Hub is source-available under mutual NDA today and offered under a commercial-use licence. The roadmap intent is to publish the Sync Hub under an open-source licence after launch once packaging, support boundaries, and abuse controls are stable.
The core product is written in Go using the standard library where practical. Local storage uses SQLite. The default install makes no external network calls for memory injection or runtime context retrieval. Customers can verify the offline posture with:
hydrate doctor --offline-checkData handling matrix
| Data category | Hydrate Free / Pro | Hydrate Team | Hydrate Enterprise |
|---|---|---|---|
| Source code | Lives in the developer’s working tree and git remotes. Hydrate does not upload source code to vendor servers. Readable by the local developer and existing repo permissions. Retention follows the customer’s git policy. | Lives in the team’s git repositories. Hydrate does not host source code. Readable by repo-authorised users. Retention follows the customer’s git policy. | Lives in customer repositories and developer workstations. The self-hosted Sync Hub does not need full source code. Readable by customer-authorised users only. Retention follows customer policy. |
| Session transcripts | Free: local disk only. Pro: local disk; post-scrub narrative may be sent to the customer’s configured LLM provider for extraction. Vendor servers receive none. Local default retention is 90 days, configurable/deletable by the user. | Local developer disks for individual sessions; shared team canon lives in git. Vendor servers receive none. Retention follows local settings and git history. | Customer perimeter only: developer workstations and, where configured, the self-hosted Sync Hub. Readable by customer-authorised project/admin roles. Default retention is 90 days unless changed by customer policy. |
| Extracted facts | Local SQLite on the developer workstation. Readable by the local user and local Hydrate process. Facts decay over time and can be deleted with Hydrate commands. Vendor servers receive none. | Local SQLite plus team-approved canon/facts committed to the team’s git repo. Readable by repo-authorised users. Retention follows local settings and git history. | Self-hosted Sync Hub and developer workstations inside customer perimeter. Readable by customer-authorised users and admins. Retention is customer-configurable per project. |
| Licence identity | Free: none beyond install artefacts. Pro: licence token may be validated by Hydrate licensing infrastructure; no session content attached. Retention follows billing/licence records. | Licence or entitlement identity for team seats may be validated by Hydrate licensing infrastructure. No session content attached. Retention follows billing/licence records. | Enterprise licence identity and seat entitlement may be validated during installation or renewal. Runtime memory does not leave the perimeter. Retention follows contract and billing records. |
| Telemetry | None by default for runtime memory features. Static website/CDN logs may exist when downloading installers. | None by default for runtime memory features. Static website/CDN logs may exist when downloading installers. | None from the Sync Hub to Hydrate by default. Customer may configure local Prometheus/SIEM telemetry inside the perimeter. |
| Audit logs | Local CLI actions may be logged locally only. No centralized Hydrate-hosted audit log. | Git history provides reviewability for team canon changes; no Hydrate-hosted audit log. | Sync Hub audit database inside the customer perimeter. Readable by customer admins/security auditors. Default retention is 90 days; configurable per project and exportable to customer SIEM. |
Compliance posture
| Framework / law | Current posture | Notes |
|---|---|---|
| SOC 2 Type II | In progress (target: TBD) | Hydrate has a published SOC 2 controls self-assessment and security policies, but no independent Type II attestation yet. Documentation is available under MNDA for Enterprise buyers. |
| ISO 27001 | In progress (target: TBD) | Controls are mapped in the compliance documentation. Hydrate is not ISO 27001 certified today. |
| GDPR | Documentation available under MNDA | Local-first and self-hosted architecture minimizes processor scope. Data subject request handling, retention, and right-to-erasure behaviour are documented. Customer remains controller for self-hosted Enterprise deployments. |
| CCPA | Documentation available under MNDA | Hydrate does not sell personal information. For self-hosted Enterprise, customer controls data collection, access, deletion, and retention inside its perimeter. |
| EU AI Act (Aug 2026) | Documentation available under MNDA | Hydrate is developer memory infrastructure, not an autonomous high-risk AI system by itself. Customers remain responsible for classification of their AI use cases and downstream model use. |
| HIPAA | Not applicable by default | Hydrate is not offered as a HIPAA Business Associate today. Do not put PHI into Hydrate unless a specific Enterprise agreement and customer-controlled deployment controls cover that use. |
| PCI-DSS | Not applicable to Hydrate runtime | Hydrate does not process cardholder data in the runtime product. Payment processor assessment is handled separately when billing provider selection is finalized. Customers should not store PAN or PCI-sensitive authentication data in session memory. |
Vulnerability disclosure
Security researchers should report vulnerabilities to [email protected]. Hydrate acknowledges reports within 48 hours and provides a substantive response within 10 business days.
Hydrate does not take legal action against researchers acting in good faith and following coordinated disclosure. CVSS score and disclosure timeline are agreed with the reporter before public disclosure.
Critical CVEs are patched within 7 days of disclosure. High CVEs are patched within 30 days. Go dependencies are scanned with govulncheck in CI, and known vulnerabilities block release unless formally risk-accepted with a written rationale.
Sub-processors
For self-hosted Enterprise deployments, there are no Hydrate runtime sub-processors. The Sync Hub runs entirely inside the customer perimeter. Customer-selected LLM providers, identity providers, storage providers, SIEMs, cloud platforms, and observability systems are the customer’s processors or sub-processors, not Hydrate’s.
For Hydrate-operated services adjacent to the product, current vendors include:
| Vendor | Role | Customer memory or source code? |
|---|---|---|
| Cloudflare | Static assets for gethydrate.dev, Pages deployment, and licence-key validation path. | No. |
| GitHub | Source hosting, CI/CD, release artefact publishing, and encrypted release secrets. | No customer session memory. |
| OpenAI / Anthropic | Optional customer-configured LLM providers for extraction in some non-Enterprise/BYOK configurations. | Only if the customer configures that provider; governed by the customer’s provider terms/DPA. |
If Hydrate later offers a managed Sync Hub, the sub-processor list will be updated before launch and included in the Enterprise DPA. There is no managed Sync Hub product today.