Choose your deployment

Choosing your platform and topology for your CAST Imaging deployment

Overview

Before installing CAST Imaging, you need to make two decisions: which platform to run it on, and which topology - how many machines - to use. This page explains the trade-offs for each choice so you can select the combination that fits your infrastructure and team.

Choosing a platform

The right platform is usually the one that matches your existing infrastructure and operational skills. CAST Imaging supports four platforms:

Platform Best for Key characteristics Notes
Microsoft Windows Teams running Windows-only infrastructure Native Windows install; no container runtime required com.castsoftware.imaging.core (analysis engine) and a PostgreSQL instance must be obtained and installed separately
Linux with Docker Most Linux deployments; teams comfortable with containers Docker Compose-based; straightforward setup WSL 2 is supported for testing only, not production use
Kubernetes via Helm Cloud deployments (AWS, Azure, GCP) or teams with existing Kubernetes clusters Helm chart deployment; supports AWS EKS, Azure AKS, GCP GKE, and on-premises clusters Highest operational complexity; best when you need auto-scaling, cloud-native integration, or cluster-level isolation
Linux with Podman Environments requiring rootless or daemonless container runtimes Identical install media to Docker; additional Podman-specific prerequisites apply Beta support in 3.5.x; full support from 3.6.x onwards

Windows vs Linux containers

Choose Windows when your organisation has no Linux expertise, no container runtime available, or when security and patching policies favour native Windows services. All CAST Imaging components can be installed on a single Windows server or spread across multiple machines.

Docker vs Podman

If Docker is already in use in your environment, prefer Docker. Podman is a good fit when rootless or daemonless container operation is a hard requirement - for example, in environments where running a privileged daemon is not permitted. Be aware of the beta status of Podman support on 3.5.x if that version is relevant to you.

When to use Kubernetes

Kubernetes is the most capable option but also the most complex to operate. Choose it when one or more of the following applies:

  • You already manage a Kubernetes cluster and want to run CAST Imaging within that existing environment.
  • You are deploying in a cloud environment (AWS, Azure, or Google Cloud) and want to use the managed Kubernetes service provided by your cloud vendor - EKS, AKS, or GKE respectively - rather than provisioning and maintaining individual VMs. Using a managed Kubernetes service offloads cluster infrastructure management to the cloud provider and integrates naturally with cloud-native storage, networking, and identity services.
  • You need auto-scaling, high availability, or cluster-level workload isolation.

If you are evaluating CAST Imaging, or if you are deploying on cloud VMs without an existing Kubernetes cluster, Docker is a simpler starting point that requires less operational overhead.

Choosing a topology

Once you have chosen a platform, decide how to distribute CAST Imaging components across machines. The two topologies available on Windows and Docker are single-machine and multi-machine. Kubernetes deployments manage distribution differently through cluster scheduling and are covered in the Kubernetes installation guide.

Single-machine installation

All CAST Imaging components - imaging-services, imaging-viewer, dashboards, analysis-node, and PostgreSQL - run on one server.

  • Simpler to set up and maintain; no cross-machine networking to configure.
  • Suitable for proof-of-concept or evaluation, small teams, or environments where only one machine is available.
  • Trade-off: analysis is compute-intensive. On a shared machine it competes with other services for CPU and memory, which can affect both analysis speed and result browsing performance.

Multi-machine installation

Components are distributed across two or more machines. Typically imaging-services, imaging-viewer, dashboards, and PostgreSQL share one machine, while the analysis-node runs on a separate dedicated machine.

  • The analysis-node can be scaled horizontally: register multiple nodes to the same imaging-services instance to run analyses in parallel across multiple applications.
  • Suitable for production environments, large or numerous codebases, and teams that need analysis to run without impacting result browsing.
  • Trade-off: more machines to provision and maintain; network connectivity between machines must be correctly configured.

Quick-reference

Situation Recommended topology
Evaluation or proof of concept Single machine
Small team with few applications Single machine
Limited hardware budget Single machine
Production environment with many large applications Multi-machine
Dedicated analysis capacity required Multi-machine
Analysis performance affecting result browsing Multi-machine

Next steps

Review the CAST Imaging components overview if you need a refresher on what each component does and how they relate to one another. Then navigate to the installation guide for your chosen platform: