Evaluator Installation

Evaluating Plexicus takes one command on a fresh Ubuntu VM — you will run it in Step 1 below, after copying the three files from your delivery package onto the VM. The installer sets up everything — Kubernetes (k3s), ingress, TLS, all secrets with per-install random passwords, the full Plexicus platform with bundled infrastructure (MongoDB, Redis, MinIO, PostgreSQL, Temporal), and a verified admin account. About 15 minutes later you log in and run your first scan.

note

Validated end-to-end on Ubuntu 24.04 LTS (amd64) with charts 1.2.19, 1.2.20, and the current 1.2.43 release. For production deployments follow the Production Installation guide instead.

Root or sudo access required. The installer must run as root (it installs k3s, Helm, and system-level services). If you SSH as a non-root user, you'll need sudo privileges to run the installation command.

This page is for a bare VM — not for a cluster you already run

The installer creates the Kubernetes cluster, on the machine you run it on. That makes it the wrong tool if you already have one:

• Already have AKS, EKS, GKE, or any other cluster? You cannot point this installer at it, and you do not need to — go to Production Installation, which installs the same platform onto your existing cluster with helm. You will get real TLS and your own domain instead of the self-signed evaluation certificates this page sets up.
• Want to evaluate on your cloud provider anyway? Create a plain Ubuntu 24.04 VM there (an Azure VM, an EC2 instance, a GCE instance) and run this installer on it. That works everywhere. It is the managed Kubernetes service that is out of scope, not the cloud.
• k3s is only in this path. It is a CNCF-certified Kubernetes distribution, bundled here so one command produces a working cluster. The Plexicus chart itself has no k3s dependency and nothing you deploy for production use involves it. Tear the whole thing down with /usr/local/bin/k3s-uninstall.sh.

What you need

Item	Details
A fresh VM	Ubuntu 24.04 LTS (amd64), 4 vCPU / 7 GB RAM / 40 GB disk (8 GB if you want a scan and an AI remediation to run concurrently — see Troubleshooting), root or sudo access required, ports 80/443 reachable from your workstation. Ports 80/443/6443 must also be free on the VM itself (the installer checks this locally before installing); 6443 is the Kubernetes API and does not need to be, and should not be, internet-reachable. Any cloud VM works (Hetzner CPX31, AWS t3.xlarge, GCP e2-standard-4, …).
CPU with AVX	The CPU exposed to the VM must support the AVX instruction set — the platform's bundled MongoDB (8.x) refuses to run without it. Every current cloud VM type has it. It only goes missing when you run the VM under your own hypervisor with a conservative virtual-CPU model (for example Proxmox's default kvm64, or a VMware cluster pinned to an old EVC baseline), which hides AVX from the guest even on modern hardware. Verify inside the VM before installing: grep -c avx /proc/cpuinfo — any number above 0 is fine. If it prints 0, set the VM's CPU type to host (or raise the EVC baseline to Sandy Bridge or newer) and power the VM fully off and on again — CPU flags are only renegotiated on a cold start, not on a reboot. See Troubleshooting for how the failure looks if you skip this.
Registry key	keys.json — a service-account key for the Plexicus image registry.
License	license.jwt — your evaluation license.
Settings file	plexicus-eval.env — the AI key Plexicus provides for your evaluation, plus any settings pre-set for you (chart version, domain). Point the installer at it with PLEXICUS_ENV_FILE.
AI key	Provided by Plexicus in your delivery package, inside plexicus-eval.env — powers finding enrichment, AI remediation, and AI SAST scanning. To use your own account instead, set PLEXICUS_AI_KEY explicitly; an explicit value always overrides the file.
SCM apps	Not needed to install. No GitHub, GitLab or Bitbucket app is required: your first scan runs through the built-in Sandbox connector. Register one later, only when you want to scan your own repositories — see Connect your own SCM.

Your delivery package — keys.json, license.jwt and plexicus-eval.env — was handed over by Plexicus when your evaluation was set up. If you do not have it, contact engineering@plexicus.ai.

1

Run the installer on the VM

Copy the three files from your Plexicus delivery package — keys.json, license.jwt, plexicus-eval.env — to the VM (e.g. scp keys.json license.jwt plexicus-eval.env root@<vm-ip>:/root/), then:

curl -fsSL https://docs.plexicus.ai/install.sh -o install.sh
sudo -E \
  PLEXICUS_ENV_FILE=/root/plexicus-eval.env \
  PLEXICUS_GAR_KEY_FILE=/root/keys.json \
  PLEXICUS_LICENSE_FILE=/root/license.jwt \
  bash install.sh

PLEXICUS_ENV_FILE is read before anything else the installer does, so every PLEXICUS_* setting delivered in plexicus-eval.env — including PLEXICUS_CHART_VERSION and PLEXICUS_DOMAIN — is what actually gets installed. Run without the remaining variables to be prompted interactively for whatever the file does not supply — the registry key, the license path and the AI key are the only three inputs the installer will ever ask you for. The installer is idempotent — re-running it after a failure or for an upgrade is safe.

The AI key comes from your delivery package

plexicus-eval.env carries the AI key Plexicus provides for your evaluation — it powers finding enrichment, AI remediation, and AI SAST scanning. Bring your own key by exporting PLEXICUS_AI_KEY when you run the installer: an explicitly-passed value — including an explicitly empty one (PLEXICUS_AI_KEY=, to skip the delivered key and be prompted instead) — always wins over the one in the file. The installer defaults to DeepInfra (https://api.deepinfra.com/v1/openai, model deepseek-ai/DeepSeek-V4-Flash); override PLEXICUS_AI_BASE_URL/PLEXICUS_AI_MODEL for a different provider.

The same precedence applies to every variable in the table below — the file is a set of defaults for your install, never an override of what you pass explicitly.

All options:

Variable	Default	Purpose
PLEXICUS_ENV_FILE	(none)	Path to plexicus-eval.env from your delivery package. Sourced first, so every PLEXICUS_* setting it contains applies — including PLEXICUS_CHART_VERSION and PLEXICUS_DOMAIN. Variables you export explicitly override it. The installer tightens the file to mode 600 (scp and unzip leave it at 644)
PLEXICUS_GAR_KEY_FILE	(required)	Path to the registry service-account JSON
PLEXICUS_LICENSE_FILE	(required)	Path to license.jwt
PLEXICUS_AI_KEY	from plexicus-eval.env	DeepInfra (or other OpenAI-compatible) API key — powers AI enrichment, remediation, and AI SAST. Provided by Plexicus in your delivery package; set it explicitly to bring your own
PLEXICUS_AI_BASE_URL	https://api.deepinfra.com/v1/openai	OpenAI-compatible endpoint
PLEXICUS_AI_MODEL	deepseek-ai/DeepSeek-V4-Flash	Model id at that endpoint
PLEXICUS_AI_SCAN_API_KEY	reuses PLEXICUS_AI_KEY	Chat LLM key for the AI SAST (SocratiCode) scan engine itself
PLEXICUS_AI_SCAN_BASE_URL	reuses PLEXICUS_AI_BASE_URL	Endpoint for the AI SAST scan engine's chat calls
PLEXICUS_AI_SCAN_MODEL	reuses PLEXICUS_AI_MODEL	Model id for the AI SAST scan engine's chat calls
PLEXICUS_AI_SCAN_EMBEDDING_API_KEY	reuses PLEXICUS_AI_KEY; prompted when a custom provider is set	Key for the embedding endpoint used when indexing repositories
PLEXICUS_AI_SCAN_EMBEDDING_BASE_URL	https://api.deepinfra.com/v1/openai	Endpoint for embedding calls
PLEXICUS_GITHUB_CLIENT_ID	(optional)	Client id of your GitHub App or OAuth App
PLEXICUS_GITHUB_CLIENT_SECRET	(optional)	Client secret of that App
PLEXICUS_GITHUB_APP_ID	(optional)	Numeric GitHub App id — GitHub App flow only
PLEXICUS_GITHUB_APP_INSTALLATION_URL	(optional)	https://github.com/apps/<slug>/installations/new
PLEXICUS_GITHUB_APP_PRIVATE_KEY_FILE	(optional)	Path to the App's private key .pem
PLEXICUS_GITLAB_CLIENT_ID	(optional)	Client id of your GitLab OAuth application (gitlab.com)
PLEXICUS_GITLAB_CLIENT_SECRET	(optional)	Client secret of that application
PLEXICUS_BITBUCKET_CLIENT_ID	(optional)	"Key" of your Bitbucket Cloud OAuth consumer
PLEXICUS_BITBUCKET_CLIENT_SECRET	(optional)	"Secret" of that consumer
PLEXICUS_DOMAIN	plexicus.local	Hostname to serve on (set a real DNS name, or plexicus.<vm-ip>.nip.io to skip /etc/hosts entirely)
PLEXICUS_ADMIN_EMAIL	admin@example.com	First admin account
PLEXICUS_ADMIN_PASSWORD	generated	First admin password
PLEXICUS_CHART_VERSION	1.2.43	Chart version to install

The nine SCM variables are a shortcut, not a requirement

Set them only if you already have the apps registered and would rather have the connector configured at install time than add it in the UI afterwards. A connector is written to the chart only when both its client id and its secret are present — a half-filled one would render a "Connect" button that can only fail at token exchange, so the installer warns and skips it. Leaving all nine unset is the normal path; see Connect your own SCM.

When it finishes, the installer prints the URLs, the admin credentials, the path of the evaluation CA certificate, and which SCM connectors (if any) it configured.

What the installer does (read the script before piping to root — we would)

The script is ~740 lines of plain bash at docs.plexicus.ai/install.sh. In order:

1. Delivery-package settings — if PLEXICUS_ENV_FILE is set, sources plexicus-eval.env before resolving any constant (so the chart version and domain it carries are the ones used), tightens the file to mode 600, and restores any PLEXICUS_* variable you passed explicitly so it wins over the file.
2. Preflight — root, amd64, ≥4 vCPU / ≥7 GB RAM / ≥40 GB disk, ports 80/443/6443 free.
3. k3s (traefik disabled) and Helm.
4. ingress-nginx as the ingress controller.
5. TLS — mints a local Plexicus Evaluation CA and per-host leaf certificates with proper CN and subjectAltName (Burp Suite and modern browsers reject certificates without them). No cert-manager needed.
6. Secrets — generates random per-install passwords (nothing shipped or documented publicly), creates the registry pull secret, the license secret, the two TLS secrets and the eight service secrets, all coherently.
7. Chart install — pulls chart 1.2.43 from the OCI registry and installs it with the bundled-infrastructure overlay (values-bundled-infra.yaml + values-evaluation.yaml) plus an override file containing your generated passwords and AI settings (/root/plexicus-eval/overrides.yaml).
8. Smoke tests — waits for fastapi, frontend and worker, then checks the frontend and api /health return HTTP 200 and the certificate CN.
9. Admin account — registers your admin user, then flips is_verified/role: admin directly in MongoDB. The evaluation overlay declares smtp.deliveryMode: "disabled", so no mail is sent and nothing fails silently — but a self-registration is never auto-verified in any delivery mode, and the admin-mediated invite path needs an admin that does not exist yet on a fresh cluster. Writing the flag is still the only way to create the first account. Every user after that should be invited from inside the platform, which hands you a verification link to pass on.

Generated credentials live in /root/plexicus-eval/credentials.env (mode 600). Uninstall everything with /usr/local/bin/k3s-uninstall.sh.

2

Point your workstation at the VM

The platform serves https://plexicus.local and https://api.plexicus.local (or your PLEXICUS_DOMAIN). On your laptop:

1. Add both names to /etc/hosts (skip if you used a real DNS name or nip.io):

   echo "<vm-ip> plexicus.local api.plexicus.local" | sudo tee -a /etc/hosts

2. Trust the evaluation CA so the browser — and Burp Suite, if you are pentesting the platform — accepts the TLS certificates:

   scp root@<vm-ip>:/root/plexicus-eval/plexicus-eval-ca.crt .

   Then import it into your trust store:

   • macOS:

     sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain plexicus-eval-ca.crt

   • Linux:

     sudo cp plexicus-eval-ca.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates

   • Windows (elevated prompt):

     certutil -addstore -f Root plexicus-eval-ca.crt

   • Firefox keeps its own trust store — import the file under Settings → Privacy & Security → Certificates → View Certificates → Import.

   • Burp Suite: Settings → TLS → CA certificates.

   The leaf certificates carry a proper CN and subjectAltName, so proxying through Burp works without TLS errors.

3

Log in and run your first scan

Open https://plexicus.local and log in with the admin credentials the installer printed.

Use the Sandbox onboarding flow — it scans a pre-configured vulnerable repository through a synthetic SCM connector, so it needs no OAuth app and no SCM connection at all:

1. Onboarding → Sandbox (or Applications → Add Repository → Sandbox).
2. Select the simplest-vulnerable repository and start the scan.
3. Watch findings appear in the dashboard — the scan takes 2–4 minutes, and AI enrichment fills in remediation guidance as it completes.

That is the whole evaluation path. Scanning your own repositories is the optional next step.

4

Connect your own SCM (optional)

Already installed? Nothing needs reinstalling

SCM connectors are added to a running deployment — this step happens after installation, whenever you choose. There is no install-time deadline: configure GitHub today, next week, or never. (The PLEXICUS_* install variables are just a shortcut for the same configuration.)

Skip this unless you want to scan your own repositories. Nothing above depends on it, and an evaluator with no SCM connected is a working evaluator.

GitHub — automatic (recommended). On a deployment with no GitHub App configured, Settings → Integrations → GitHub offers Create GitHub App automatically: the platform drives GitHub's App Manifest flow, GitHub creates and configures the App for you, and the credentials are stored and applied to the running deployment — nothing to copy, no restart. Two notes:

• The button is offered to the operator account — the one the installer created. Invited team members see a message asking them to contact their administrator instead.
• The generated App only gets webhooks when your domain is publicly resolvable — see SCM Connections.

GitLab and Bitbucket Cloud — register once, paste into the platform. Neither provider offers an API for creating an OAuth application, so unlike GitHub there is no automatic option: you register the app yourself, then enter its client id and secret under Connectors → Source Control → GitLab (or Bitbucket Cloud). The connector page shows the exact callback URL your registration must use — copy it from there rather than typing it, since a mismatch is rejected at token exchange rather than at registration.

Saving takes effect on the running deployment within a minute. There is no reinstall, no helm upgrade and no pod restart. The form is offered only to an operator account with the backoffice-settings admin permission; invited team members see the connector as unconfigured instead.

You can still pre-configure either provider at install time with the matching PLEXICUS_* variables from the table above — the values and callback URLs are identical either way, and anything you enter in the platform later takes precedence over what the installer wrote.

A hand-registered GitHub App follows the same pattern, under Settings → Integrations → GitHub — though on a deployment with no App configured the automatic flow above is almost always the faster path.

GitHub — register a GitHub App

A full GitHub App rather than a plain OAuth App is worth the extra minute: the platform has two separate GitHub OAuth flows — sign-in and the repo-scanning connector — that each need their own callback registered, and the App flow additionally enables webhooks and per-repository install/uninstall. On github.com: Settings → Developer settings → GitHub Apps → New GitHub App:

• Callback URLs (add both — use Add Callback URL for the second one):

  • https://plexicus.local/api/callback/github (sign-in)
  • https://api.plexicus.local/vulnerability-tool/callback/github (the repo-scanning connector — note the hyphen in vulnerability-tool)

  (your PLEXICUS_DOMAIN in place of plexicus.local if you changed it — the browser follows these redirects, so a .local name from /etc/hosts works fine)

• Request user authorization (OAuth) during installation: checked.

• Webhook → Active: unchecked — GitHub cannot reach a .local name, so push-triggered rescans are unavailable in this setup (manual and scheduled scans work). Use a publicly resolvable PLEXICUS_DOMAIN (e.g. plexicus.<vm-ip>.nip.io) if you want webhooks.

• Repository permissions: Contents and Metadata (read-only). Add Pull requests (read & write) to test remediation pull requests.

• After creating the app: note the App ID and the app slug (from its URL), generate a client secret, and generate a private key (a .pem file downloads).

• Install the app on your GitHub account or organization (https://github.com/apps/<slug>/installations/new) — that installation URL is one of the values Plexicus asks for.

To wire it in at install time instead, copy the .pem to the VM and pass:

sudo -E \
  PLEXICUS_ENV_FILE=/root/plexicus-eval.env \
  PLEXICUS_GAR_KEY_FILE=/root/keys.json \
  PLEXICUS_LICENSE_FILE=/root/license.jwt \
  PLEXICUS_GITHUB_CLIENT_ID=... \
  PLEXICUS_GITHUB_CLIENT_SECRET=... \
  PLEXICUS_GITHUB_APP_ID=123456 \
  PLEXICUS_GITHUB_APP_INSTALLATION_URL=https://github.com/apps/<slug>/installations/new \
  PLEXICUS_GITHUB_APP_PRIVATE_KEY_FILE=/root/github-app.pem \
  bash install.sh

GitLab — register an OAuth application

User Settings → Applications on gitlab.com (a self-managed GitLab instance is connected separately, per-connection, in the platform UI — this app registration only covers gitlab.com):

• Redirect URI: https://plexicus.local/api/callback/gitlab
• Scopes — grant all eight, which is what Plexicus requests: api, read_api, read_user, read_repository, write_repository, openid, profile, email
• After creating it: note the Application ID (client id) and Secret — PLEXICUS_GITLAB_CLIENT_ID and PLEXICUS_GITLAB_CLIENT_SECRET.

To connect a self-managed GitLab instead, skip these installer variables entirely and follow GitLab → Self-Hosted after the platform is up: you register the application on your own instance and enter its URL, client id and secret in the Plexicus UI.

Bitbucket Cloud — register an OAuth consumer

Workspace Settings → OAuth consumers → Add consumer:

• Callback URL: https://plexicus.local/api/callback/bitbucket_cloud
• Permissions: Repositories (Read), Pull requests (Write), Issues (Write), Account (Read)
• After creating it: note the Key and Secret — PLEXICUS_BITBUCKET_CLIENT_ID and PLEXICUS_BITBUCKET_CLIENT_SECRET.

Once a connector is configured, Applications → Add Repository lists your repositories.

Every other supported provider — GitHub Enterprise Server, self-managed GitLab, Gitea, Forgejo, Azure DevOps and TFVC — needs nothing at install time. Each of those connections carries its own credentials, entered in the UI under Connectors → SCM once the platform is running. The SCM Connection Reference lists the flow, callback URLs and scopes for all of them, and records that Bitbucket Server / Data Center is not supported.

Troubleshooting

The installer failed — where do I look?

The installer is verbose and dies with a specific error message. Re-running it is safe and resumes idempotently. The usual suspects:

• ImagePullBackOff on Plexicus pods → wrong or expired keys.json, or a chart version older than 1.2.19 (chart 1.2.19 was the first release whose default images all resolved in the customer registry — the installer now defaults to 1.2.43; pin 1.2.32 or later, since this installer no longer understands the single-file values-evaluator.yaml overlay chart 1.2.19 through 1.2.31 shipped).
• Registration failed / login 500 → kubectl -n plexicus logs deploy/fastapi; a crash-looping temporal-* pod during the first ~2 minutes is normal while the Temporal schema Job completes.
• Pods Pending → check RAM: kubectl -n plexicus describe pod <pod>. 7 GB is the tested minimum, and it is only enough with the evaluation profile applied — that overlay trims the standing footprint (one worker replica, no Temporal admin/web UI, no MinIO console) specifically to leave room for the scan and remediation Jobs the worker creates at runtime. A cluster installed without it will schedule the always-on services fine and then leave those Jobs Pending forever.
• A remediation or scan Job stays Pending while everything else is Running → kubectl -n plexicus describe pod <pod> will say Insufficient memory. These Jobs are created by the worker at runtime, not by the chart, so they are scheduled against whatever memory the always-on Deployments have not reserved. On a minimum-spec VM that budget is small enough that running a scan and a remediation at the same time may not fit — let one finish before starting the other, or give the VM more RAM. Their sizing is tunable without a rebuild via the worker's REMEDIATION_JOB_MEMORY_REQUEST / PLEXALYZER_JOB_MEMORY_REQUEST (and the matching _LIMIT) environment variables.

deploy/fastapi did not become ready and mongodb is in CrashLoopBackOff

If the installer ends with deploy/fastapi did not become ready (or deployment "fastapi" exceeded its progress deadline), check the database first — fastapi and worker cannot start without it and their errors are usually downstream noise:

kubectl -n plexicus get pods

When mongodb shows CrashLoopBackOff while redis-master, minio and temporal-postgresql run normally, and its logs are empty or stop right after the startup banner, the cause is almost always a missing AVX instruction set (see What you need): MongoDB 8.x aborts with an illegal-instruction signal before it can write a log line, so the crash looks silent. Confirm both halves in seconds:

grep -c avx /proc/cpuinfo    # 0 = AVX is not exposed to this VM
kubectl -n plexicus get pod -l app.kubernetes.io/name=mongodb \
  -o jsonpath='{.items[0].status.containerStatuses[0].lastState}'

"exitCode":132 (SIGILL) together with an AVX count of 0 confirms it. The fix is on the hypervisor, not in the VM: set the VM's CPU type to host (Proxmox) or raise the EVC baseline / enable CPU passthrough (VMware), then power the VM fully off and on — a reboot does not renegotiate CPU flags.

Two things to know before re-running the installer after this fix:

• The preflight requires ≥ 40 GB free disk. A partially-completed install already consumes ~14 GB, so on a minimum-size 40–50 GB disk the re-run can be blocked by disk space even though nothing else is wrong — grow the disk first if needed.

• If a previous run got as far as admin registration and failed, the retry can keep failing with an HTTP 422 mentioning E11000 duplicate key ... casbin_policies. Reset the database once and re-run — the installer rebuilds everything it needs:

  kubectl -n plexicus exec deploy/mongodb -c mongodb -- mongosh -u root \
    -p "$(kubectl -n plexicus get secret mongodb -o jsonpath='{.data.mongodb-root-password}' | base64 -d)" \
    --authenticationDatabase admin plexicus --eval 'db.dropDatabase()'

Scans stay at "Scanning in progress" forever

The AI credentials are wrong. Verify the key, endpoint and model that the installer wired in:

kubectl -n plexicus logs deploy/worker | grep -i "api_key\|openai"

The api_key client option must be set (or HTTP 401 from the AI endpoint) means the key/endpoint/model combination is invalid. Re-run the installer with the right PLEXICUS_AI_BASE_URL and PLEXICUS_AI_MODEL.

AI Remediation cannot be created — the AI connection test fails (400)

The Create Remediation flow first tests the remediation AI connection (POST /openai/connections/remediator/tests); a 400 there blocks the UI. Look for the tell-tale pair in kubectl -n plexicus logs deploy/fastapi:

Response testing OpenAI: {"error":{...,"code":"invalid_api_key"}}
AI provider returned HTTP 401: User is not authorized to access this resource

If scans and enrichment work but this test 401s, the AI provider label does not match the endpoint your key belongs to: the test endpoints dispatch on the label with per-provider request URLs. Installs made with an installer older than the current one hit exactly this. The current installer derives the label from PLEXICUS_AI_BASE_URL automatically — re-download and re-run it to fix an affected install:

curl -fsSL https://docs.plexicus.ai/install.sh -o install.sh
sudo -E PLEXICUS_ENV_FILE=/root/plexicus-eval.env PLEXICUS_GAR_KEY_FILE=... PLEXICUS_LICENSE_FILE=... bash install.sh

Create Remediation stays at "Creating…" and no fix ever appears

Installs made with an installer older than the current one are missing the post-install fixes for the remediation engine's network rules and the worker sizing, so remediation requests can never reach the engine. Re-download and re-run the installer — it is idempotent and applies the fixes without touching your data:

curl -fsSL https://docs.plexicus.ai/install.sh -o install.sh
sudo -E PLEXICUS_ENV_FILE=/root/plexicus-eval.env PLEXICUS_GAR_KEY_FILE=... PLEXICUS_LICENSE_FILE=... bash install.sh

If remediation still fails afterwards with the platform otherwise healthy, your evaluation license may predate the current feature set — request a refreshed license at engineering@plexicus.ai.

Connect GitHub fails with error_code=unknown (400 Bad Request on the callback)

The OAuth token exchange with GitHub is failing. Check, in order:

1. Client secret present? It must be non-empty in the fastapi Secret:

   kubectl -n plexicus get secret plexicus-fastapi \
     -o jsonpath='{.data.GITHUB_OAUTH_CLIENT_SECRET}' | base64 -d | wc -c

   0 means no GitHub client secret was ever configured on this install. Add the connector under Settings → Source Control, or re-run the installer with PLEXICUS_GITHUB_CLIENT_ID/PLEXICUS_GITHUB_CLIENT_SECRET set (see Connect your own SCM).

2. Callback URLs registered? The GitHub App needs both registered exactly: https://<PLEXICUS_DOMAIN>/api/callback/github (sign-in) and https://api.<PLEXICUS_DOMAIN>/vulnerability-tool/callback/github (the repo-scanning connector — note the hyphen). A mismatch or a missing one makes GitHub reject the exchange (redirect_uri_mismatch in kubectl -n plexicus logs deploy/fastapi).

3. Installs from before installer GitHub support (chart ≤ 1.2.32 era scripts) created the Secret keys under legacy names that chart 1.2.21+ no longer reads (GITHUB_CLIENT_SECRET, GH_APP_PRIVATE_KEY). Re-running the current installer recreates them under the canonical names (GITHUB_OAUTH_CLIENT_SECRET, GITHUB_APP_PRIVATE_KEY).

Browser or Burp rejects the TLS certificate

Import /root/plexicus-eval/plexicus-eval-ca.crt as described in Step 2. If you regenerated certificates, restart the ingress pods: kubectl -n ingress-nginx rollout restart deploy.

Manual installation

The installer on this page is a convenience for throwaway single-VM trials, not a deployment path — it exists so that one command turns a bare VM into something you can click around in. It is not used to deploy Plexicus for real use, and nothing it does is exclusive to it.

Production Installation is the standard deployment procedure, and it is entirely manual: helm, kubectl, openssl and curl against your own cluster, with external infrastructure, real DNS and certificates, OAuth apps, SMTP, and the environment preparation that surrounds them. If you are assessing, auditing, or documenting how Plexicus is deployed, that is the procedure to read — not this one. The chart also ships its own manual-path documentation (helm pull the chart and read docs/getting-started.md).