> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nitsor.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Nitsor is a pre-release product. Every page in this documentation carries an availability status in its frontmatter (`availability`) and, as the first element of its body, a link labelled `Available now`, `Limited design-partner access`, or `Planned - not available yet`. That label is binding: it says whether a reader can use the behaviour the page describes.
> A page written in the present tense is not a claim that the behaviour ships. Where the availability label says `Planned - not available yet`, the page describes a target contract and there is no runnable product, screen, command, or public interface behind it.
> Every readiness claim this documentation makes lives on the Product status page. If any statement elsewhere disagrees with the capability status matrix on that page, the matrix is correct.
> Reading this documentation grants no product access and no permission. No agent can create or approve a Nitsor release.

# Deployment and security

> Separate the public site's verified controls from planned product deployment, security, identity, compliance, and self-hosting capabilities.

<a className="nit-availability" data-availability="target-contract" href="/product-status#status-definitions" aria-label="Planned — not available yet. Read the status definitions."><span aria-hidden="true" className="nit-availability__dot" />Planned — not available yet</a>

**Status: Planned — not available yet.** This page is a target contract: a precise description of the deployment and security evidence a future Nitsor product should provide. It also lists a few controls verified for the public site.

## 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.

| Header                    | What it controls                                                                                          | How it is verified                                    |
| ------------------------- | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- |
| `Content-Security-Policy` | Which sources a browser is allowed to load content from, so injected third-party content is refused.      | Automated test of the header sent by the public site. |
| `Referrer-Policy`         | How much information about the page you came from is passed on when you follow a link away from the site. | Automated test of the header sent by the public site. |
| `X-Content-Type-Options`  | Prevents the browser from guessing a file's type instead of trusting the type the site declared.          | Automated test of the header sent by the public site. |
| `X-Frame-Options`         | Prevents another website from embedding Nitsor pages inside a frame on its own page.                      | Automated test of the header sent by the public site. |

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.

| Deployment commitment | What a buyer would need to see                                                                 | Current status |
| --------------------- | ---------------------------------------------------------------------------------------------- | -------------- |
| Hosting architecture  | Where the service runs, how tenants are separated, and which components hold customer records. | Not published  |
| Regional availability | The regions a customer may choose and where records stay.                                      | Not published  |
| Service levels        | Availability, support response, and escalation commitments.                                    | Not published  |
| Backup contract       | Backup frequency, retention, restore procedure, and tested recovery times.                     | Not published  |
| Upgrade policy        | Release cadence, notice periods, compatibility rules, and rollback.                            | Not published  |
| General availability  | The date the product becomes generally purchasable and supported.                              | Not published  |

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.

| Area                              | Question to ask                                                                          | Acceptable evidence                                                                   | Current status |
| --------------------------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | -------------- |
| System and data-flow boundaries   | Which components hold or move customer data, and where does each boundary sit?           | A current architecture and data-flow description reviewed against the running system. | Not published  |
| Tenancy and authorization         | How is one customer's data kept unreachable by another customer or an unauthorized user? | Isolation design plus tests that demonstrate a denied cross-tenant request.           | Not published  |
| Credential and key handling       | Where are secrets stored, who can read them, and how are they rotated?                   | A secret-management description and evidence of a completed rotation.                 | Not published  |
| Encryption                        | What is encrypted while travelling over a network and while stored?                      | Configuration evidence for both cases, with the key owner named.                      | Not published  |
| Integrity of history records      | Can decision and version history be altered after the fact, and who could do it?         | An append-only or tamper-evidence design plus an access list.                         | Not published  |
| Vulnerability and dependency care | How are known vulnerabilities in the product and its dependencies found and fixed?       | A scanning and patching process with recent, dated results.                           | Not published  |
| Incident response                 | What happens when a security incident occurs, and when are customers told?               | A written response plan with notification timelines and a rehearsal record.           | Not published  |
| Backup, retention, and deletion   | How is data backed up, how long is it kept, and how is deletion confirmed?               | Retention and deletion policies plus a tested restore.                                | Not published  |
| Deployment and upgrade paths      | How does a change reach production, and who approves it?                                 | A change-control description and evidence that upgrades and rollbacks were run.       | Not published  |
| Regulatory and customer controls  | Which external regulations or customer-specific controls apply, and who signs off?       | A mapping of applicable controls to product behavior, reviewed by your own counsel.   | Not published  |

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.

| Criterion                  | What a pass requires                                                                    | Current status    |
| -------------------------- | --------------------------------------------------------------------------------------- | ----------------- |
| Versioned package          | A named, numbered release you can obtain again later and pin to.                        | Not available yet |
| Integrity verification     | A way to confirm the package you received is exactly the one that was published.        | Not available yet |
| Dependency list            | A complete list of every other component the product needs to run.                      | Not published     |
| Identity                   | A documented way to connect your own sign-in system and manage accounts over time.      | Not available yet |
| Secrets handling           | Documented storage, access, and rotation of passwords, keys, and tokens.                | Not published     |
| Storage and backup         | Defined storage requirements plus backup and restore procedures you can test.           | Not published     |
| Upgrade and rollback       | Steps to move to a newer version and to return safely to the previous one.              | Not available yet |
| Logs and metrics           | Operational signals sufficient to tell whether the system is healthy and why it is not. | Not published     |
| Licence                    | Settled terms stating what you may run, modify, and redistribute.                       | Not established   |
| End-to-end deployment test | A test that installs the product from scratch and proves a real workflow completes.     | Not available yet |

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](/reference/self-host) 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](/guides/design-partner-onboarding).

<table className="nit-page-details" aria-label="Page details">
  <tbody>
    <tr><th scope="row">Outcome</th><td>Build an evidence checklist without assuming a production deployment option exists.</td></tr>
    <tr><th scope="row">Availability</th><td>Planned — not available yet</td></tr>
    <tr><th scope="row">Audience</th><td>Software and security teams, CTOs, Heads of AI and Software, Operational decision-makers</td></tr>
    <tr><th scope="row">Prerequisites</th><td>Read Product status; Identify your hosting, identity, and compliance requirements</td></tr>
    <tr><th scope="row">Last verified</th><td>2026-08-23</td></tr>
  </tbody>
</table>