Desktop vs. Platform How It Works Supported Stacks Customers Deployment About Us FAQ

On-Premise & Cloud Deployment

Choose SaaS or your own environment.

Use the hosted workspace when you want to avoid installation, or deploy MigryX on your infrastructure. Self-hosted and air-gapped operation have different setup and connectivity requirements; choose the option that fits your team.

Discuss deployment → Download MigryX Desktop (Free)

What stays where

SaaS

We host MigryX. Your team gets a login. You do not install anything.

Self-hosted

You run the container. Code and the database stay on your machine. Nothing is sent to us.

What you are installing

One container. Users only open a browser.

MigryX is a UI plus an engine. PostgreSQL lives inside the engine. Users never connect to the database, and you do not open a database port.

Users

Open a web browser. Nothing to install on their machines.

MigryX containerAL2023 or RHEL 9

UI

The screens users see. The only thing the browser talks to.

Engine

Runs conversion and validation. Only the UI calls it.

Python 3.12

JDK 21

PostgreSQL 17

Port 3174 is the only one you must open. Port 1443 opens VS Code for admins who need system access. PostgreSQL never leaves the container.

Security Posture

Zero-trust by design

MigryX is built for regulated environments. Every component runs inside your perimeter with no external dependencies.

🔒

Air-Gapped Operation

Fully disconnected deployment supported. No internet access required during analysis, conversion, execution, or validation.

🚫

No Outbound Connections

Zero external API calls. Zero telemetry. Zero phoning home. Every byte stays on your infrastructure.

📦

Container-Isolated

All processing (parsing, conversion, validation, and AI augmentation) executes inside a single container on your host.

🔐

SSL Everywhere

TLS encryption for VS Code, Jupyter, the nginx proxy, and the backend API. Use your own certificates.

🗃

Local PostgreSQL

Project metadata and audit logs stored in a local PostgreSQL instance. No external database connections. All data on local disk.

Container images

Two images. Pick the OS you already run.

Both images are OCI-compatible. The application inside is the same; the base OS is the difference.

Image 1

Amazon Linux 2023

The base operating system of the container. Use this build on AWS.

Image 2

Red Hat Enterprise Linux 9

The same application, on a Red Hat base. Use this build with Podman and OpenShift.

What is in the image

PostgreSQL 17Inside the engine. Not a port you open.

Python 3.12Runs the conversion and validation work.

JDK 21Java pieces shipped in the same image.

Host requirement

CPU cores

32 GB

RAM

100 GB

Disk

This is the size for the machine that runs the container, on a laptop, a VM, or a cluster node.

Ports

Access	Port	Required
UI	3174	Yes. This is the only port you need.
VS Code, for system access	1443	Optional. Open it only if operators need a shell in the container.

PostgreSQL, the API, and the rest stay inside the container. They are not extra host ports.

Load the image, then run it. Docker and Podman use the same steps. Publish 3174 for the UI and 1443 for VS Code. Mount a host directory so PostgreSQL and workspace files stay on the machine when the container is replaced. --restart=always brings the container back if it exits. Docker does that on its own. Podman also needs podman-restart.service enabled, or a reboot will leave it stopped.

Docker

# Load the image file you were given docker load -i migryx.tar # Run. 3174 is the UI, 1443 is VS Code. # Data stays in /data/newrh9 on the host. docker run -d --name migryx --restart=always \ -p 3174:3174 -p 1443:1443 \ -v /data/newrh9:/sas2py/app \ migryx:latest # Monitor docker ps docker logs -f migryx docker stats migryx # Stop and start. The host directory is kept. docker stop migryx docker start migryx

Podman

# Load the image file you were given podman load -i migryx.tar # :Z lets SELinux on RHEL label the mount. # Then enable the boot service once, as root: # systemctl enable --now podman-restart.service podman run -d --name migryx --restart=always \ -p 3174:3174 -p 1443:1443 \ -v /data/newrh9:/sas2py/app:Z \ migryx:latest # Monitor podman ps podman logs -f migryx podman stats migryx # Stop and start. The host directory is kept. podman stop migryx podman start migryx

Create /data/newrh9 before the first run and give the container user write access. /sas2py/app is the data directory inside the image. To use a named volume instead of a directory, create it with docker volume create migryx-data or podman volume create migryx-data, then mount migryx-data:/sas2py/app.

Get it running

Same image, on a host or in your cloud

Install a container runtime on the machine below, pull the Amazon Linux 2023 or RHEL 9 image, and publish port 3174.

On a machine you control

Windows 11 with Docker

Docker Desktop on Windows 11. The container is the same Linux image.

Windows 11

Docker

MigryX

Red Hat 9 with Podman

RHEL 9 host. Podman runs the RHEL 9 image without a Docker daemon.

RHEL 9

Podman

MigryX

CentOS with Docker

CentOS host with the Docker engine. Pull either image and publish the UI port.

CentOS

Docker

MigryX

Virtual machine in your cloud

VM on AWS

EC2 in your VPC, sized to 8 cores, 32 GB RAM, and 100 GB disk. Amazon Linux 2023 image fits here.

AWS VPC

EC2 VM

MigryX

VM on Azure

An Azure VM in your VNet, same size. Docker or Podman on the guest.

Azure VNet

Azure VM

MigryX

VM on Google Cloud

A Compute Engine VM in your VPC, same size.

GCP VPC

Compute Engine

MigryX

Managed containers

EKS or ECS

Amazon EKS for Kubernetes, or ECS when you want AWS to run the task. Give the workload the same 8 cores, 32 GB, and 100 GB.

AWS

EKS / ECS

MigryX

AKS

Azure Kubernetes Service. Expose the UI through a service or ingress. The VS Code port stays optional.

Azure

AKS

MigryX

GKE

Google Kubernetes Engine. Same container, same single UI port, optional VS Code port.

Google Cloud

GKE

MigryX

OpenShift

On-premises OpenShift, ROSA on AWS, or ARO on Azure. Use the RHEL 9 image. A Route publishes the UI. Add a second route only if you want VS Code for system access.

OpenShift Route

Project

MigryX pod

Network & Security

Runs inside your private VPC or VNet with private endpoints. No public internet egress.
Container images pulled from your private registry: ECR, ACR, or Artifact Registry.
Secrets managed in your key management service: AWS KMS, Azure Key Vault, or Google Cloud KMS.
Data stays in S3, ADLS, or GCS under your control.
Audit logs remain in CloudWatch, Log Analytics, or Cloud Logging.
TLS enabled for all local services with your own certificates.
Optional VPN or peering to on-premises networks for hybrid deployments.

AWS

VPC • PrivateLink • S3 • ECR • KMS • CloudWatch • IAM • Security Groups

Azure

VNet • Private Endpoints • ADLS • ACR • Key Vault • Log Analytics • AAD • NSGs

Google Cloud

VPC • Private Service Connect • GCS • Artifact Registry • Cloud KMS • Cloud Logging • IAM

Architecture Overview

Built for enterprise infrastructure

Three pillars that make MigryX deployment-ready for any environment, from a single Docker host to a multi-region Kubernetes cluster.

📦

Deployment

Single-container architecture. Amazon Linux 2023 or Red Hat Enterprise Linux 9. Run it with Docker on Windows 11 or CentOS, Podman on Red Hat 9, a cloud VM, EKS, ECS, AKS, GKE, or OpenShift.

Docker Podman K8s OpenShift Windows 11 + Docker

🔌

Connectors

Ingest from any legacy platform: SAS, Talend, Alteryx, DataStage, Informatica, ODI, SSIS, COBOL, Teradata, Oracle PL/SQL, and SQL dialects. Output to Databricks, Snowflake, BigQuery, PySpark, Polars, Fabric, DBT, and Python.

13 Sources 9 Targets JDBC/ODBC

🗃

Storage

Local PostgreSQL for project metadata, lineage graphs, and audit logs. Workspace files on the container filesystem with optional volume mounts for persistence. No external database dependencies.

PostgreSQL 17 Local Disk Volume Mounts

Security & Compliance

Enterprise-grade governance, built in

MigryX meets the security and compliance requirements of financial services, healthcare, government, and defense organizations.

🌐

Data Residency

All source code, converted output, lineage data, and metadata remain in your chosen environment: on-premises data center or private cloud region. No cross-border data movement.

👤

Access Control

SSO integration with LDAP, Okta, and SAML. Role-based access control for project-level permissions. Multi-factor authentication supported.

📋

Auditability

Complete audit trail for every conversion: who ran what, when, with which parameters, and what the output was. Logs stored locally in PostgreSQL and on disk.

📜

Governance

Column-level lineage, STTM mappings, data classification tags, and validation reports provide audit-ready evidence for SOX, GDPR, BCBS 239, and HIPAA.

💾

Backups

PostgreSQL and workspace data can be backed up with standard tooling: pg_dump, volume snapshots, or your existing enterprise backup solution.

🛡

Isolation

Each MigryX instance is fully isolated. No shared tenancy, no shared databases, no shared storage. Container-level network policies prevent lateral movement.

No container, no cloud

Install the software on the machine.

The same product, written onto the operating system. No Docker, no Podman, and no cloud account. Users still open a browser.

Red Hat VM 8 or 9

A virtual machine running Red Hat Enterprise Linux 8 or 9. MigryX is installed on that OS. Nothing else sits between the VM and the application.

RHEL 8 or 9 VM

MigryX software

Browser :3174

Windows 11

Windows 11 on a PC or a virtual machine. MigryX is installed as software on Windows. Docker Desktop is not required.

Windows 11

MigryX software

Browser :3174

Both installs use the same host size: 8 cores, 32 GB RAM, and 100 GB disk. Port 3174 is the UI. Port 1443 is VS Code for operators who need a shell. PostgreSQL stays on that machine. Data stays on its disk.

Ready to deploy?

See MigryX running in your environment. Book a 30-minute Platform Demo or download MigryX Desktop to analyze your code locally.

Book a Platform Demo → Download MigryX Desktop (Free)