Skip to content

IVAAP Technical Data Sheet



IVAAP Technical Requirements Overview




IVAAP 2026.1

Software requirements

IVAAP requires a modern browser that supports HTML5 Canvas and WebSockets, and is only tested against Chrome, Edge, and Safari. For 3D views, WebGL must be supported.

Platform Capabilities (Summary)

IVAAP is a development and visualization platform that includes:

  • A built-in formula engine for reusable scalar and array-based calculations
  • SDKs for application development (JavaScript Client SDK and Java Data Backend SDK)
  • Configurable branding and UI customization
  • License-based enablement using SLB-supported licensing mechanisms

Server requirements (single host)

To ensure optimal performance and compatibility, IVAAP should be deployed on a dedicated server with no other services running concurrently.

Database Requirements:

  • IVAAP relies on a PostgreSQL database and optionally supports connecting to MongoDB for specific use cases. IVAAP does not include a MongoDB instance — customers must provision and manage their own MongoDB deployment. Refer to the official MongoDB documentation for installation and configuration guidance.

Java SDK Development:

  • For deployments involving the Java Data Backend SDK, it is recommended to install Oracle JDK 21 on the host system during development.
  • IVAAP container images for Java components are packaged with OpenJDK 21, and preconfigured base images are available for building custom datanode containers if needed.

Data Connectivity and Supported Connectors:

IVAAP supports a broad set of data connectivity options to integrate with existing enterprise and industry-standard data sources, including:

  • OSDU services across cloud providers (AWS, Azure, GCP, IBM)
  • Cloud object storage (S3, Azure Blob, Google Cloud Storage)
  • WITSML (1.3.1 with limitations, 1.4.1)
  • PPDM 3.8 data model
  • SQL databases (PostgreSQL, SQL Server, Oracle, MySQL) for tabular data access
  • MongoDB for table-based and well-based data, including write-back scenarios

Supported data formats include seismic (SEG-Y, OpenVDS, OpenZGY, etc.) and well data (LAS, DLIS), depending on the connector used.

Container Orchestration:

  • A typical single-instance deployment uses k3s to orchestrate OCI-compliant container images.
    Ensure the runtime environment is compatible with k3s version 1.30 or higher.
  • Starting with IVAAP 2026.1, deliveries ship as a unified zip from the SLB Software Download Center. The primary artifact is the self-extracting ivaap binary (embedded Helm chart, container images, and connectors). The zip also includes a Windows documentation executable (IVAAP_Documentation_*.exe), a documentation zip for ./ivaap docs start on Linux, and a lightweight Helm chart config archive. Run ./ivaap install on a dedicated Linux host for k3s; the installer provisions k3s and Helm when they are not already present. Multi-node deployments (AKS, EKS, OpenShift) use the same binary for retag-images and generate-yaml; see the Multi-Node Kubernetes Installation Guide.

Delivery Model

Series Delivery format Primary install path
2025.x Zip archive containing deploy-ivaap.sh plus chart, images, and seed Run deploy-ivaap.sh on the target host
2026.x Single zip containing the ivaap binary (embedded chart, images, seed, docs) ./ivaap install for k3s; ./ivaap retag-images + ./ivaap generate-yaml for BYO Kubernetes

The 2025.x script-based delivery is legacy. New deployments and upgrades should use the 2026.x ivaap binary. See the Single-Node K3s Installation Guide and Multi-Node Kubernetes Installation Guide for the supported install paths, and the IVAAP All-in-one Binary reference for subcommand details.

Operating System Compatibility:

  • SLB’s preferred OS distribution is Ubuntu LTS, with primary testing conducted on Ubuntu 22.04.
  • IVAAP has also been successfully deployed on Amazon Linux 2+, RHEL 9, and other Linux distributions.
  • Note: Non-Ubuntu systems may introduce native code dependency issues that could affect certain SDK functions.

Architecture Requirement:

  • IVAAP currently supports only x86_64 CPU architecture.

Server System Requirements

IVAAP is a modular, scalable platform composed of microservices that can be deployed in environments ranging from lightweight development setups to full-scale production infrastructure. The system’s resource needs vary based on the number of active features, concurrent users, and data volume.

If deploying on virtual machines, it's recommended to scale resources dynamically as development progresses and requirements evolve. IVAAP images are built for x86_64 architecture.

Single Host Deployment Guidelines

Low to Medium Usage (Development or Light Production)

  • CPU: 8-core modern processor
  • Memory: 32+ GB RAM (based on nodes/features)
  • Storage (SSD):
    • Split disks — /var/lib/rancher (k3s) ≥ 60 GB, /opt/ivaap ≥ 80 GB
    • Single disk — ≥ 150 GB total
  • Suggested EC2 Class: m(x).2xlarge

High Usage (Production with Heavy Activity)

  • CPU: 16+ core modern processor
  • Memory: 32–64+ GB RAM
  • Storage (SSD):
    • Split disks — /var/lib/rancher (k3s) ≥ 100 GB, /opt/ivaap ≥ 150 GB
    • Single disk — ≥ 256 GB total recommended (≥ 150 GB bare minimum)
  • Suggested EC2 Class: m(x).4xlarge or higher
  • Note: Seismic workloads using VDS/ZGY OpenSeismic libraries require significantly more resources.

What drives the storage requirements

The ivaap installer binary embeds ~12 GB of payload (Helm chart, container images, database seed, helpers). At install time, the payload is extracted to /opt/ivaap, and container images are imported into /var/lib/rancher by k3s. Upgrades transiently double the footprint in /opt/ivaap while the old and new artifacts coexist. Logs, PVCs, and database growth accumulate over time on top of that baseline.

WSL2 Deployments (Development / Evaluation Only)

Not for production

WSL2 (Windows Subsystem for Linux 2) is supported for development, evaluation, and demonstration only. WSL2's NAT networking, memory governor, and dependency on the Windows host introduce reliability and reproducibility risks that are unacceptable for production IVAAP deployments. Production deployments must run on a native Linux host or a supported Kubernetes platform (AKS, EKS, OpenShift).

WSL2 runs IVAAP inside a managed Linux VM on top of a Windows host, which means the host machine carries the full Linux footprint plus Windows overhead. Plan for both layers.

Windows host requirements:

  • OS: Windows 10 build 19041+ or Windows 11 with WSL2 enabled
  • CPU: 12+ cores (so WSL2 can be allocated at least 8 without starving Windows)
  • Memory: 48+ GB RAM (so WSL2 can be allocated ≥ 32 GB via .wslconfig)
  • Host disk (for the WSL2 ext4.vhdx virtual disk): ≥ 250 GB free SSD. The vhdx grows on demand and does not shrink automatically — leave headroom.

WSL2 distribution requirements:

  • Distribution: Ubuntu 22.04 LTS, installed as a dedicated WSL2 distro for IVAAP (do not share with other development work)
  • systemd: must be enabled ([boot] systemd=true in /etc/wsl.conf)
  • WSL2 resource allocation (via %USERPROFILE%\.wslconfig on the Windows host):
    • memory=32GB (minimum; 48 GB recommended for High Usage profile)
    • processors=8 (minimum)
    • swap=8GB
  • In-distro disk: matches the Low/Medium tier above (/var/lib/rancher ≥ 60 GB, /opt/ivaap ≥ 80 GB) since the WSL2 vhdx is the disk

Known WSL2 considerations:

  • Do not extract or run the ivaap binary from /mnt/c/.... The Windows filesystem bridge is 10× slower for the multi-gigabyte extraction step and breaks Linux file ownership semantics. Copy the delivery zip into the WSL2 ext4 filesystem first (e.g., ~/ivaap-deploy/).
  • License server placement — SLB recommends running the FlexNet license server on a separate host. If a same-host loopback license server is unavoidable in a dev/eval scenario, the installer handles routing via a synthesized hostname (ivaap-flexnet.local) injected into /etc/hosts and the k3s bridge IP — do not hardcode loopback IPs into license configuration.
  • Windows Update can restart the WSL2 kernel mid-install. Pause Windows updates for the install window, or run the install during a maintenance period.
  • Corporate VPN clients on the Windows host frequently break WSL2 outbound networking. Confirm curl https://sdc.software.slb.com succeeds inside the WSL2 distro before starting the install.

Multi Host Orchestration Environments

IVAAP can be deployed beyond single-host setups using Kubernetes-compatible orchestration platforms such as:

  • AWS EKS
  • Azure AKS
  • Red Hat OpenShift

Instead of using k3s, the Helm chart template enables scalable deployment across these platforms. IVAAP containers do not require elevated privileges, making them suitable for secure, enterprise-grade environments.

Kubernetes/OpenShift Resource Guidelines

These starting points reflect typical pod resource requirements. Performance is best when CPU limits are not set, and in large clusters, memory requests may also be omitted. SLB recommends managing resources at the pod or node level, not the container level. If container-level limits are required, set memory requests equal to memory limits.

Pod Resource Overview

Note: For optimal performance, SLB recommends managing resources at the pod or node level rather than setting strict container-level CPU or memory limits. Memory requests and limits should be aligned if limits are required.

Pod Type Description Requests (CPU / Memory) Limits (Memory) Notes
IVAAPServer Single Java container 500m / 512Mi 4Gi May benefit from ≥8 vCPU in high usage
Admin Client NGINX serving static JS site 100m / 128Mi 1Gi Low resource usage
Viewer Two NGINX containers for static JS sites 100m / 128Mi (each) 1Gi (each) Low resource usage
Backend Data Platform JVM cluster with Akka network (6 core containers) 2500m / 3840Mi (total) 13Gi (each) Additional containers per data type
Backend Data Platform Additional connector container 1000m / 512Mi 2–128Gi Depends on workload; seismic requires more
Backend Tasks JVM containers for real-time features 100m / 64Mi per task 6–10Gi Typically 3–4 tasks in real-time setups
Ingress Proxy NGINX routing HTTP/WebSocket traffic 250m / 256Mi 1Gi —

PostgreSQL Requirements

IVAAP requires a PostgreSQL 17.x instance to store dashboards and user/project metadata. SLB recommends using a managed cloud database or a dedicated external instance located in the same datacenter as the IVAAP AdminServer.

Key Requirements:

  • Latency: <100ms (ideal: 20–60ms) - This can be confirmed with the /IVAAPServer/api/v2/testresults API.
  • Connections: 30–60 per IVAAP instance (max 100 recommended)
  • Disk Usage: Typically 1–3 GB; up to 15 GB in large deployments

Required Extensions:

  • CITEXT, FUZZYSTRMATCH, PG_BUFFERCACHE, PG_STAT_STATEMENTS, PLPGSQL,
    POSTGIS, POSTGIS_TIGER_GEOCODER, POSTGIS_TOPOLOGY, UUID-OSSP

Network Connectivity

  • Ports: HTTP/HTTPS (80/443) must be open for browser access
  • Data Source Proximity: IVAAP should be deployed close to its data sources to avoid latency
  • Proxy Disclosure: If a corporate proxy is used, SLB must be informed for configuration

OSDU Seismic Data Support

IVAAP supports seismic data stored in cloud object storage or Seismic DDMS, including:

Cloud Storage:

  • SEG-Y files
  • OpenVDS

Seismic DDMS:

  • SEG-Y files
  • OpenVDS
  • OpenZGY

Note: For AWS, Seismic DDMS data must reside in the same region as the IVAAP deployment.

Security & Access

  • Authentication: Local users (PostgreSQL) or OpenID Connect (OIDC) via AWS Cognito or Azure Entra ID
  • Data Access: Role-based permissions, secure APIs
  • Cloud Compatibility: Azure, AWS, GCP, OSDU-compliant