CVE commitment
Search and observability without sending a single log outside Nigeria.
Search, logs and text analytics that stay in the country
Apache Solr and OpenSearch, deployed and supported on your own infrastructure. Replace foreign observability SaaS, power customer search in the digital channel and run AML screening, all inside the CBN perimeter.
- OpenSearch
- Apache Solr
- OpenSearch Dashboards
- Data Prepper
The technologies we cover
Products in this family
OpenSearch
Apache 2.0 search and analytics engine, the open fork of Elasticsearch 7.10, used for log management, security analytics and application search.
Bare metalKubernetesPrivate cloudAir-gappedOfficial support
Apache Solr
Mature Lucene-based search platform with SolrCloud clustering, fine-grained relevance tuning and a long track record in banking and retail catalogues.
Bare metalKubernetesPrivate cloudAir-gappedOfficial support
OpenSearch Dashboards
Visualisation, alerting and reporting layer for OpenSearch, with role-based access and audit-ready saved searches.
KubernetesPrivate cloudAir-gappedOfficial support
Data Prepper & Fluent Bit
Lightweight collection and enrichment pipelines that move logs, traces and audit events from hosts and clusters into OpenSearch.
Bare metalKubernetesAir-gappedOfficial support
Why it matters for data localisation
Where this family meets the CBN directive
The CBN data-localisation directive requires that primary processing, databases, backups, identity and access management, encryption keys and audit logs for Nigerian financial data be kept in the country by 1 January 2027, without dependency on a foreign cloud provider. Logs are the item most often overlooked. Application logs, access logs and audit trails routinely contain account numbers, BVNs, card fragments and customer identifiers, and in many institutions they are shipped to an observability SaaS hosted abroad. Auditors treat this as a localisation finding, and remediation is on the clock. This family answers that finding directly: OpenSearch and Solr run on your own servers in Nigeria, retention and snapshots stay on Nigerian object storage, and the audit trail the CBN can inspect is produced inside the perimeter. The same platform serves customer search in the digital channel and AML screening, so the investment covers three regulated workloads rather than one. Nothing here is legal advice; your compliance team should confirm the scope that applies to your institution.
The journey with NuxFamily
- 01Assess
- 02Design
- 03Build
- 04Migrate
- 05Operate
- 06Evolve
Every family is delivered through the same six-stage journey, with official 24×7 support and knowledge transfer built in.
Our expertise
Credentials, not adjectives
We have run Solr and Elasticsearch-family clusters in production for European banks, insurers and retailers since the SolrCloud era, including catalogue search for one of Europe's largest fashion retailers and log platforms for retail banks under ECB supervision. Since the licence change in 2021 we have migrated several of those estates to OpenSearch without downtime. Our engineers handle shard design, JVM tuning, relevance work and the security plugin day to day, and the same team carries the support contract.
Sectors
- banking
- insurance
- retail
- industry
12+
Years with these technologies
25+
Production deployments
40-node OpenSearch cluster indexing 20 TB of logs per day
Largest scale delivered
Official vendor support
Support tiers for this family
Essential
- Coverage
- 8×5, Nigeria business hours
- P1 response
- 4 h
- Corrective support for OpenSearch, Solr and Dashboards
- Security patches for the supported release lines
- Access to the knowledge base and ticket portal
- Guidance on index, shard and retention settings
Business
- Coverage
- 24×7
- P1 response
- 1 h
- Everything in Essential
- Proactive cluster monitoring (heap, shard balance, queue depth)
- Quarterly health checks and capacity review
- Version management and minor-upgrade execution
- Relevance and pipeline tuning sessions
Mission Critical
Most chosen- Coverage
- 24×7 with a named engineer
- P1 response
- 15 min
- Everything in Business
- Named engineer who knows your cluster
- Architecture review twice a year
- Major-upgrade support (Solr 8 to 9, OpenSearch 2 to 3)
- Support during CBN inspections and evidence extraction
Version policy
Response times and tier names are indicative and confirmed contractually.
Use cases
How it is used in a regulated bank
Use case 01
100 % local log and audit platform
A bank ships application and infrastructure logs to a foreign observability SaaS. The logs contain customer identifiers and access events, and the CBN inspection team has asked where they are stored. The institution needs an equivalent platform in Nigeria, with retention and traceability it can demonstrate.
Technologies
- OpenSearch
- Data Prepper
- Fluent Bit
- Apache Kafka
- MinIO
Expected outcome
All logs and audit trails are produced, stored and retained inside Nigeria, with a defined retention schedule and an evidence pack the CBN can inspect. The foreign SaaS subscription is decommissioned.
Metric: Retention of 12 months searchable and 7 years archived, with the SaaS contract closed within one quarter
- 1Collect at source. Fluent Bit agents on hosts and Kubernetes nodes pick up application, system and access logs without changing application code.
- 2Buffer and decouple. Events land on Kafka topics so that indexing load and collector load are independent and nothing is lost during maintenance.
- 3Enrich and route. Data Prepper parses, masks sensitive fields where required and routes events to the right index by system and criticality.
- 4Index with tiers. OpenSearch stores hot data on NVMe, moves warm indices to larger nodes and rolls cold data off through Index State Management.
- 5Snapshot locally. Daily snapshots go to S3-compatible object storage in a second Nigerian data centre for retention and disaster recovery.
- 6Alert and inspect. Dashboards, alerting and saved searches give operations and compliance the same view; audit access to the platform is itself logged.
Use case 02
Customer and operations search in the digital channel
Use case 03
AML and sanctions-list screening
Reference architecture
What a compliant deployment looks like
Sources
Collection and indexing
Search platform
Consumers and retention
Migration path
From where you are to a compliant platform
01
2-3 weeksAssess
Activities
- Inventory every log source, index and dashboard in the current SaaS or Elasticsearch estate
- Classify which streams contain customer or payment data
- Measure daily ingest volume, query patterns and retention obligations
- Agree target retention tiers with compliance and internal audit
02
3-5 weeksDesign and build
Activities
- Size the OpenSearch and Solr clusters for peak ingest plus 40 % headroom
- Deploy on Kubernetes or bare metal in the primary Nigerian data centre
- Configure security plugin, SSO integration and field-level masking
- Set up snapshot repository on S3-compatible storage in the secondary site
03
4-6 weeksDual-run
Activities
- Ship logs to both the old platform and the new one in parallel
- Rebuild dashboards, alerts and saved searches on OpenSearch Dashboards
- Migrate Solr collections and re-index from source with relevance regression tests
- Train operations and compliance users
04
1-2 weeksCut over and decommission
Activities
- Switch collectors to the local platform only
- Export historical data from the SaaS provider for the retention period
- Confirm deletion of data at the foreign provider and keep the certificate
- Produce the localisation evidence pack
05
OngoingOperate
Activities
- 24×7 support under the agreed tier
- Quarterly capacity and retention review
- Minor upgrades on a planned cadence; major upgrades with a rehearsal cluster
FAQ
Questions architects ask us
The directive covers audit logs explicitly, and application logs frequently contain customer identifiers and transaction data that fall under primary processing. In our experience it is one of the most common findings in localisation assessments. Whether a given stream is in scope depends on its content, so we start with a classification of every log source. This is not legal advice; your compliance function should confirm the interpretation.
OpenSearch is licensed under Apache 2.0, which lets you run and modify it on your own infrastructure without vendor terms tied to a cloud service. It carries the security, alerting and index-management features that banks need, and the migration from Elasticsearch 7.x is well understood. Elasticsearch's licence changed in 2021 and its AGPL option in 2024 still needs careful reading for on-prem use.
Solr excels at structured search over business records where relevance is tuned in detail: customer lookup, product catalogues, document repositories. OpenSearch is the better fit for high-volume time-series data such as logs and security events, and for vector search. Many of our customers run both; we support both under the same contract.
A well-designed OpenSearch cluster scales horizontally to tens of terabytes per day of ingest. The practical limits are disk throughput on the hot tier and JVM heap per node, both of which we size from measured traffic rather than estimates. Hot, warm and cold tiers keep the cost of long retention under control.
Yes. OpenSearch, Solr and the collectors have no runtime dependency on external services. We deliver images and packages through an internal registry, and updates follow the same controlled import process we use for air-gapped Kubernetes.
NuxFamily engineers provide the support directly, from first response to root cause, on the release lines listed in the version policy. Coverage includes security patches, corrective fixes, upgrade execution and, on the Mission Critical tier, a named engineer and assistance during CBN inspections. The exact SLA terms are set out in the support agreement.
Masking happens in the pipeline before indexing: Data Prepper rules redact or hash card numbers, BVNs and other identifiers according to your data classification. Field-level and document-level security in OpenSearch then controls who can see what remains. Both layers are part of our standard deployment.
A typical estate with a few hundred log sources moves in three to four months from assessment to decommissioning, most of it in dual-run. Search migrations on Solr depend on the number of collections and the relevance work required; a single application usually takes six to eight weeks.
Over two decades
Built by the team behind the platforms of Santander, ING, Bankinter, Mapfre and Inditex
More than twenty years designing, building and operating private clouds for institutions that cannot afford to fail, and a delivery model where we stay with you from assessment to operation.
See our track record20+
Years building private clouds
40+
Private clouds delivered
Talk to an architect about this family
Tell us where you are today and we will come back with a first view of the target architecture and the migration path.