Deployment
Built to pass your security review before the meeting.
This page exists so that your security and legal teams can read it without you in the room. It states what Noveam contacts, what it stores, how it authenticates, and where its limits are.
Appliance, or hosted
| Aspect | BlackBox appliance | Hosted |
|---|---|---|
| Where it runs | Your hardware, your network | Operated on your behalf |
| Tenancy | Single tenant | One isolated database per tenant, resolved by subdomain |
| Network | Air-gappable | Standard internet-facing |
| Identity | Your OIDC provider | Your OIDC provider, with provisioning handled for you |
| Data | Your disk | Isolated per tenant, exportable at any time |
| Primary model | Yes | Entry point |
The definitive list
Nothing, unless you configured it. There is no vendor endpoint to switch off, because there is none to begin with.
- No telemetry, no analytics, no crash reporting, no call-home. None of it is present in the code, in any form.
- No CDN. Scripts and all eight font files are served from the host you installed Noveam on.
- No external database, no message broker, no cache tier. Storage is SQLite, one database file per tenant, in write-ahead-logging mode.
- Licensing is offline. No activation server, no hardware binding.
- The one outbound call the product can make is OIDC discovery against your identity provider, at an address you configure. On an air-gapped appliance with local accounts, it is absent.
How this is held in place. A browser test fails the build on any request to a host outside the machine, and on any content security policy violation. Stated limit: that external-request assertion covers the dashboard route, not yet every route in the product.
The content security policy, quoted exactly
default-src 'self'; script-src 'self'; style-src 'self'; connect-src 'self'No unsafe-inline. No unsafe-eval. That exact string is asserted by a Rust test, so it cannot drift quietly across a release.
Your identity provider, your rules
- OIDC , Authorization Code flow with PKCE (S256) and a verified nonce.
- Per-tenant issuer isolation on the hosted model: a token minted for one tenant cannot be replayed against another.
- Identity-provider secret material is envelope-encrypted , AES-256-GCM, with typed additional authenticated data so a ciphertext cannot be moved between fields.
- CSRF protection and server-side sessions.
- Step-up re-authentication on privileged operations, and a denied step-up is written to the audit log.
Limits, stated plainly
- Roles are administrator and user, plus an instance-level superadmin flag, enforced fail-closed. There are no per-object permissions.
- No SCIM. User provisioning is not automated.
- OIDC is standards-based and validated against a mock provider and against FusionAuth. There is no certified test matrix for any specific commercial identity provider.
- The database is not encrypted at rest. Disk-level or volume-level encryption is your responsibility. What Noveam encrypts is the identity-provider secret material.
One process, one port, one file
Noveam ships as one binary plus its static/ directory. One process, one port. No runtime to install, no cluster to stand up, no external services to operate.
Your model is a SQLite database file per tenant. Back it up by copying it. Move it by moving it. Export it as CSV, JSON, XLSX or OSCAL component-definition JSON. There is no proprietary cloud state you can be stranded in.
The product interface is English
This site is available in English and Romanian. The product interface is English only. We would rather you read that here than discover it in the demo.