Verified for the public site
The public site configures browser security headers that limit which resources a page may load, how referral information is shared, whether browsers may guess file types, and whether another site may place Nitsor in a frame. A response header is a short instruction the website sends alongside each page to tell the browser how to treat it. Available now. The website sends each of the four headers below on public pages, and an automated test checks that they are present and correctly set.
Automated documentation tests also check that public content comes from the public-site folder and scan for known private markers.
These controls apply to the public site. They are not evidence for a future dashboard, product-data storage or processing, storage integration, identity system, or self-hosted deployment.
Product deployment status
Planned — not available yet. Nothing in this table describes a service you can buy or run today. Each row records a commitment a production offering would have to publish, and the honest status of that commitment right now.
Nitsor is not operated as a hosted service you can sign up for today, and no self-hosting package, image, installer, deployment file, or upgrade path is published. An intention to be deployable or open does not satisfy an operational acceptance test.
Identity and permissions
The intended product requires separate human and machine identities, limited permissions, attributable actions, and protected decisions. No public sign-in setup, organization model, session behavior, or permission table is available today. A provider name in draft legal text would not make that provider a permanent architecture commitment.Security and compliance questions
Planned — not available yet. Use this table as the list of asks for a future security review. The questions are ready to send; the answers are not published, so treat every current status below as an open item rather than a reassurance.
No certification, regulated-use approval, medical-device status, or compliance attestation is claimed.
Self-hosting acceptance gate
Planned — not available yet. Self-hosting means running Nitsor on infrastructure your own team controls. Before calling any future option self-hostable, require all ten criteria below to pass. None of them passes today, so the honest reading of this table is that a self-host offering does not exist yet — not that it is nearly ready.
A draft configuration or a container that starts one dependency does not prove that the product can be self-hosted. Some low-level bootstrap mechanics are implemented and tested; Self-host mechanics describes exactly what they do and do not start.
Legal status
The public terms, privacy, and cookie pages are drafts awaiting counsel review. They are not binding policies, a data-processing agreement, or procurement evidence.Common mistakes and limits
- Security headers do not protect a private file that was accidentally published.
- Open-source intent is not a settled licence.
- A local build is not a supported self-hosted deployment.
- A simulated security review is not a penetration test or compliance audit.
- A target identity model is not proof of tenant isolation.
Next step
Turn your deployment and security requirements into pass/fail evidence requests, then include them in the charter described in Design-partner onboarding.| Outcome | Build an evidence checklist without assuming a production deployment option exists. |
|---|---|
| Availability | Planned — not available yet |
| Audience | Software and security teams, CTOs, Heads of AI and Software, Operational decision-makers |
| Prerequisites | Read Product status; Identify your hosting, identity, and compliance requirements |
| Last verified | 2026-08-23 |