Saltar al contenido principal

Self-Hosted Plexicus

Plexicus can be deployed on any Kubernetes cluster using the official Helm chart (current release: 1.2.43), published as an OCI artifact to Google Artifact Registry. This section covers everything you need to install Plexicus on your own infrastructure — no support ticket required.

Which Kubernetes do I need?

Any CNCF-conformant Kubernetes at v1.25 or later — AKS, EKS, GKE, or an on-premises cluster. Plexicus ships as a standard Helm chart and does not require, prefer, or bundle a particular distribution.

The Evaluator Installation is the one exception, and it is not a product requirement: to turn a single bare VM into a working cluster in one command, that installer bundles k3s (a CNCF-certified Kubernetes distribution). It applies only to the throwaway trial VM. Nothing you deploy for real use involves k3s.

Running a hardened or vendor-specific distribution (OpenShift, RKE2, or a cluster under a restrictive Pod Security Admission profile)? Those are not part of our published validation matrix yet — contact engineering@plexicus.ai with your distribution and version and we will confirm the specifics for your environment.

No phone-home guarantee

A self-hosted Plexicus deployment does not send telemetry, analytics, or feedback data outside your cluster. Features that depend on Plexicus' own commercial services (billing, marketplace listings, product analytics) are disabled in this mode. Only the integrations you configure (your GitHub, your AI provider, your SMTP server) talk to external systems — and only to the endpoints you specify.

Choose Your Path​

"Self-hosted" and "on-premises" are the same thing

Plexicus has one self-hosted deployment. Whether you run it in your own datacentre or in a cloud account you control, it is the same product, the same chart and the same licence — deployment_type: on_prem either way. The only thing that differs is how far you are taking it: a quick evaluation on a single VM, or a production install on your own Kubernetes cluster. That is the choice below.

The opposite of self-hosted is not "on-prem", it is Plexicus-hosted SaaS.

Pick the guide that matches what you are trying to do:

🧪 I want to evaluate Plexicus locally​

You want to spin up Plexicus on a small Ubuntu 24.04 server (cloud VM or on-premise), click around, and see if it solves your problem. No GitHub, GitLab, or Bitbucket app is needed to install: your first scan runs through the built-in Sandbox connector, and SCM connectors can be added at any time afterwards from the UI (Settings → Integrations / Settings → Source Control). One command installs everything — a single-node Kubernetes cluster (k3s), TLS, secrets, the platform with bundled infrastructure, and an admin account. The guide shows the exact invocation (it points the installer at the three files from your delivery package). This is the path we validate end-to-end.

Requires a plain Linux VM you have root on. The installer builds the cluster itself, so it cannot run against a managed cluster you already have — if you are starting from AKS, EKS, or GKE, take the production path below instead.

→ Local Evaluation (Self-Signed)

🏭 I'm deploying to a production Kubernetes cluster​

You have a real cluster (AKS, EKS, GKE, on-premises, etc.) running Kubernetes v1.25 or later, a domain you own, and you want a TLS-enabled installation that your team will use day-to-day. You install with helm from your own workstation against whatever cluster your kubectl context points at — Plexicus does not install or replace your Kubernetes. The guide installs MongoDB, Redis, MinIO, PostgreSQL, and Temporal as separate Helm releases for maximum control over versions, lifecycle, and tuning. Bundled subcharts are also available as an alternative — see the guide for details.

This is the standard deployment procedure — the complete, manual sequence a customer follows, including the environment preparation that is not performed by the product.

→ Production Installation (Helm)

🔒 I'm deploying to an air-gapped or restricted environment​

Your cluster has no public internet access, or you need to mirror images to an internal registry, or you have strict egress controls.

This is not a separate installer. It is the Helm path above plus three additions: mirror the container images into a registry your cluster can reach, point the chart at that mirror with global.imageRegistry, and swap Let's Encrypt for your own internal certificate issuer. Read the Helm guide first, then apply this one on top. It works the same way on a managed cluster with locked-down egress (an AKS cluster pulling from Azure Container Registry, for example) as it does on a fully disconnected on-premises cluster.

→ Air-Gapped Installation

After Installation​

Once the platform is running and reachable, you'll want to configure provider integrations: SCM (GitHub, GitLab, Bitbucket, Gitea), AI (OpenAI or Azure OpenAI), email (SMTP), and OAuth login providers.

→ Configuration Reference

nota

Per-provider configuration guides are published incrementally as the chart stabilizes. The configuration index lists which guides are available today and what is coming next.

Getting Help​