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 the UK and Europe.
- 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.
- Server access is controlled through Tailscale, MFA, and separated admin permissions.
- NOSIBLE uses firewalls, endpoint security, antivirus, SSL, and DDoS protection.
- Website verification checks security.txt, Google Web Risk, blocklists, and redirects.
- Dedicated replicas isolate capacity, access, API keys, query contention, and audit boundaries.
- nosible.world is designed for on-prem deployment in secure customer environments.
- NOSIBLE has completed SOC 2 readiness work and is preparing for independent examination.
Security starts with dedicated infrastructure and controlled access
NOSIBLE runs almost entirely on dedicated bare-metal servers hosted by OVHcloud in the UK and Europe. They run hardened Ubuntu Pro and are accessible only through Tailscale, with access and activity recorded.
The system is split into web discovery, web crawling, and web indexing. Discovery finds websites and URLs. Crawling retrieves HTML from whitelisted websites and converts it into structured data. Indexing streams that structured data into shards that contain lexical indexes, vector indexes, and supporting artifacts. Hosting, access, replication, backup, delivery, and customer-key controls each have a defined operational role.
Index resilience is handled through backups and replication
| Area | NOSIBLE position |
|---|---|
| Primary hosting | Dedicated OVHcloud bare-metal servers in the UK and Europe. |
| 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 standard | NOSIBLE has completed readiness work and is preparing for an independent SOC 2 examination. |
Operational controls reduce intrusion and abuse risk
NOSIBLE uses firewalls, endpoint security, antivirus, anti-malware, multi-factor authentication, high-security Gmail settings, SSL encryption, DDoS protection, BrightData routing, and hardened Ubuntu Pro. NOSIBLE has completed SOC 2 readiness work and is preparing for an independent SOC 2 examination. 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 primarily on dedicated OVH bare-metal servers in the UK and Europe. NOSIBLE also buys load balancers and networking products from OVH. The core index is a large retrieval system that 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. Web discovery finds websites and URLs that should be indexed. Web crawling retrieves HTML from whitelisted websites and converts it into structured data. Web indexing streams that data into relevant shards, each of which contains a lexical index, vector index, and other retrieval artifacts.
How are Search Feed and Crawl Feed delivered securely?
Crawl Feed publishes matching results to a private Pub/Sub channel visible to the customer and NOSIBLE. Search Feed delivers results to S3 or a customer-selected storage system. Delivery setup controls access, retention, and customer-side handling.
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 has completed readiness work with Vanta and Cognisys, has mapped vendors, and has implemented controls. NOSIBLE is preparing for an independent SOC 2 examination and does not claim a completed SOC 2 report.
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.
How does the SQL filter affect security and data minimization?
SQL filters run after pre-retrieval and before retrieval, so NOSIBLE constrains the search space before pulling final results. That is better than filtering after results are retrieved. It reduces unnecessary exposure, improves precision, and lets customers narrow searches by fields such as domain or date.
What fields can customers filter on?
Customers can filter on fields such as chunk key, document key, domain, published date, visited date, total chunks, chunk number, word count, and company identifiers. These fields make filtering operationally useful because they constrain source, timing, document structure, and entity scope before retrieval.
Why does NOSIBLE use Google Knowledge Graph identifiers?
NOSIBLE uses Google Knowledge Graph identifiers because they cover many current and defunct public companies, private companies, geographic locations, and notable people. That improves entity targeting and recall. It also gives customers a stable identifier layer across company names, aliases, and historical records.
Which third-party vendors does NOSIBLE rely on?
NOSIBLE uses Bright Data for proxy infrastructure, OVHcloud for bare-metal hosting, Hugging Face for GPU-hosted embedding endpoints, Google Cloud for core services, and Wasabi for S3-compatible storage. NOSIBLE maintains lists of competitors for each vendor so it can move if needed without redesigning the service.
Can customers get a dedicated replica?
Yes. NOSIBLE offers dedicated replicas that are secure, private, contention-free, and accessible only by approved API keys. A dedicated replica can handle roughly 25-50 million unfiltered searches per day, and more if queries are filtered. That is a security and operations feature because it isolates capacity and access for a customer deployment.
What does a dedicated replica isolate?
A dedicated replica isolates capacity, access, approved API keys, and query contention for a customer deployment. The customer gets a private operating lane with predictable throughput, cleaner audit boundaries, stronger access control, and fewer shared-infrastructure concerns.
Can NOSIBLE offer an on-prem replica?
Yes. nosible.world is designed to be deployed on prem for customers that need the index inside their own secure environment. An on-prem replica can keep data, access, logs, and network paths under the customer's controls while preserving NOSIBLE search, retrieval, and point-in-time workflows. Deployment scope, refresh cadence, hardware, authentication, and update process are agreed during enterprise architecture review.
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 uses Microsoft's multilingual-e5-large-instruct model through Hugging Face dedicated endpoints running on AWS GPU servers. NOSIBLE plans to migrate to qwen3-embed-8b in Q1 2026 and is evaluating OpenRouter as an alternative embeddings provider. The planned migration is intended to improve search recall and precision without changing the data schema or delivery.
What happens during the planned embedding and resharding migration?
NOSIBLE plans to migrate from multilingual-e5-large-instruct embeddings to qwen3-embed-8b and then reshard the index into higher-quality collections. The planned migration improves recall and precision without changing the data schema or delivery. Customer integrations are expected to continue using the same data contract.
Are NOSIBLE shards interpretable?
Yes. NOSIBLE assigns metadata to shards so analysts and data scientists can understand what each shard contains. That includes language, title, description, geography, industry, topic, brand-safety status, top entities, top keywords, statistics, and example questions. Analysts can inspect the index structure before depending on a shard.
Is NOSIBLE SOC 2 compliant?
Not yet. NOSIBLE has completed a bootcamp with Vanta and Cognisys, has mapped vendors, and has implemented controls. NOSIBLE is preparing for an independent SOC 2 examination. SOC 2 is an attestation report, not a certification, and NOSIBLE does not have a completed report today.