Security AWS

Catalyst SOAR Incident Response Platform on AWS User Guide

| Product: Catalyst SOAR

Overview

This guide covers the deployment and configuration of Catalyst on AWS using cloudimg AWS Marketplace AMIs. Catalyst is an open source, self-hosted SOAR (Security Orchestration, Automation and Response) and incident-response platform for security teams. It gives a SOC one place to triage alerts, manage incidents, vulnerabilities and tasks, run playbooks and automations (reactions), keep case timelines and evidence, and work through a web console and a REST API.

The cloudimg image ships the free and open source, AGPL-3.0 licensed Catalyst, run the officially supported way as a single pinned Go binary. Catalyst stores everything in an embedded SQLite database and keeps evidence attachments as local file uploads, so there is no external database to run. The application binds to loopback only; an nginx reverse proxy terminates TLS on port 443 and forwards to it, and port 80 redirects to HTTPS. The incident datastore lives on a dedicated EBS volume mounted at /var/lib/catalyst, separate from the operating-system disk. Because an incident-response platform holds sensitive security data, nothing here ships with a known secret: a unique admin password, fresh session, token and reset secrets, and a per-instance self-signed TLS certificate are generated for each instance on first boot, before the platform is reachable. Backed by 24/7 cloudimg support.

Catalyst is a trademark of its respective owner. This image is produced by cloudimg and is not affiliated with, endorsed by, or sponsored by SecurityBrewery or Catalyst. It ships the free and open source AGPL-3.0 licensed self-hosted software, unmodified; the verbatim licence text and a pointer to the corresponding source ship inside the image under /usr/share/doc/cloudimg/third-party-licences.

What is included:

  • Catalyst v0.15.7, the upstream single-binary release, SHA256-verified at build time
  • An embedded SQLite datastore and local evidence uploads on a dedicated EBS volume at /var/lib/catalyst
  • An nginx reverse proxy terminating TLS on port 443, with the application bound to loopback 127.0.0.1:8090
  • A unique admin password and fresh session, token and reset secrets generated per instance on first boot
  • A fresh self-signed TLS certificate generated per instance
  • The security group opens only SSH (22) and HTTPS (443)
  • 24/7 cloudimg support

The Catalyst console sign-in page, served over HTTPS by the per-instance nginx TLS reverse proxy, showing the Catalyst logo, a Login heading and email and password fields

Connecting to your instance

This listing offers one or more operating-system variants. Connect over SSH as that variant's default login user, using your EC2 key pair:

OS variant Login user Example
Ubuntu 24.04 LTS ubuntu ssh -i your-key.pem ubuntu@<public-ip>

Step 1: Subscribe and launch from AWS Marketplace

  1. On the product page in AWS Marketplace, choose Continue to Subscribe, accept the terms, then Continue to Configuration.
  2. Choose the region and the m5.large instance type (recommended), then Continue to Launch.
  3. Under Network settings, attach a security group that allows inbound TCP 22 (SSH) from your IP and TCP 443 (the web console) from the addresses that should reach the platform. Restrict both to your own CIDR rather than the whole internet; an incident-response platform should not be world-open.
  4. Select your EC2 key pair and launch.

Step 2: Launch from the AWS CLI (alternative)

You can also launch the subscribed AMI directly. Replace the AMI id, key name, security group and subnet with your own:

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name your-key \
  --security-group-ids <sg-id> \
  --subnet-id <subnet-id> \
  --metadata-options "HttpTokens=required" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=catalyst-soar}]'

Then connect over SSH as ubuntu (see the table above).

Step 3: Confirm the services are running

SSH in as ubuntu and confirm the core services are active:

systemctl is-active catalyst.service nginx.service

Both units report active. The application listens on loopback 127.0.0.1:8090 and is reached only through the nginx reverse proxy; from outside the instance only 443 (HTTPS) is served, and 80 redirects to it:

sudo ss -tln | grep -E ':(443|8090) '

The embedded SQLite datastore lives on its own dedicated EBS volume, separate from the OS disk:

findmnt /var/lib/catalyst

Step 4: Retrieve your per-instance credentials

A unique admin password is generated on the first boot of every instance and written to a root-only file, alongside the console URL:

sudo cat /root/catalyst-credentials.txt

The file (mode 0600 root:root) holds CATALYST_URL, CATALYST_ADMIN_EMAIL (admin@catalyst.local) and CATALYST_ADMIN_PASSWORD. None of these ship in the image; every value is unique to this instance, so no two instances share a credential and there is no default login. Catalyst also generates fresh session, token and reset secrets in the database on first boot.

Step 5: Sign in to the console

Open the console in your browser at https://<public-ip>/. The certificate is a per-instance self-signed certificate, so your browser will warn once; accept it to continue. Sign in with the email and password from the credentials file.

The Catalyst dashboard summarising open tickets, tasks, users and reactions, with tickets-by-type and tickets-per-week charts

Step 6: Triage alerts and manage incidents

Catalyst organises work as tickets of different types, alerts, incidents and vulnerabilities, each with its own severity, timeline and tasks. Use the sidebar to open the incident queue, where you can search, filter open or closed cases, and open New Ticket to raise one.

The Catalyst incident queue listing open incidents with severity indicators, a search box and open or closed filtering

Open a case to work it: set its status and assignee, edit the description, add tasks and attach evidence. This case view is the core of Catalyst incident-response case management.

A Catalyst incident case view showing the title, incident type, open status, description, a tasks section and a close-incident action

Step 7: Automate with reactions and use the API

Catalyst runs automations called reactions, and exposes a full REST API so you can create and update tickets from your existing tooling (SIEM, EDR, scripts). Every API request must carry a bearer token from POST /auth/local/login; unauthenticated requests are refused. python3 and python3-venv are installed so reaction Python actions run.

Security model

  • No known credential ships. On first boot, before the platform is reachable, Catalyst generates a unique admin password and fresh session, token and reset secrets for this instance, plus a per-instance self-signed TLS certificate. Default logins are rejected.
  • Loopback application, TLS front door. The application binds to 127.0.0.1:8090 only; nginx terminates TLS on 443 and is the only external exposure. The security group opens just SSH (22) and HTTPS (443).
  • Datastore on a dedicated volume. The embedded SQLite database and evidence uploads live under /var/lib/catalyst/catalyst_data on an independently resizable EBS volume, separate from the OS disk.
  • Clean first boot. Build-time state is wiped before the image is captured, so the database, incidents, secrets and TLS certificate are all created fresh on your instance.

You can confirm the front door end to end at any time. The reverse proxy serves the console over HTTPS and reports healthy, and plain HTTP redirects to HTTPS:

curl -sk -o /dev/null -w 'HTTPS health: %{http_code}\n' https://127.0.0.1/health

curl -s -o /dev/null -w 'HTTP redirect: %{http_code}\n' http://127.0.0.1/

Step 8: Replace the TLS certificate (optional)

The image ships a per-instance self-signed certificate at /etc/ssl/certs/catalyst-selfsigned.crt with its key at /etc/ssl/private/catalyst-selfsigned.key. To use a certificate trusted by your browsers, replace those two files with your own (for example from your internal CA or a public CA for a DNS name that points at the instance) and reload nginx:

sudo systemctl reload nginx

Step 9: Back up the datastore

Catalyst keeps everything under /var/lib/catalyst/catalyst_data (the SQLite database and evidence uploads) on the dedicated volume. Snapshot that EBS volume, or copy the data directory, to back up your cases:

sudo ls -la /var/lib/catalyst/catalyst_data

Managing the service

  • Check status: systemctl --no-pager status catalyst.service
  • The application binary is /usr/local/bin/catalyst; its systemd unit serves it on loopback 127.0.0.1:8090
  • Configuration is at /etc/catalyst/catalyst.env; the datastore is /var/lib/catalyst/catalyst_data on a dedicated EBS volume
  • The nginx TLS reverse proxy config is at /etc/nginx/sites-available/cloudimg-catalyst
  • The AGPL-3.0 licence text and source pointer ship at /usr/share/doc/cloudimg/third-party-licences

Support

cloudimg provides 24/7 technical support for this product by email and live chat, with a one-hour average response for critical issues. We help with deployment, TLS termination and certificate replacement, DNS, backups, user and playbook setup, and scaling.