Our posture on security
NOSIBLE security is built around dedicated infrastructure, hardened servers, controlled access, replication, and operational controls. The search index needs to stay available, consistent, recoverable, and protected from unwanted access under risk-based security standards such as GDPR Article 32.
- NOSIBLE runs on dedicated OVHcloud bare-metal servers in France, Germany, and the UK.
- Servers run hardened Ubuntu Pro with controlled access and recorded activity.
- Indexes are backed up to S3 and geographically replicated, with recovery paths kept separate.
- Replication uses write-ahead logs, replica replay, and checksum validation.
- Public API requests pass through a secure gateway and require API-key authentication, authorization, rate-limit checks, and validated inputs.
- API traffic is encrypted in transit. Bulk Search and Time Search results are delivered as encrypted JSON files.
- NOSIBLE does not log API request or response payloads on normal endpoints; limited usage logs are retained for 24 hours.
- Server access is controlled through Tailscale, MFA, and separated admin permissions.
- NOSIBLE uses firewalls, endpoint security, antivirus, TLS, and DDoS protection.
- Website verification checks security.txt, Google Web Risk, blocklists, and redirects.
- NOSIBLE is in the early stages of SOC 2 readiness with Vanta and Cognisys. No independent examination or report has been completed.
Security starts with dedicated infrastructure and controlled access
NOSIBLE runs on dedicated bare-metal servers hosted by OVHcloud in France, Germany, and the UK. They run hardened Ubuntu Pro, sit behind firewalls and DDoS protection, and are administratively accessible only through Tailscale with MFA. Access and activity are recorded and auditable.
The system is split into web discovery, web crawling, and web indexing. Discovery finds websites and URLs. Crawling retrieves HTML from whitelisted websites through Bright Data proxies and converts it into structured data. Raw HTML and parsed JSON are stored in Wasabi S3. Indexing streams structured data into lexical and vector indexes on OVH servers, using dedicated RunPod or Hugging Face GPU endpoints for embeddings. NOSIBLE World is a structured database distilled from the index.
Index resilience is handled through backups and replication
| Area | NOSIBLE position |
|---|---|
| Primary hosting | Dedicated OVHcloud bare-metal servers in France, Germany, and the UK. |
| Backups | Indexes are backed up to S3 regularly. |
| Replication | The index is geographically replicated using write-ahead logs shipped from primary indexes to replica indexes. |
| Consistency checks | Replica indexes replay committed changes and use checksums to verify consistency after updates. |
| Server hardening | Servers run Ubuntu Pro with full hardening enabled. |
| Access control | Server access is limited through Tailscale, with access and activity recorded. |
| Security program | NOSIBLE is in the early stages of SOC 2 readiness with Vanta and Cognisys. Policies are in place, vendors are mapped, and controls are being implemented. No independent examination or report has been completed. |
Operational controls reduce intrusion and abuse risk
Public API requests are proxied into the index through a secure gateway. Every request is authenticated with an API key and authorized against that key's permissions and rate limits. Inputs are validated against Pydantic models, rate-limit breaches return HTTP 429 responses, and retrieval endpoints are monitored for abuse.
Behind the gateway, NOSIBLE uses firewalls, endpoint security, antivirus, anti-malware, multi-factor authentication, high-security Gmail settings, TLS encryption, DDoS protection, and hardened Ubuntu Pro. Administrative access requires Tailscale with MFA and is recorded and auditable. Secrets and per-key encryption keys are stored in Google Secret Manager. U.S. security enforcement has focused on gaps between promised controls and actual controls, including FTC v. Wyndham, LabMD v. FTC, FTC Chegg, and FTC Zoom.
Common security questions
Where are NOSIBLE servers hosted?
NOSIBLE runs on dedicated OVHcloud bare-metal servers in France, Germany, and the UK rather than on multi-tenant cloud compute. NOSIBLE also buys load balancers and networking products from OVHcloud. The core index benefits from predictable compute, storage, network behavior, and clearer operational control.
How is NOSIBLE architected?
NOSIBLE has three major systems: web discovery, web crawling, and web indexing. Discovery finds websites and URLs. Crawling retrieves HTML from whitelisted websites through Bright Data proxies and converts it into structured data. Raw HTML and parsed JSON are stored in Wasabi S3. Indexing streams structured data into lexical and vector indexes on dedicated OVHcloud servers, with embeddings supplied by dedicated RunPod or Hugging Face GPU endpoints. NOSIBLE World is a structured database distilled from the index.
What deployment options does NOSIBLE support?
NOSIBLE supports three deployment options: structured flat files delivered through S3 with no API or executable code; an on-premises Docker container that connects to S3 and exposes an internal search API; and managed Web API access.
How are NOSIBLE APIs authenticated and authorized?
NOSIBLE APIs use API keys. OAuth 2.0 and mTLS are not currently supported. Requests pass through a secure gateway and each key is checked for authentication, permissions, and rate limits. API keys can be revoked and reissued on request.
How are API inputs and rate limits enforced?
Inputs and payloads are validated against Pydantic models. When a rate limit is reached, the API returns an HTTP 429 rate-limit-exceeded response. Retrieval endpoints are strictly rate-limited and monitored for abuse.
Is data encrypted in transit and at rest?
All requests to and from NOSIBLE APIs are encrypted in transit with TLS 1.2 or newer. Bulk Search and Time Search results are delivered as encrypted JSON files. The live search index is not encrypted at rest because it must remain queryable; NOSIBLE mitigates that exposure with dedicated infrastructure, firewalls, DDoS protection, restricted administrative access through Tailscale with MFA, and recorded access activity.
What customer API data does NOSIBLE retain?
NOSIBLE retains limited usage logs for 24 hours to enforce rate limits and prevent abuse. It does not log or record API request or response payloads on normal endpoints. Customer API requests are processed on OVHcloud servers in France, Germany, and the UK and are not stored.
Where are delivery files and supporting services hosted?
Raw crawl artifacts are stored in Wasabi S3. Google Cloud supports datastore, storage, error reporting, and secret management. NOSIBLE World S3 delivery is served from AWS us-east-1. Bulk Search and Time Search results are delivered as encrypted JSON files.
What logging and monitoring does NOSIBLE use?
Usage logs retain only what is needed for rate limits and abuse prevention and are deleted after 24 hours. API payloads and customer content are not included in logs. Administrative server access and activity through Tailscale are recorded and auditable. NOSIBLE is in the early stages of using Vanta for vendor and control monitoring.
Have NOSIBLE APIs undergone security testing?
Internal code reviews have occurred, but NOSIBLE has not yet completed penetration testing or an independent vulnerability assessment. Vulnerability and control monitoring through Vanta is still in the early stages. NOSIBLE will share an executive summary after independent testing is completed.
How does NOSIBLE keep replicas consistent?
The index uses write-ahead log replication. Committed changes are shipped from a primary index to replica indexes. Replica indexes replay those logs to stay synchronized, and checksums verify that the index is consistent across replicas after updates. Replication protects availability and integrity under GDPR Article 32.
What does NOSIBLE back up?
NOSIBLE backs up indexes to S3 regularly and keeps the index geographically replicated. Raw HTML and parsed JSON documents are stored in secure S3 buckets hosted by Wasabi. These backups and object stores support recovery, durability, replay, vendor review, and continuity if a primary system fails.
What operating system hardening is used?
NOSIBLE servers use Ubuntu Pro with full hardening enabled. NOSIBLE also uses server firewalls, endpoint security, antivirus, anti-malware, multi-factor authentication, email security controls, SSL encryption, and DDoS protection for the primary index and replicas. These controls reduce intrusion risk across servers, endpoints, and network access.
How does website verification reduce security risk?
Before a website enters the source universe, NOSIBLE checks whether the homepage resolves cleanly, whether it redirects to a different entity, whether it appears on internal blocklists, whether Google Web Risk reports malware, social engineering, or unwanted software, and whether the site publishes security.txt. These checks reduce unsafe-source risk before content reaches the index.
Why does NOSIBLE check security.txt?
security.txt can identify a website's vulnerability disclosure channel. NOSIBLE looks for it at the standard root and well-known paths and records the path when present. That does not prove a site is secure, but it gives a useful operational contact signal when a source needs review or when a security issue needs to be routed responsibly.
How is server access controlled?
Servers are accessible only through Tailscale, and access and activity are recorded. Access to core NOSIBLE systems also uses multi-factor authentication. Administrative access is separate from customer API permissions and governs the infrastructure that runs the index, replicas, storage, and supporting services behind customer-facing products.
Does NOSIBLE claim to be SOC 2 certified?
No. SOC 2 is an independent attestation report, not a certification. NOSIBLE is in the early stages of readiness work with Vanta and Cognisys. Policies are in place, vendors have been mapped, and controls are being implemented, but no independent examination or report has been completed.
How would NOSIBLE handle breach notification?
NOSIBLE would assess notification duties under the laws that apply to the affected customers and data. UK and EU GDPR require supervisory-authority notification without undue delay and, where feasible, within 72 hours after awareness of a qualifying personal-data breach (GDPR Article 33). Data-subject notice applies where the breach is likely to create high risk (GDPR Article 34). U.S. timelines vary by state.
Which third-party vendors does NOSIBLE rely on?
NOSIBLE uses Bright Data for proxy infrastructure, OVHcloud for bare-metal hosting, Hugging Face and RunPod for dedicated GPU-hosted embedding endpoints, Google Cloud for datastore, storage, error reporting, and secret management, Wasabi for raw HTML and parsed JSON in S3-compatible storage, and AWS us-east-1 for NOSIBLE World S3 delivery. NOSIBLE maintains alternatives for critical vendors so it can move without redesigning the service.
What open-source technology does NOSIBLE use?
NOSIBLE is built with Python and runs in Docker containers on bare-metal OVH servers. Core packages used across the system include NumPy, Polars, Numba, Redis bindings, orjson, Zstandard, Aho-Corasick tools, spaCy, wordfreq, PyStemmer, fast language detection, SimSIMD, Flask, Gunicorn, FastAPI, Uvicorn, BeautifulSoup, LMDB bindings, OpenAI tooling, rbloom, datefinder, sentence-transformers, json repair tools, SciPy, scikit-learn, usearch, and Playwright.
Which embedding models and model vendors does NOSIBLE use?
NOSIBLE Search uses Microsoft's multilingual-e5-large-instruct model through dedicated Hugging Face and RunPod GPU endpoints. NOSIBLE World uses OpenAI's text-embedding-3-large model.
Is NOSIBLE SOC 2 compliant?
Not yet. NOSIBLE is in the early stages of SOC 2 readiness with Vanta and Cognisys. Policies are in place, vendors have been mapped, and controls are being implemented. No independent examination has been completed and there is no SOC 2 report to share today. In the meantime, NOSIBLE can share its security posture, policies, and compliance pack during customer due diligence.