On-premise Installation
On-premise deployments run P4SaMD entirely within infrastructure you own and manage. The platform is delivered as Kubernetes workloads, distributed as OCI container images. On-premise installations include the full Enterprise feature set.
Your team provisions the infrastructure listed below and operates it (backups, monitoring of the cluster and the database). The Mia-Care Support Team installs P4SaMD on it and performs every upgrade. Mia-Care also provides the release notes and a dedicated account manager.
Kubernetes is the standard and recommended runtime for on-premise deployments. P4SaMD can also run on a VM-based environment using Docker Compose, typically where Kubernetes is not a viable option or a lighter operational footprint is required. Docker Compose deployments are not self-serve. Suitability depends on your scale, availability requirements, and operational context, so the Mia-Care Support Team must complete a feasibility assessment before you proceed. Contact your account manager to initiate the assessment.
Prerequisites
Before the installation, confirm that your environment satisfies the requirements below.
Mandatory Requirements
These components must be present and correctly configured before installation.
| Component | Minimum Requirement | Notes |
|---|---|---|
| Kubernetes | v1.25 or later | Any CNCF-conformant distribution (EKS, GKE, AKS, RKE2, k3s, etc.). A dedicated namespace for P4SaMD. |
| Compute | 4.5 vCPU and 11 GB of memory available to P4SaMD | Sized on the limits of one replica per component; about 1 vCPU and 3 GB are reserved. |
| PostgreSQL | v13 or later | External database, managed or self-hosted. Three databases: application, identity (Keycloak) and AI gateway. The application database user must be neither superuser nor BYPASSRLS. |
| Object storage | S3-compatible API | AWS S3, MinIO, or another service exposing the S3 API with path-style addressing and access keys. Azure Blob Storage does not expose the S3 API. Only the platform reaches the bucket; users' browsers never do. |
| Ingress controller | Supports Kubernetes Ingress (networking.k8s.io/v1) | NGINX Ingress, Traefik, AWS ALB, etc. One hostname serves the application, the API and the sign-in pages. |
| TLS certificate | Valid certificate | For your custom domain. When P4SaMD is published on the internet, cert-manager is supported for automated provisioning. See Private installations otherwise. |
| Container registry access | Pull access | To the Mia-Care registry, and to quay.io, ghcr.io and docker.io for the bundled open-source components, directly or through an internal mirror |
| SMTP server | Any standards-compliant relay | For email notifications, password reset, and account invitations |
P4SaMD needs no persistent volumes: all data lives in PostgreSQL and object storage.
Sign-in is provided by a bundled Keycloak, installed with P4SaMD. Users are managed in it, and two-factor authentication (TOTP) is required. Federation with a corporate identity provider is not part of the standard installation; contact your account manager if you need it. When it is set up, users sign in with their organization account: inviting a user sends no email and creates no separate P4SaMD password, so the identity provider and its multi-factor checks always apply.
P4SaMD can also be published under a path on a hostname shared with other applications, for example https://example.com/p4samd/, instead of at the root of its own hostname. Tell your account manager if you need this.
From v3.8, installations also include the Admin Console, a separate application for your installation operators. It has its own operator accounts with passkey-only sign-in, and manages organizations, users, memberships, licenses and permission overrides. Sensitive actions need a second operator's approval, and every action is recorded in an audit trail. Project members do not use it.
Private installations
P4SaMD does not have to be published on the internet. In that case cert-manager is not needed: the certificate can come from your internal certificate authority, as long as your users' devices trust it.
Users outside your network then need another way to reach the platform, such as a VPN. Set it up before the installation, and include the Mia-Care Support Team, who need access to install and upgrade P4SaMD.
Optional Requirements
These components are not required. They add specific capabilities.
| Component | Purpose | Notes |
|---|---|---|
| AI provider | AI-powered features (Whisper, compliance evaluation) | Needed only to use AI capabilities. Bring your own account with one of the supported providers: OpenAI, Anthropic, Google Vertex AI, or Azure OpenAI. P4SaMD does not provide or resell model access. The cluster needs outbound HTTPS (port 443) access to the provider's endpoint: api.openai.com (OpenAI), api.anthropic.com (Anthropic), the configured Vertex AI region endpoint such as us-central1-aiplatform.googleapis.com (Google Vertex AI), or your resource endpoint plus management.azure.com (Azure OpenAI). No external secrets manager is required: keys are stored encrypted in the platform database. A custom provider endpoint must use HTTPS and must not resolve to a loopback, link-local, or private address range. Egress must therefore reach the provider over a public endpoint rather than an internal gateway address. See AI Configuration for the setup steps. |
| Software composition data | SBOM enrichment | Outbound HTTPS access to api.deps.dev and packages.ecosyste.ms adds package metadata to imported SBOMs. Without it, SBOMs are imported without enrichment. |
| Secrets manager | Secret storage | Platform secrets are Kubernetes Secrets. They can be supplied by an external manager, such as HashiCorp Vault through External Secrets, instead of being created by the installation. |
Encryption keys (for stored AI provider keys and repository access tokens) are generated by Mia-Care during the installation and kept as Kubernetes Secrets.
Recommended Environments
Mia-Care recommends two installations: a non-production environment and a production environment. The non-production environment is not mandatory, but it is highly recommended.
Keep the two environments as similar as possible: same Kubernetes distribution, same PostgreSQL and object storage services, same network and access setup. Mia-Care then applies every upgrade and fix to the non-production environment first, and you verify it there before it reaches production.
Installation Overview
The Mia-Care Support Team installs P4SaMD with its Helm chart. The steps:
- Prepare the infrastructure (your team): satisfy the mandatory prerequisites, create the namespace and the three databases, and give Mia-Care access to the cluster.
- Configure the installation (Mia-Care): hostname, database connections, object storage, SMTP relay, and the generated secrets.
- Install (Mia-Care): the chart creates all Kubernetes resources. Database migrations run automatically when the services start.
- Verify (Mia-Care): all pods are ready, and
https://<your-domain>/-/inforeports the installed version. - Create the first organization (Mia-Care): the organization and its first administrator, who then invites the rest of your team.
Upgrades
P4SaMD follows semantic versioning. Each release comes with a Helm chart of the same version, its release notes, and any manual steps it needs.
Mia-Care performs upgrades with helm upgrade, on the non-production environment first when there is one. Database migrations run automatically. Take a database snapshot before each upgrade.
Support
On-premise customers receive a dedicated account manager and access to the Mia-Care support portal. For critical production issues, a priority support SLA is available as part of the Enterprise agreement.