This guide describes how to deploy Prime Detect for a proof of value on a single Ubuntu machine using Minikube (a local, single-node Kubernetes cluster). Everything is driven by one script and one configuration file.

We learned from real client deployments that the same document has to serve two very different readers, so it is split into two tracks. Read the one that fits you — you do not need both.

Jump to Track A — Fast Install ·

Jump to Track B — Guided Walkthrough

One Ubuntu host running a local Minikube cluster with the full Prime Detect stack: a web UI and REST API, a PostgreSQL database, Apache Kafka (with a Kafka UI), a Logstash log-ingestion layer, and an Apache Flink stream-processing engine that applies Sigma rules to incoming events. When everything is up, you log in to the UI, point a log source at it, and watch detections appear — sub-second, in real time.

Times depend heavily on your hardware and your internet speed (the container images are pulled from Docker Hub). The numbers below are rough estimates for the recommended server.

Prime Detect is a real-time SIEM detection pipeline platform by SOC Prime. It applies Sigma rules to streaming events from Apache Kafka using Apache Flink, providing sub-second threat detection. Events arrive (via Logstash or directly into Kafka), Flink pipelines evaluate Sigma rules against them, and matches surface in the UI.

You do not install these by hand — the script does. The table is here so you recognize the names when you see them scroll past during deployment.

The deploy script also installs these command-line tools if they are missing (check-then-install):

Confirm each item before you touch the script:

There are three common ways to run the PoV. They differ only in who runs the script and whether/how TLS (HTTPS) is enabled. Pick one now; each track tells you exactly what changes for your choice.

For readers who know Docker and Kubernetes. If any command surprises you, switch to Track B — Guided Walkthrough, which explains every step.

Access (default ports): UI http://SERVER_HOST:4173, API:8000, Kafka UI:8080, K8s Dashboard:8443, Kafka broker SERVER_HOST:9094, Logstash:10501/:10510/:10520.

Set in .env: TLS_ENABLED=true, TLS_MODE=selfsigned. Then:

UI/API/Kafka-UI/Dashboard now serve HTTPS on the same ports (https://SERVER_HOST:4173, etc.). Browsers warn until you import the CA:

Put your PEM cert/key under certs/ (gitignored). Set in .env:

HTTPS on the FQDN with no browser warning (valid cert).

Then open the UI, log in (default admin@soc.local / admin), tune Pipeline Runtime settings, and create your first pipeline — see Step 9: From deploy to first detection.

This track assumes no prior Kubernetes or Kafka experience. It walks the whole deployment, tells you what each command does, what you should see afterwards, how long things take, and what to do when something looks wrong. Follow the steps in order.

Before opening a terminal, have these ready. Missing one is the most common reason a deploy stalls later.

Unpack the files SOC Prime provided to you (detectflow-oss-private-ubuntu-based.zip) and cd into the resulting folder:

All settings live in a file called .env. Copy the template, then open it in an editor (nano .env is fine):

You only need to touch a few values. The two that matter most for a first run are SERVER_HOST and the IMAGE_* tags.

All five images live in the same Docker Hub repo (socprimecom/detectflow), tagged by component.

TLS is off by default. If you are doing Profile 1, skip this step entirely — everything will serve plain HTTP. Come back and switch TLS on later if you want; you only edit .env and re-run.

When TLS is enabled, Traefik terminates TLS and the UI, API, Kafka UI and K8s dashboard serve HTTPS on the same port numbers (so http://…:4173 becomes https://…:4173). The Kafka broker and Logstash always stay plaintext.

Set in .env:

cert-manager issues a certificate from a self-signed CA, using SERVER_HOST as the certificate name (SAN). Browsers will warn until you import that CA (covered in Step 7). Good for a demo on a LAN by IP.

Use this when you have a valid certificate and want no browser warnings. Put the PEM files somewhere safe (for example under certs/) and set in .env:

Make the script executable and run it as your normal user:

If Docker was not already installed (or your user was not yet in the docker group), the script installs Docker, adds you to the group, and stops on purpose. You will see something like:

Activate the group membership, then run the script a second time:

The Prime Detect images are private, so the script needs a Docker Hub login to pull them. The credentials are temporary — they are never written to .env. You have two options.

Just run the script; it asks interactively (the token is hidden as you type):

The script now deploys the full stack as a numbered sequence (you will see headers like ═══ Step 2/15: Starting Minikube Cluster ═══). It installs any missing tools, starts Minikube, then installs each component in order. All Kubernetes manifests live in manifests/ next to the script; ${VAR} placeholders are filled from your .env at apply time. Nothing is fetched from external git repos, and no images are built locally — they are pulled from Docker Hub.

Roughly what happens, and what it is waiting for:

When the deploy finishes, the script prints a summary block: access URLs (with your SERVER_HOST filled in), the default login, the pod list, and the port-forward PIDs. For Profile 1 it looks like this:

The 10.11.14.59 above is only an example — yours shows whatever you set as SERVER_HOST. Every pod should read 1/1 Running.

The summary also lists port-forward PIDs, for example:

Those forwards are what make the services reachable from your browser. If they die (for example when your SSH session ends), restart them — see Part 5 → Useful commands. To stop them all at once: kill <PID> <PID> ... using the PIDs from your own run.

In a browser, go to the UI URL exactly as printed in your summary, then sign in with the default credentials:

After the stack is deployed and you log in to the Prime Detect UI, review the Pipeline Runtime settings and tune them to your system resources before you create or run a pipeline.

Settings to review:

These values significantly affect performance and resource usage. Adjust them as needed for your environment.

Refer to the screenshot below for an example configuration:

Settings → Pipeline Runtime, with example values for a PoV host.

The fastest way to prove the pipeline end-to-end is to push a sample event into Logstash. The syslog input listens on port 10501 and writes to the Kafka topic logstash-syslog. Replace SERVER_HOST with yours:

Prefer raw Kafka? Produce a structured event straight onto a topic with kcat (see Part 5 for the full example):

Read the topic back. If your event prints, ingestion works:

You can also watch this visually in the Kafka UI (SERVER_HOST:8080): open the topic and confirm the message count went up. Logstash auto-creates the logstash-* topics on the first event.

In the Prime Detect UI, a pipeline is what applies Sigma rules to a topic and produces detections. At a high level:

From here, see Part 6 — Where to Go Next for tuning, scaling, and day-2 operations.

Each entry is written as: what you see, what it means, and how to fix it. Start with the common-mistakes box — it covers most first-deploy surprises.

You see: You were added to the 'docker' group… re-run this script. Meaning: expected behaviour — the new group is not active in the current shell. Fix:

You see: Cannot talk to Docker daemon. Is it running? Meaning: you were added to the docker group, but the shell predates it (often after skipping the re-login above). Fix: log out/in or newgrp docker, then re-run. Verify with docker info.

You see: the deploy refuses to start Minikube as root. Meaning: Minikube's docker driver blocks root. Fix — either run as a normal user in the docker group:

…or force it (root + docker driver):

You see: pods stuck in Pending, scheduling/eviction messages, or Minikube failing to start. Meaning: the host does not have enough CPU/RAM/disk for the requested cluster. Fix: lower MINIKUBE_CPUS / MINIKUBE_MEMORY in .env to fit the host, then reset and redeploy:

You see: a pod that never reaches Running. Fix: inspect it — the events and logs almost always say why (no resources, bad image, failed dependency).

You see: a pod in ImagePullBackOff, or a long hang during the image-pull step. Meaning: a wrong image name/tag (Stopper #2) or invalid/insufficient Docker Hub credentials. Fix:

To re-create the pull secret, delete it and re-run:

Wait for all three cert-manager pods to be Running before the Flink operator installs:

Check the scheme first (Stopper #4): http:// for no-TLS, https:// for TLS. Then confirm the port-forward is alive (next item).

Meaning: the Traefik port-forward is not running (it can die when the deploy's shell/SSH session ends). Fix:

Meaning: Traefik is serving its built-in default. Fix: confirm the default TLSStore points at df-tls, and the secret holds the right cert, then reload Traefik:

Meaning: a leftover cert-manager Certificate is still reconciling the secret. The deploy deletes it automatically; to do it by hand:

Meaning: the certificate's SAN does not cover the name you are using. Fix: confirm SERVER_HOST matches the cert (openssl … -ext subjectAltName); for a wildcard use a sub-host, not the apex.

Meaning: TLS_SECRET_NAME was not rendered into the Traefik values. Fix: make sure you are running the current script (it exports the variable for envsubst).

Detailed material for both tracks: access URLs, the full TLS story, Kafka and Logstash access, and the commands you will reach for after deploy.

After deployment, the script sets up port-forwards (bound to PF_ADDRESS, default 0.0.0.0) and prints the URLs. Replace SERVER_HOST with the value from your .env (remote clients use the server IP/hostname; locally, localhost works).

Default login:

TLS is off by default. When enabled, Traefik terminates TLS so the UI, API, Kafka UI and K8s dashboard serve HTTPS on their existing ports (http://…:4173 becomes https://…:4173). The Kafka broker and Logstash stay plaintext. Set in .env:

Export the CA once and import it into your OS/browser trust store to remove the warning:

Change TLS_MODE (and the cert paths) in .env and re-run. App pods are not restarted; only the df-tls secret swaps. If the browser still shows the old cert, force a reload (restarts Traefik only, ~5s):

The deploy configures Kafka with two listeners:

The EXTERNAL listener advertises SERVER_HOST:9094 (from .env) and is port-forwarded on 0.0.0.0, so clients on other machines can produce/consume. Example (replace SERVER_HOST with the server IP/hostname):

If the port-forward dies, restart it:

Logstash runs three input listeners (port-forwarded on PF_ADDRESS, default 0.0.0.0). Each tags events with a type and writes them to a per-type Kafka topic logstash-<type>:

To test each input, send one event to its port (replace SERVER_HOST). Each command opens a TCP connection through bash's built-in /dev/tcp:

Verify the events landed in Kafka:

Logstash auto-creates the logstash-* topics on the first event (Kafka auto.create.topics.enable is on).

Once you have a first detection, here is how to get more value out of the PoV. These map to the menus you see in the Prime Detect UI.