Sovereign Ithura
Ithura ships as a single Go binary with a documented, self-hostable stack. The sovereign guides in this section are for the person answering procurement, compliance, and security review questions: what data lives where, what Ithura's architecture guarantees, and how to fill in the vendor questionnaire.
Every answer here is written from first-hand reading of the code and the
deployment topology. Where an answer depends on how you run Ithura, the guide
says so explicitly (self-hosted on your own hardware, self-hosted on a rented
VM, or the managed EU offering at ithura.com).
Who this section is for
- Procurement and security review teams filling in NIS2, DORA, ISO 27001, SOC 2, or SIG-Lite questionnaires that name Ithura as an ICT service.
- Legal counsel drafting or reviewing the Data Processing Agreement.
- Ops and platform teams running Ithura on their own infrastructure and wanting the audit-ready statements about encryption, backups, access controls, and data residency.
The one-page pitch
Ithura is a single Go binary, an accompanying React SPA served as static assets, a Postgres database, a Valkey (Redis-protocol) cache, a RustFS S3 object store, a Yjs collaboration sidecar, and a LiveKit media server. That is the entire runtime. No hosted analytics, no telemetry, no external error reporting, no third-party feature-flag service, no vendor-managed queue. The list of outbound network calls Ithura makes on its own is empty. Every call to a third party (Slack webhook, GitHub OAuth, Stripe, an SMTP relay you configured) happens because your admins wired it up in the settings.
That property is the sovereign story. It is not marketing, it is a direct consequence of the single-binary architecture, and it is what makes the compliance answers below easy to give.
Guides
| Guide | What it covers |
|---|---|
| Data residency | Where data lives in each deployment mode, what a self-hosted install controls, sub-processors under the managed EU option, and how to answer the "where is my data" question in one line |
| GDPR | Roles (controller vs processor), Article 30 records of processing, Article 32 security-of-processing measures Ithura implements, data-subject rights, sub-processor list, and international transfers |
| NIS2 | The ten cybersecurity risk-management measures NIS2 Article 21 requires, mapped to Ithura features and configuration |
| DORA | ICT-service-provider assessment for financial-services customers: register-of-information fields, incident-reporting cooperation, testing support, and exit-strategy guarantees |
| Data Processing Agreement (template) | A fill-in-the-blanks DPA template you can adapt when Ithura acts as your processor or when you resell a self-hosted instance to your own customers |
| Air-gap install | Running Ithura with zero outbound internet access: images and SBOMs to bring in, env vars to unset, and a shell verification checklist |
| SBOM and image signatures | Signed SPDX SBOMs generated per release with syft + cosign, how to verify them, how to download without cosign, how to generate locally |
| Audit log CSV export | Streaming CSV export of the workspace audit log with the same filters as the JSON list endpoint, column contract, and SIEM-ingest recipes |
Not legal advice
These guides describe what Ithura's code does and how to configure it to meet each regulation's requirements. They are written by Ithura's own engineering team for reviewers who want vendor-provided facts. They are not a substitute for advice from your own legal counsel or a qualified compliance auditor.