Hosted architecture
Staging is a second deployment of the same shape, holding no customer data, used to prove a release before production. Data boundary states which bytes cross each boundary and under which bound.
Providers that handle your data
These providers process customer data for the hosted product. Source volumes you register by reference stay in your own bucket and reach none of them except as the bounded reads Data boundary describes.Community deployments
Community runs as a single node on your infrastructure. Telemetry and billing are off. You operate the deployment and own its backups. Follow Self-host Community for installation and configuration.Access controls
- People on Team sign in through WorkOS AuthKit with email and password, Google or Microsoft. Enterprise uses SSO. Community is designed to sign in through its operator’s own OIDC identity provider, which the self-host stack requires. That stack does not include the Nitsor application, so a Community deployment has no Nitsor dashboard or sign-in today. People hold one of four account roles. Machines hold agent tokens of a service account, with the permissions it holds or fewer and an expiry 90 days after creation by default and 365 at most; only the SHA-256 of a token is stored.
- Inside a project, authority is one of four rungs held through grant rows; account owners and admins hold
adminon every project. Roles and provenance carries the tables. - Every event, Decision, grant and credential is account-scoped, and authorization runs before every write. A write that reaches guarded authorization records a Decision, every accepted event records a Ledger entry, and a read check refuses without recording one. A Dataset Version pin is written without an event, a Decision or a Ledger entry.
- Owners and admins submit storage keys through the dashboard or personal authority. Nitsor seals them with envelope encryption and binds access to the account, storage target, prefix and read or write role. Keys are never returned in public responses, events, logs or errors. Encryption at rest does not prevent the processor access described above: Vercel handles key submissions in transit, and Modal receives plaintext credentials for viewer-representation and Dataset Version jobs. Agent credentials cannot add or change keys or enable writing. New customer connections are read-only. Masks, stored viewer representations, uploads, model outputs and mask-bearing Dataset Version files need write access; Nitsor does not keep scan pixels or pixel-derived files as a fallback for a read-only connection. Customer-storage uploads also require an owner or admin to enable Accept uploads after the checks in storage connection setup pass.
- Every client requires HTTPS except to loopback.
- Events are append-only, commits are content-addressed, and a review verdict binds the hash it judged.
Retention and deletion
Nitsor never deletes source scans in customer storage. Hosted uploads default to Nitsor-managed storage; the owner can turn that destination off. Scans uploaded to Nitsor-managed storage are retained until the owner deletes them, subject to fair use. Export the scans and records you need before closing an account. Owner-directed deletion of managed uploads is separate from account and workspace record deletion; the 30-day account and workspace record deadline in the privacy policy’s retention section does not set a managed-scan deletion deadline. Control-plane records persist for the life of the project. A Dataset Version is tombstoned rather than hard-deleted: a 30-day grace, then cleanup of unshared, uncited artifacts, with the cleanup state visible on the tombstone. Retention windows for nonces, invitations and drafts are configurable per deployment; project-level retention is not published.Not published or not guaranteed
The following are not published or guaranteed:- service availability and escalation commitments;
- backup frequency, retention, restore procedure and tested recovery times;
- a cross-tenant isolation test result; tenancy is published as design;
- encryption-at-rest guarantees beyond the sealed customer-key handling described above, customer-held encryption keys and credential rotation commitments;
- operator access lists, vulnerability scanning cadence and incident-response commitments;
- storage and network records from a working deployment;
- that data is processed only in one country or region: dashboard and Dataset Version requests are first handled at the nearest Vercel or Cloudflare edge location;
- the server upgrade cadence and notice; the client compatibility policy is on the API page;
- certifications, regulated-use approval, medical-device status or compliance attestations. Export-control markings and clearances exist as a product mechanism.
Terms and privacy
Read the terms of service and privacy policy. Enterprise contract terms, including data processing, are agreed with sales.Next step
Compare Plans and billing, or contact sales to discuss Enterprise deployment, security and procurement requirements.| Plans | All plans |
|---|---|
| Last verified | 2026-09-30 |