Data retention & regions
Jutsu organizes your data so it stays queryable while it is operationally useful, then archives older data to lower-cost storage — and it runs in more than one region so you can keep data closer to where you operate.
Data lifecycle
Event and alert data flows into per-organization weekly OpenSearch indices (the pipeline writes to indices following an org-{organizationId}-…-events pattern). Time-bucketed indices keep recent data fast to search and make whole time ranges easy to age out or roll over as a unit.
A dedicated data-archiver service handles the long-term side of the lifecycle. It runs on a nightly schedule (a UTC cron, by default just after midnight) and tiers stale audit aggregates out of the hot Postgres store into object storage (S3), removing the rows from Postgres once they are archived. The effect is a two-tier model: recent data stays in the operational stores for fast access, and older data is preserved in cheaper, durable storage.
Exact retention windows — how long data stays in hot indices before it is rolled over or archived, and how long archives are kept — are configured per deployment (for example, the archiver's schedule and target bucket are environment settings). Confirm the retention periods that apply to your data against your deployment.
Regional deployments
Jutsu's manifests are organized as a shared base plus one overlay per deployment, which lets the same stack run in different regions:
| Deployment | Region | Notes |
|---|---|---|
| Primary | us-east1 | The default production deployment. |
| India | asia-south1 | A separate deployment in the India region. |
Each deployment runs in its own isolated namespace with its own datastores, so data created in one region's deployment lives in that region's stores.
Data residency
Because each regional deployment keeps its own data, where your organization is provisioned determines where its events, alerts, cases, and archives reside. If your operations or regulatory obligations require data to stay in a particular jurisdiction — for example within India — provisioning into the matching regional deployment keeps that data in-region.
Data residency depends on which regional deployment your organization is provisioned into and on how your operator configures managed datastores and archive buckets. If you have a specific residency requirement, confirm the region and the storage locations with your deployment operator before onboarding data.