SFTPPlus MFT on Kubernetes and OpenShift

Run secure file transfer services and automated transfers on Kubernetes or OpenShift. Use the SFTPPlus Helm chart, ConfigMaps, Secrets, and clustering.

Kubernetes logo in golden color on a dark background

SFTPPlus MFT runs as a containerized file transfer server and transfer automation service in Kubernetes and OpenShift. One deployment can provide incoming SFTP, FTPS, HTTPS, and AS2 services alongside scheduled outbound transfers. It does not require a separate application server or external database. Teams can use the networking, storage, configuration, and secret management facilities already available in their cluster for both sides of the file exchange.

Kubernetes Logo

Supported Kubernetes environments ​

SFTPPlus MFT can run in an on-premises cluster, OpenShift, or managed Kubernetes services such as:

  • Azure Kubernetes Service
  • Amazon Elastic Kubernetes Service (EKS)
  • Google Kubernetes Engine (GKE)

Any modern Kubernetes version is supported, and the container can use current Linux distributions. SFTPPlus MFT can also run in native Windows containers, which we use every day to test SFTPPlus across various Windows environments. See the system requirements documentation for more details about supported operating systems.

Install SFTPPlus MFT with Helm or Kubernetes manifests ​

The SFTPPlus Helm chart is available for installing SFTPPlus MFT on Kubernetes. Teams that already use Helm can manage the installation through their existing deployment workflow.

The SFTPPlus Kubernetes repository provides example Kubernetes resources for single-pod, autoscaled, and persistent-storage deployments. Use them as a starting point and adapt their namespaces, storage classes, network services, and resource settings to your cluster.

The SFTPPlus Docker repository contains the container build files, entry point, and configuration examples used to create an SFTPPlus image. This gives your team control over the image build and the SFTPPlus version deployed in each environment.

The following deployment manifest is a partial snippet that illustrates a two-replica worker configuration. It is not a self-contained example: the namespace, persistent volume claim, ConfigMap, Secret, and initialization script need to be created separately.

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
    name: sftpplus-worker
    namespace: manual-tests
    labels:
        app: sftpplus-worker
spec:
    replicas: 2
    selector:
        matchLabels:
            app: sftpplus-worker
    template:
        metadata:
            labels:
                app: sftpplus-worker

        spec:
            securityContext:
                runAsUser: 1000
                runAsGroup: 1000
                fsGroup: 1000
                fsGroupChangePolicy: 'OnRootMismatch'
            containers:
                - name: worker
                  image: proatria/sftpplus-trial:5.26.4-linux-x64
                  command: ['/bin/sh']
                  args: ['/opt/sftpplus-initialization/worker-init.sh']
                  ports:
                      - name: sftp
                        containerPort: 10022
                      - name: https-files
                        containerPort: 10443
                  volumeMounts:
                      - name: sftpplus-storage
                        mountPath: /opt/sftpplus-storage
                      - name: sftpplus-initialization
                        mountPath: /opt/sftpplus-initialization
                      - name: sftpplus-worker-credentials
                        mountPath: /opt/sftpplus-worker-credentials
                        readOnly: true
            volumes:
                - name: sftpplus-storage
                  persistentVolumeClaim:
                      claimName: sftpplus-storage
                - name: sftpplus-initialization
                  configMap:
                      name: sftpplus-initialization-v1
                - name: sftpplus-worker-credentials
                  secret:
                      secretName: sftpplus-worker-credentials

Manage configuration with GitOps ​

The SFTPPlus .INI configuration file can be supplied through a Kubernetes ConfigMap. Cluster secrets can provide sensitive files and values separately from the main configuration. This separation lets teams review deployment and application configuration while keeping credentials out of version control.

GitOps controllers such as Argo CD can apply the container, ConfigMap, Secret references, storage, and network service from the same reviewed repository. For more detail about configuration workflows and command-line automation, see the DevOps and GitOps solution.

Scale and keep transfers available ​

Kubernetes services and external load balancers can distribute incoming connections across SFTPPlus replicas. SFTPPlus cluster support synchronizes configuration between instances and centralizes events on the primary node. Persistent or shared storage can be selected according to how files need to be accessed across replicas.

This allows a deployment to scale file transfer volume by adding instances and maintain availability by load balancing incoming connections. Operators can review component status through Web Manager while Kubernetes manages pod placement and network access.

Explore deployment guides ​

Browse all Kubernetes articles for configuration, storage, and deployment examples.