Unmanaged Private Cloud

The Unmanaged Private Cloud is an alternative deployment option to Jedox Cloud Software as a Service (SaaS). It allows customers to deploy Jedox in their own Kubernetes cluster, providing the flexibility to control and manage their infrastructure while benefiting from Jedox’s cutting-edge features. This offering is ideal for organizations with rigorous security requirements, as it enables them to maintain strict control over their infrastructure and systems and comply with industry-specific regulations.

Key Benefits

Own security standards
Maintain your organization's strict security standards by deploying Jedox in your own Kubernetes cluster, keeping sensitive data and planning processes within your controlled environment.

Customization and control
Gain complete control over the deployment process, enabling fine-tuning and customization as needed.

Helm Chart for Kubernetes Deployment

The Unmanaged Private Cloud leverages a continuously updated Helm Chart, which is the preferred method for deploying Jedox on Kubernetes clusters. Helm, a package manager for Kubernetes, simplifies the installation, configuration, and management of Jedox, ensuring seamless integration into your existing infrastructure.

Key highlights of using the Helm Chart

  • Automated deployment
    Helm Chart streamlines the deployment process, reducing the complexity of setting up Jedox on Kubernetes.
  • Flexibility and scalability
    The Helm Chart enables seamless scaling of Jedox instances to match evolving business needs.
  • Continuous updates
    Jedox is committed to regularly updating the Helm Chart with the newest version of the platform, providing access to the latest features and improvements.

Services Provided by Jedox Cloud Operations

Deployment assistance
Jedox Cloud Operations offers deployment assistance to help customers successfully set up Jedox on their Kubernetes cluster. This includes guidance on installing the Helm Chart and configuring Jedox according to the organization’s requirements.

Support and troubleshooting
Customers receive support related to the deployment and configuration of Jedox on their infrastructure.

Helm Chart updates
The Helm Chart provided by Jedox Cloud Operations is continuously updated with the latest Jedox version, ensuring access to the newest features, bug fixes, and performance improvements.

Technical Requirements

These guidelines are applicable to most deployment scenarios in CNCF-certified Kubernetes distributions.

Before starting the deployment, ensure that the following requirements are met:

Requirements Details
Helm and admin access Helm must be installed on the local machine that you will use for deployment, and you must have admin access to the Kubernetes cluster.
Kubernetes version As of January 2025, Jedox has been tested to be compatible with Kubernetes version 1.31.x. While using older/newer releases may be technically possible, it has not been officially tested against the latest Jedox version.
Worker nodes The Kubernetes cluster must meet the following worker node requirements:
  • The cluster must be provisioned with a minimum of 2 worker nodes.
  • The worker nodes must be dedicated solely to supporting the workloads of the cluster.
  • Recommended worker node size is 16CPU and 128GB RAM.
  • Nodes must be equipped with an OS disk of at least 128GB.
Ingress controller
  • Inbound access to Jedox must be done via the Ingress NGINX controller for Kubernetes version 1.21.6.
  • Install NGINX Ingress Helm Chart using the following command:
    helm install ingress-nginx ingress-nginx/ingress-nginx --version 1.25.5
  • Ensure that the release name and namespace for the NGINX Ingress controller are set to “Ingress-nginx”.
Inbound access and certificates
  • Inbound access to Jedox must be done via HTTPS.
  • Certificate management and deployment must be performed according to each customer’s best practices.
Storage requirements
  • Each Jedox instance must be provided with at least 512GB of underlying storage. The Persistent Volumes (PVs) must be created via StorageClass.
  • The underlying storage of the storage class must provide ReadWriteMany volumes. The StorageClass must utilize NFS version 3 as the underlying storage protocol:
    - rw
    - relatime
    - rsize=262144
    - wsize=262144
    - namlen=255
    - hard
    - proto=tcp
    - nconnect=8
    - timeo=600
    - retrans=2
    - sec=sys
    - mountproto=udp
    - local_lock=none
    - nolock
  • PostgreSQL database. Jedox requires a PostgreSQL database for persisting the ETL drillthrough and ETL history.
  • Deploy a PostgreSQL database along with Jedox to fulfill this requirement.

Disclaimer: while the Helm Chart has been tested for compatibility with Jedox's Azure infrastructure, it may also work with other cloud providers. However, it is the responsibility of the customer to ensure the compatibility and suitability of the Helm Chart for their specific cloud provider. We recommend conducting thorough testing and evaluation before deploying the Helm Chart in a non-Azure environment. Jedox does not guarantee the performance or functionality of the Helm Chart in cloud providers other than Azure. Customers should do their due diligence and consult with their cloud provider's documentation and support resources for guidance on deploying and managing applications in their specific environment.

Installation Steps

Follow the steps below to install Jedox in the Kubernetes cluster:

Step 1: Login to the Jedox container registry

Run the following command to login to the Jedox container registry:

Copy 
helm registry login XXX.azurecr.io -u xxx -p Xxx

Replace ‘XXX’ with the actual container registry URL, and ‘xxx’ and ‘Xxx’ with your username and password, respectively.

Step 2: Pull and export the Jedox Helm Chart

After successfully logging in, pull and export the Jedox Helm Chart to a directory on your computer using the following commands:

Copy 
helm pull oci://XXX.azurecr.io/helm/jedox --version xx.x --untar --untardir jedox-xx.x

The value for the version parameter in this command is specifying the version of the Jedox Helm Chart to be pulled, and is not to be confused with the version of the Jedox Platform that will be installed with this Chart later. To define the Jedox Platform version, go to the Jedox directory within untardir, which has been created after running the helm pull command, and define the Jedox version that you want to install afterwards by running one of the following set-ver scripts:

  • For PowerShell (Windows)
    .\set-ver.ps1 -newVersion "<your_version>"; E.g: .\set-ver.ps1 -newVersion "24.2"
  • For Bash (Linux/Mac)
    ./set-ver.sh <your_version>; E.g: ./set-ver.sh 24.2
Step 3: Adjust values in YAML files

Go to the Jedox-xx.x/Jedox directory, where the Helm chart is extracted, and locate the file jedox_values.yaml. Adjust the values in this file according to your specific requirements. The values in the jedox_values.yaml file should be edited when defining a new Jedox instance. The values.yaml file does not need to be edited in a normal setup scenario.

Copy 
# NOTE: What is called "Jedox instance" in the docs, is in Helm terminology a "release".
# NOTE: This is a streamlined version of the values.yaml file. For a full list of options, please refer to the values.yaml file.
# NOTE: The jedox_values.yaml file is used to define the most common production settings for the Jedox instance.
# NOTE: In a standard deployment, you only need to modify this and only this file. Values.yaml should be ignored.
global:
  # values used by the BYOI deployment
  storage:
    # You can enable only one storage method: fromStorageClass / fromPersistentVolume / fromNfs
    external:
      fromStorageClass:
        # Set to true if you want to use StorageClass 
        enabled: false
        # For jedox_values.yaml, the storageClass must always be RWX and Use nfs 3.1 instead
        # If you cannot natively provide RWX storage, you can use the NFS option below
        # https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner
        # Name of the storage class defined in your cluster (required)
        storageClass: default
        #The disk size must always be at least 128Gi (512GB recommended)
        diskSize: 128Gi

      #To be used when you want to define your PersistentVolumeClaim manually
      fromPersistentVolume:
        # Set to true if you want to use manually defined PVC
        enabled: false
        # The below variables are used to define external NFS for Jedox
        # Please input the name of a RWX PVC that is already defined in the NS where you deploy Jedox (required)
        # pvc: rwx-pvc

      # To be used when you run your own NFS server
      # Only NFS 3 is supported
      fromNfs:
        enabled: false
        #
        # NFS server address (required)
        server: 10.100.10.10
        #
        # NFS path (required)
        path: /jedox
        #
        # NFS volume size (default is 100Gi)
        #size:
        #
        # NFS volume reclaim policy (default is Retain)
        #reclaimPolicy:
        #
        # NFS volume mount options (default is rsize=262144, wsize=262144, nconnect=8). nfsvers=3 is required and always set
        #mountOptions:
  #
  #
  #Define the PostgreSQL settings
  #Set to true if you want to use an external PostgreSQL DB
  db:
    # If both external and internal PostgreSQL options are set to false, it will fallback on H2 DB (not supported)
    # Either external or internal can be enabled at the same time.
    postgres:
      #
      # Use an external PostgreSQL server
      external:
        enabled: false
        #
        # PosgreSQL init details (required)
        #
        # for BYOI, this is the hostname or IP for the PostgreSQL DB (required)
        databaseHost:
        #
        #for BYOI, this is the name of the database you've defined in the PostgreSQL server (the DB schema should have the same name)
        databaseName:
        #
        # PostgreSQL username (required)
        databaseUser:
        # PostgreSQL password (required)
        databasePassword:
        # for BYOI, this is the port for the PostgreSQL DB (required)
        databasePort: 5432
        # Sslmode for PostgreSQL DB (required)
        sslmode: require
  # vhosts configuration
  vhosts:
    #
    # Virtual hosts. Default uses the Helm release name.
    # Format: <namespace>.<apex-domain>.
    # The namespace serves as the subdomain. E.g.:
    #hosts:
    #  - company.jedox.com
  # cert-manager configuration
  # If using cert-manager, you can add the issuer name to the values.
  cert_manager:
    enabled: false
    #
    # issuer name, default is letsencrypt-staging
    #issuerName: letsencrypt
    #
    # issuer kind, default is ClusterIssuer
    #issuerKind: Issuer
olap:
  enabled: true
  olap:
    # hardware key for licensing, at least 10 chars (required)
    #hwKey:

 

Step 4: Namespace naming convention

As per Jedox naming conventions, the namespace where you deploy the Jedox instance must have the same name as the subdomain in the DNS. For example, if your instance is accessed via the domain dev-jedox.customer.com, the namespace of the instance must be dev-Jedox.

Step 5: Deploy Jedox

Use the following Helm command to deploy Jedox to the Kubernetes cluster:

Copy 
helm install <NAMErelease-name> . --namespace <NS> --values values.yaml

Replace ‘<release-name>’ with the desired name for the Helm release.

Step 6: Ingress and certificates

Once the Helm chart is deployed, you must adjust the Ingress controllers to point to the correct domain. You can do this via the externalDomains parameter in values. Once set, you’ll be able to access Jedox via <chart_name>.<domain>.
The certificates must be set manually for each Ingress controller.

Step 7: Docker images

Our commitment to providing a seamless user experience includes the automatic release of Docker images whenever improvements are made. The updated Docker image is automatically released during scheduled overnight processes, ensuring you wake up to the latest, most stable version.

Frequently Asked Questions

Below we address the most common questions about the Private Cloud offering.

Overall, customers must ensure that they have the budget for the infrastructure and the right engineering team to set up and manage it. Jedox provides the application via a Helm Chart, but the installation and monitoring of the infrastructure is customers' responsibility. Jedox will only support the application itself - in this case the customer should contact Jedox Support. Note that Jedox does not have a monitoring mechanism in place, nor does it have any access to the environment.

In the Private Cloud offering, “unmanaged” means that Jedox Cloud Operations will not directly manage the infrastructure where the Jedox Platform is deployed. Instead, it is the responsibility of the customer to manage and maintain the underlying infrastructure, including the Kubernetes cluster and associated resources. Jedox will provide the necessary software components, such as the Helm Chart for deployment, but customers are required to handle the operational aspects of their infrastructure.

In the Unmanaged Private Cloud offering, the customer is responsible for tasks such as provisioning and scaling the Kubernetes cluster, ensuring high availability and disaster recovery measures, applying security patches, monitoring performance, and troubleshooting infrastructure-related issues.

Jedox will provide support related to the deployment of the Jedox platform within the customer’s Kubernetes cluster. This support typically includes assistance with the installation, configuration, and troubleshooting of the Jedox software. Customers should be aware that Jedox will not provide ongoing infrastructure management or maintenance. For such tasks, customers are expected to have their own technical resources, or partner with a managed service provider.

In the Unmanaged Private Cloud offering, Jedox Cloud Operations will not have direct access to your data or network. Jedox will provide the necessary software components, but the data resides within the customer’s infrastructure and is not accessible by Jedox Cloud Operations. The Jedox team does not have visibility into your data or network configuration. This is done on a best-effort basis.

We monitor the status and performance of services comprising the Jedox Application. Patches are applied automatically. New releases are communicated to the customer in advance. When the customer requests not to upgrade, Jedox puts the customer on a hold list.

Jedox is committed to continuously updating the Helm Chart with the latest Jedox version, ensuring customers have access to the most recent features, enhancements, and bug fixes. The frequency of these updates may vary based on the Jedox’ release schedule and the introduction of new versions. Customers should regularly check for updates or subscribe to notifications from Jedox to stay informed about the availability of new Helm Chart releases.

Yes, the Unmanaged Private Cloud offering is designed to be flexible and customizable. You can integrate Jedox seamlessly with your existing infrastructure, data sources, and services. The Helm Chart allows you to adjust settings to meet your specific requirements and integration needs.

While the Unmanaged Private Cloud offering provides flexibility and control, it requires technical expertise to manage the Kubernetes cluster and associated infrastructure. Customers should consider their team’s capabilities, infrastructure readiness, and ongoing maintenance requirements before opting for this offering. Additionally, customers are responsible for ensuring compliance with relevant data protection regulations and implementing best practices for securing their infrastructure and data.

Secure development: Jedox adheres to the principles of secure software development and testing along the Secure Development Lifecycle (SDLC) in all Jedox internal software development procedures.

Security patches: Jedox continuously deploys security patches overnight (local time). Thus, there is no downtime for customers and no need to schedule a maintenance window during which work on the Jedox Platform must be halted.

Jedox has partnered with HackerOne for a continuous bug bounty program. Throughout the year, potential weak spots are identified by selected security experts from a group of global “white hat hackers”. These weak spots are triaged and quality tested, and this information is shared with Jedox internal teams. Through this practice, Jedox has implemented an additional layer of quality assurance, guaranteeing the best practices in data security to protect customer data. Besides actively searching for vulnerabilities, the Jedox development pipeline implements various other security tools and methods, such as Trivy and Static Code Analysis.

Updated February 3, 2025