Disclosure: I built systemprompt.io. One of its core design decisions was self-hosted deployment. I will explain why that decision was made, where the tradeoffs are, and where SaaS governance genuinely makes more sense. I have tried to be fair about the operational burden self-hosted requires.

This guide is the pillar for our enterprise AI governance cluster. It covers the architectural case for self-hosted deployment, regulatory drivers, a vendor comparison, infrastructure requirements, a worked air-gapped deployment walkthrough, troubleshooting, and a cost-of-ownership model. For deeper material on adjacent topics (tool comparisons, audit trails, secret detection, OWASP controls, gateway security, and head-to-head competitor breakdowns), see the linked sibling guides at the end.

The Deployment Problem

Here is an uncomfortable question: where does your AI governance data live?

Not your AI model data. Not your application data. Your governance data specifically. The logs that record which users accessed which AI agents, which tools those agents called, what parameters were passed, what policies were evaluated, and what the outcomes were.

For most enterprises in 2026, the answer is "in someone else's cloud." Most AI governance products are delivered as SaaS. You configure policies through a web dashboard, your agents report activity to the vendor's API, and your governance data sits in the vendor's infrastructure.

Think about what that data contains. It is a complete record of how your organisation uses AI. Which departments use AI agents. What data those agents access. Which tools they call. What parameters they send. How much they spend. What gets blocked and what gets through. It is, in effect, a detailed map of your organisation's AI operations.

For a software company shipping a consumer product, this tradeoff might be acceptable. The vendor manages the infrastructure, handles updates, provides support, and the governance data is not particularly sensitive.

For a bank, a hospital, a defence contractor, or a government agency, this is a non-starter. The governance data itself is sensitive. It reveals operational patterns, data access patterns, and security boundaries. Sending it to a third-party cloud is not a technical concern. It is a compliance violation.

This is the deployment problem. The tools that are supposed to help you govern AI responsibly are asking you to send your governance data, the most operationally sensitive data about your AI usage, to infrastructure you do not control.

Who Needs Self-Hosted

Not everyone. Let me be clear about that. Self-hosted governance adds operational complexity. If you do not need it, do not take on that burden. Here is who genuinely needs it.

Financial Services

Banking regulators in most jurisdictions require that customer data and operational data remain within defined boundaries. The UK's FCA, the EU's DORA regulation, and US federal banking regulators all have data residency requirements that apply to systems processing customer information.

AI governance logs that record "agent X queried customer account Y with parameters Z" contain customer data by reference, even if the actual customer record never leaves your database. The governance log reveals that the query happened, which customer was queried, and what the purpose was. Regulators consider this operational data, and it is subject to the same residency requirements as the underlying customer data.

Financial institutions also face audit requirements that demand complete chain-of-custody for operational data. If your auditor asks "can you prove that no one outside your organisation has accessed the governance logs?" and the logs are in a vendor's cloud, the honest answer is no. You trust the vendor, but you cannot prove it.

Healthcare

HIPAA's Security Rule requires that covered entities maintain physical and technical safeguards for systems that process electronic protected health information (ePHI). An AI agent that can access patient records, clinical notes, or lab results through tool calls generates governance logs that reference that ePHI.

The governance log itself might not contain the patient record, but it contains the query that accessed it, the user who initiated it, and the result summary. Under HIPAA's broad definition of ePHI, this is protected information. It needs the same safeguards as the patient record itself.

Self-hosted governance keeps these logs within your existing HIPAA-compliant infrastructure. The same physical controls, access controls, and audit mechanisms that protect your clinical systems protect your AI governance data.

Government and Defence

Government agencies and defence contractors operate under classification regimes that prohibit certain categories of data from leaving controlled environments. Even unclassified operational data about AI usage patterns may be considered sensitive in a defence context.

The UK's Official Sensitive classification, the US government's Controlled Unclassified Information (CUI) designation, and NATO's classification system all impose handling requirements that are incompatible with storing data in a commercial SaaS platform. Air-gapped deployment is not a preference. It is a requirement.

Data Sovereignty

The EU's GDPR, Brazil's LGPD, and India's DPDP Act all impose data residency requirements for personal data. AI governance logs that contain user identifiers, user actions, and user behavioural patterns are personal data under these regulations.

If your organisation operates in the EU and your AI governance vendor stores data in the US, you have a data transfer problem. Schrems II invalidated the Privacy Shield. Standard Contractual Clauses require a Transfer Impact Assessment. Self-hosted governance on EU infrastructure eliminates the problem entirely. The data never leaves the jurisdiction.

The matrix below compares what four regulatory regimes actually require of governance data that leaves a controlled environment. Read it as a decision aid: if your organisation operates under any of these regimes, the self-hosted case is not a preference but a mapping exercise.

Regime Data residency rule Cross-border transfer mechanism Applies to governance logs? Source
EU AI Act Art. 10 Data governance applies to training, validation, and testing data sets; operational logs under Art. 12 Not a transfer rule per se; interacts with GDPR Chapter V for personal data Yes, when logs contain personal data or are evidence for high-risk system operations EU AI Act Art. 10, EUR-Lex
GDPR Art. 44-49 Transfers outside EEA permitted only with adequacy decision, SCCs, or derogation Adequacy decision, Standard Contractual Clauses plus Transfer Impact Assessment, or Art. 49 derogation Yes, when logs contain user identifiers or activity records GDPR Chapter V, EUR-Lex
NIST SP 800-53 Rev. 5 SC-7 boundary protection; AC-4 information flow enforcement across authorisation boundary System-to-system interconnection agreements (CA-3); ICA documentation Yes, when governance system is inside the authorisation boundary NIST SP 800-53 Rev. 5, AC-4 / SC-7
CCCS ITSG-33 (Canada) Information categorisation drives boundary controls; protected/classified data remains in Canada Government of Canada cloud usage profile; domestic-only for classified Yes, when logs reference protected or classified operational data CCCS ITSG-33

Data sources: regulator and standards-body pages linked above; provisions summarised against the public text of each regime, as of 2026-04. Counsel should verify applicability for specific use cases.

Deployment Model Comparison

Not all self-hosted options are equal. Here is how the current AI governance landscape breaks down by deployment model.

Solution Deployment Model Dependencies Air-Gap Support Deploy Time
Credo AI SaaS only N/A (vendor-managed) No Days (onboarding)
Rubrik Agent Govern SaaS only Rubrik ecosystem No Weeks (onboarding)
IBM watsonx.governance SaaS / Private cloud IBM Cloud Pak Partial Weeks
Claude Enterprise SaaS + Bedrock option AWS Bedrock for model hosting No (governance is SaaS) Hours
Microsoft AGT Self-hosted (open-source) Kubernetes, Redis, PostgreSQL, multiple services Yes (with effort) Days
systemprompt.io Self-hosted / Cloud PostgreSQL only Yes Minutes

Data sources: vendor documentation (Credo AI, Rubrik, IBM watsonx.governance product pages), Microsoft AGT GitHub repository, Anthropic Claude Enterprise documentation, as of 2026-04.

A few clarifications on this table.

Claude Enterprise with Amazon Bedrock hosts the AI model in your AWS account, which addresses data residency for inference. But the governance features (usage controls, permission management, audit logs) remain in Anthropic's cloud. You get data sovereignty for model interactions but not for governance data. This is an important distinction that is easy to miss in the marketing.

Microsoft's Agent Governance Toolkit is genuinely self-hosted and open-source under the MIT licence. You can deploy it entirely within your infrastructure. The "with effort" qualifier on air-gap support reflects the reality that AGT's full deployment involves multiple services (policy engine, identity provider, sandboxing runtime, event store) running on Kubernetes. Getting all of that running in an air-gapped environment is achievable but requires significant platform engineering effort. You are building a governance platform from components, not deploying a finished product.

IBM watsonx.governance can run on IBM Cloud Pak for Data, which supports private cloud deployment. Whether it truly supports air-gapped operation depends on the specific Cloud Pak configuration and IBM's licensing requirements. Consult IBM directly for air-gapped deployments.

What Air-Gapped Means in Practice

The term "air-gapped" gets thrown around loosely. Some vendors use it to mean "deployed in your VPC." That is not air-gapped. Air-gapped means zero outbound network connections. No telemetry. No update checks. No cloud API calls. No licensing server heartbeats. No DNS lookups to external domains. The system operates entirely within a network that has no route to the public internet.

For a software system to run air-gapped, it must satisfy several requirements that most modern software does not.

No Phone Home

No telemetry collection. No usage reporting. No crash reporting to external services. No anonymous analytics. Many SaaS platforms that claim "optional telemetry" still require periodic connection to a licensing server. In an air-gapped environment, periodic means never. The software must function indefinitely without any outbound connection.

Self-Contained Authentication

The system must issue and validate authentication tokens without relying on an external identity provider. In a connected environment, you might delegate authentication to Auth0, Okta, or Azure AD. In an air-gapped environment, the authentication system runs locally. This means the governance platform needs its own user management, its own token issuance, and its own token validation, all without calling external services.

Alternatively, the platform must integrate with whatever identity provider runs inside the air gap. Many government and defence networks run Active Directory or a SAML-based IdP internally. The governance platform needs to work with what is available inside the boundary.

Local Updates

Software needs updates. Security patches. Bug fixes. Feature additions. In a connected environment, you pull updates from a registry or repository. In an air-gapped environment, updates arrive on physical media or through a controlled transfer process. The software must support this update path, typically by accepting a new binary that replaces the existing one without requiring any external download or dependency resolution.

No External Dependencies at Runtime

The software cannot depend on external package registries, CDN-hosted assets, or cloud-based services at runtime. Every dependency must be bundled in the deployment artifact or available within the air-gapped network. This eliminates most solutions that use Node.js (npm install at startup), Python (pip install), or containerised deployments that pull images from external registries.

The Single-Binary Approach

One architectural answer to every constraint above is a single statically-linked Rust binary. Approximately 50MB. No runtime dependencies beyond PostgreSQL. No external library loading. No package manager. No container registry. Copy the binary to a Linux server, point it at a PostgreSQL database, and run it.

The binary is its own web server, its own API server, its own authentication system, and its own job runner. It issues and validates JWT tokens locally. It serves its own admin dashboard. It runs database migrations on startup. There is nothing to install, nothing to configure beyond the database connection, and nothing that reaches outside the network boundary.

This is not an accident of implementation. It is a design decision made specifically to support air-gapped deployment. Rust's compilation model produces self-contained binaries. Static linking eliminates dynamic library dependencies. Embedding all assets in the binary eliminates CDN requirements. Building authentication into the core eliminates external IdP requirements.

The result is a deployment model that works identically on a developer's laptop, a cloud VM, a bare-metal server in a data centre, and a classified workstation on an isolated network.

Infrastructure Requirements

For organisations evaluating self-hosted AI governance, the infrastructure question matters. What do you actually need to run this?

The Minimum

A Linux server with 2GB of RAM. A PostgreSQL 14+ database. The governance binary. That is the entire infrastructure requirement for a single-binary deployment.

The binary consumes approximately 80MB of RAM at idle and scales with concurrent connections. A server handling 50 concurrent users typically uses 200 to 400MB of RAM. CPU usage is minimal for governance operations. Policy evaluation is string matching and rule evaluation, not compute-intensive work.

PostgreSQL stores all governance data: audit events, policy configurations, user accounts, agent definitions, and skill content. A standard PostgreSQL deployment with daily backups satisfies the data persistence requirement.

Docker (Optional)

If your organisation standardises on containers, the binary runs as a Docker container. The image is the binary plus a minimal base layer. No runtime installation steps. No entrypoint scripts that download dependencies. The container starts in milliseconds.

services:
  systemprompt:
    image: systemprompt/systemprompt:latest
    environment:
      DATABASE_URL: postgres://user:pass@db:5432/systemprompt
    ports:
      - "8080:8080"
  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data

What You Do Not Need

You do not need Kubernetes. You do not need Redis. You do not need a message queue. You do not need a reverse proxy (the binary serves HTTPS directly if configured with TLS certificates). You do not need a separate job runner, a separate worker process, or a separate admin service. You do not need Node.js, Python, Java, or any runtime beyond the operating system kernel.

This is a deliberate design choice. Every additional dependency is a potential failure point, a security surface, and an operational burden. For air-gapped deployments specifically, every dependency is something that needs to be available inside the boundary. The fewer dependencies, the simpler the deployment.

Compare to Microsoft AGT

Microsoft's Agent Governance Toolkit, for comparison, requires Kubernetes for production deployment. The full deployment includes separate services for the policy engine, identity management, sandboxing, event storage, and the admin interface. Each service has its own configuration, its own scaling requirements, and its own failure modes.

This is not a criticism of AGT. It is an architectural difference that reflects different design priorities. AGT prioritises modularity and extensibility (you can replace any component with your own implementation). A single-binary approach prioritises operational simplicity (everything runs as one process with one configuration).

For organisations with mature platform engineering teams that already run Kubernetes in production, AGT's deployment model is familiar. For organisations without Kubernetes expertise, or those operating in constrained environments where Kubernetes is not available, the single-binary model is significantly simpler.

Compliance Implications

Self-hosted deployment is not just an operational preference. For several compliance frameworks, it is the architectural answer to specific regulatory requirements.

Before the framework-by-framework detail, here is where each framework directly speaks to governance-data locality, processing boundary, or audit evidence storage. The matrix below maps each framework to the specific provision that creates the self-hosted case.

Framework Governance-data locality Audit evidence storage Processing boundary Provision / Source
ISO/IEC 42001:2023 (AI management system) Implied via asset classification Required retention of AI system operational records Organisation-defined scope ISO 42001 standard page
NIST AI RMF 1.0 MAP-2.3, MEASURE-2.8 on data provenance GOVERN-1.6 documentation requirements Organisational context (GOVERN-3) NIST AI RMF 1.0
EU AI Act Art. 10 data governance; Art. 12 automatic logging Art. 12 retention obligations for high-risk systems Art. 61 post-market monitoring on operator infrastructure EU AI Act, EUR-Lex 32024R1689
NIST SP 800-53 Rev. 5 AC-4 information flow enforcement; SC-7 boundary protection AU-9 audit record protection; AU-11 retention System authorisation boundary (CA-3) NIST SP 800-53 Rev. 5
SOC 2 (TSC 2017) CC6.1 logical access; CC6.6 network boundary CC7.2 system monitoring records Defined in system description AICPA Trust Services Criteria
GDPR (EU 2016/679) Art. 5(1)(f) integrity and confidentiality; Art. 44-49 transfers Art. 30 records of processing Controller/processor roles, Art. 28 GDPR, EUR-Lex 32016R0679

Data sources: official regulator and standards-body pages linked above; citations verified against each framework's public text, as of 2026-04. Provisions summarised; consult the full text for authoritative interpretation.

SOC 2: Data Residency

SOC 2's Trust Services Criteria include provisions for data processing location. If your SOC 2 scope includes AI agent operations (and it should if agents access customer data), the auditor will ask where governance data is processed and stored. Self-hosted governance gives a straightforward answer: the same infrastructure as everything else, under the same controls, in the same compliance boundary.

ISO 27001: Information Security Controls

ISO 27001 requires organisations to identify and control information assets. AI governance data (audit logs, policy configurations, user activity records) is an information asset. Annex A control A.5.10 (acceptable use of information) requires that information assets are handled according to the organisation's classification scheme.

If your classification scheme says operational security data stays on-premise, self-hosted governance satisfies that requirement by design. If governance data is in a vendor's cloud, you need to demonstrate that the vendor's controls meet your classification requirements, which is possible but adds complexity to every audit cycle.

HIPAA: Technical Safeguards

HIPAA's technical safeguard requirements (45 CFR 164.312) include access controls, audit controls, integrity controls, and transmission security for systems processing ePHI. Self-hosted governance means these safeguards are implemented by your organisation, under your control, auditable by your compliance team.

When governance data is in a vendor's cloud, the vendor's Business Associate Agreement (BAA) covers their obligations. But the covered entity (you) retains ultimate responsibility. Self-hosted governance eliminates the need to rely on a vendor's BAA for your governance data.

FedRAMP and Government Frameworks

For organisations pursuing or maintaining FedRAMP authorisation, the Authorisation Boundary is sacred. Every system within the boundary must meet the baseline's security controls. Adding a SaaS governance platform means either bringing it inside the boundary (which requires the vendor to have FedRAMP authorisation) or keeping it outside (which means governance data crosses the boundary).

Self-hosted governance runs inside the boundary. It is subject to the same controls as everything else. No boundary crossing. No vendor authorisation dependency. No data flow diagrams with arrows pointing outside your infrastructure.

The Tradeoff

I would be dishonest if I did not address this directly. Self-hosted governance means you take on operational responsibility that SaaS platforms handle for you.

You Manage Updates

When a security patch is released, you need to apply it. On a SaaS product, the vendor patches and you benefit automatically. On self-hosted, you download the new binary, test it in staging, and deploy to production. A single-binary design simplifies this (replacing the binary and restarting the process is the entire update procedure), but the responsibility is yours.

For air-gapped environments, the update process is slower. The new binary needs to be transferred through whatever controlled media process your security boundary requires. This might take days rather than minutes.

You Manage PostgreSQL

PostgreSQL needs backups. It needs vacuuming. It needs monitoring. It occasionally needs version upgrades. If your organisation already runs PostgreSQL for other applications, this is not a new burden. If you are introducing PostgreSQL solely for AI governance, it is additional operational surface.

PostgreSQL is mature, well-documented, and widely understood. This is not a risky dependency. But it is a dependency that requires attention.

You Manage Availability

If the governance platform goes down on a SaaS product, the vendor's SRE team responds. On self-hosted, your team responds. For organisations that already run production infrastructure, this is standard operating procedure. For organisations that have moved most workloads to SaaS, this is a capability they may need to rebuild.

You Manage Security Patching

Self-hosted means you are responsible for the security posture of the governance platform. When a CVE is published that affects a dependency, you need to apply the patch. For connected deployments, this is straightforward. Download the updated binary, test it, deploy it. For air-gapped deployments, the patch needs to traverse your controlled media transfer process, which may involve multiple approval steps and physical media.

The flip side is that you control the patching timeline. On a SaaS platform, the vendor patches when they decide to patch. If a critical vulnerability is disclosed and the vendor takes 72 hours to deploy a fix, you wait. On self-hosted, you can apply the patch as soon as it is available, on your schedule, with your testing process.

When SaaS Makes More Sense

If you are a startup or mid-sized company without data residency requirements, without regulatory mandates for self-hosted infrastructure, and without an air-gapped network, SaaS governance is simpler and probably the right choice. The operational burden of self-hosted deployment is only justified when the compliance or sovereignty requirements demand it.

There is no shame in choosing SaaS governance. The goal is to govern AI agents effectively, not to run infrastructure for its own sake. Choose the deployment model that your organisation can operate reliably.

The Decision Framework

Ask yourself three questions. First: does any regulation or policy require your governance data to remain within a specific boundary? If yes, self-hosted. Second: do you operate air-gapped or classified networks where the governance platform must run? If yes, self-hosted. Third: does your organisation have the operational capacity to manage a Linux server and a PostgreSQL database? If no, start with SaaS and migrate to self-hosted when you build that capacity.

Most organisations that end up self-hosting do not start there. They start with a SaaS platform, discover the data sovereignty implications during their first compliance audit, and migrate. Starting with self-hosted governance avoids that migration, but only if you have the operational maturity to support it from day one.

Worked Example: An Air-Gapped Deployment, Start to Finish

Abstract claims about air-gapped deployment are easy to make. What does the process actually look like? Here is a concrete walkthrough for a fictional defence contractor deploying a self-hosted governance binary into an isolated network.

The Target Environment

The contractor runs a classified development network on Red Hat Enterprise Linux 9 servers. The network has no outbound internet connectivity. Inbound transfer happens through a physical media transfer station operated by the security team. Patches, binaries, and software artifacts are manually reviewed, signed, and moved on write-once media. A PostgreSQL 16 cluster already runs inside the boundary for other applications. Authentication uses an internal SAML identity provider backed by Active Directory.

Step 1: Assemble the Artifact Outside the Boundary

On a staging machine with internet access, download the binary and compute a SHA-256 checksum.

curl -L -O https://example.invalid/releases/governance-2026.04.0-linux-x86_64
sha256sum governance-2026.04.0-linux-x86_64 > governance-2026.04.0.sha256

Package the binary together with its signature, checksum, and the database migration SQL exported from the binary itself (./governance-2026.04.0-linux-x86_64 migrations dump > migrations.sql). The entire deployment artifact is three files totalling under 60MB.

Step 2: Security Review and Transfer

The security team ingests the artifact into their review pipeline. Antivirus scans. Static analysis. Manual review of the release notes. Once approved, the artifact is written to a write-once USB device, sealed in a tamper-evident bag, and hand-carried to the classified network operations centre. This process commonly takes between two hours and two days depending on the organisation's controls.

Step 3: Deploy the Binary

Inside the boundary, a system administrator copies the binary onto a dedicated governance host. No package manager. No network install. No dependency resolution.

install -m 0755 governance-2026.04.0-linux-x86_64 /usr/local/bin/governance
mkdir -p /etc/governance /var/lib/governance /var/log/governance

Create a minimal configuration file pointing at the existing PostgreSQL cluster:

# /etc/governance/config.toml
[database]
url = "postgres://governance:REDACTED@pg.internal.mil:5432/governance"

[server]
bind = "0.0.0.0:8443"
tls_cert = "/etc/governance/tls/cert.pem"
tls_key  = "/etc/governance/tls/key.pem"

[auth]
provider = "saml"
metadata_url = "https://idp.internal.mil/metadata"

[audit]
retain_days = 2555  # seven years, matches existing CUI retention policy

A SAML metadata URL inside the boundary is fine. The governance binary is reaching a host inside the air gap, not the public internet.

Step 4: Run Migrations and Start the Service

governance migrate --config /etc/governance/config.toml
systemctl start governance
systemctl enable governance

Migrations run against the existing PostgreSQL database. The service starts. Logs stream to /var/log/governance/governance.log. Administrators log in via SAML, create their organisation, and register their first AI agent within minutes.

Step 5: Verify Zero Egress

This is the part most deployment guides skip. After the service is running, verify that it actually respects the air gap.

# Capture all outbound traffic from the governance host for 24 hours
sudo tcpdump -i any -w /tmp/egress.pcap 'not (dst net 10.0.0.0/8 or dst net 172.16.0.0/12 or dst net 192.168.0.0/16)' &
# ... run typical operations: register agents, invoke tools, query audit logs ...
# After 24 hours, inspect:
sudo tcpdump -r /tmp/egress.pcap | wc -l

If the tcpdump output is non-empty, the binary is making outbound connections and is not truly air-gapped. For a properly designed single-binary governance platform with built-in auth and no telemetry, the expected result is zero packets.

Record this verification as evidence for your accreditation package. Most regulators accepting air-gapped claims want to see a traffic capture proving the claim.

Step 6: Ongoing Operations

Updates follow the same path. A new binary is staged outside the boundary, security-reviewed, transferred on physical media, and deployed by replacing /usr/local/bin/governance and restarting the service. Database migrations run automatically on startup. There is no orchestration, no cluster upgrade, no blue-green deployment. The upgrade is a single file replacement.

Backups are handled by the existing PostgreSQL backup infrastructure. Monitoring is handled by the existing observability stack reading the binary's Prometheus metrics endpoint. Log aggregation ships the governance audit log to the existing SIEM. None of this is specific to AI governance. It is ordinary Linux server operation.

This is what self-hosted AI governance actually looks like when it is designed for the constraint. Six steps, one binary, no dependencies beyond PostgreSQL and whatever identity provider you already run.

Troubleshooting Common Self-Hosted Deployments

Most self-hosted governance failures fall into a small number of categories. The patterns below are the ones we see in real deployments.

Binary refuses to start: "failed to connect to database"

Ninety percent of the time this is a PostgreSQL auth problem. The binary is trying to reach the database but the credentials or the pg_hba.conf entry is wrong. Checklist:

  1. psql from the governance host to the database using the same connection string. If psql fails, so will the binary.
  2. Check pg_hba.conf for an entry allowing the governance host's IP range with md5 or scram-sha-256 authentication.
  3. Check that the database user has CREATE privileges on the schema. Migrations need to create tables on first run.
  4. If using TLS to the database, confirm the CA certificate is trusted by the governance host.

Authentication redirects fail with SAML identity providers

The most common cause is the binary advertising a public URL that the browser cannot actually reach. In air-gapped deployments, the governance host's public-facing hostname must resolve inside the boundary. If the SP metadata advertises https://governance.internal.mil/saml/acs but DNS inside the boundary does not resolve that name, the SAML assertion will be rejected.

Fix: configure the public_url explicitly in the governance config and ensure DNS resolves it from the browser network segment.

"Migration failed" on upgrade

This almost always means the database is on an older schema version than the new binary expects and a migration step failed partway through. The binary is idempotent across most operations but migrations are the exception. Checklist:

  1. Read the binary's log output for the specific failing migration.
  2. Check pg_stat_activity for blocking queries that prevented the migration from acquiring a lock.
  3. Roll back to the previous binary version, verify the service runs, then retry the upgrade during a maintenance window with no other database activity.

Agents cannot reach the governance API

Agents are calling the governance platform over HTTP or gRPC and the call is failing. Common causes:

  1. Firewall rule missing between the agent's network segment and the governance host.
  2. Agent is using a stale API token. Tokens rotate, clients cache, failures follow.
  3. Governance TLS certificate is self-signed and the agent process does not trust the CA. Install the CA certificate into the agent's trust store.

Audit log is filling disk

The audit log is voluminous by design. A busy agent fleet can produce tens of gigabytes of events per day. If disk usage is a problem:

  1. Configure log rotation on the file-based audit output if you use one.
  2. Ship audit events to your SIEM and rely on the SIEM for long-term retention. See the ai-agent-audit-trail-siem guide for SIEM integration patterns with Splunk, Elastic, and Datadog.
  3. Tune retention in the governance config. The default of seven years is appropriate for regulated industries but excessive for unregulated ones.

Tool calls are unexpectedly blocked

Policy evaluation is denying a tool call that the operator expects to succeed. This is usually a policy rule interaction, not a bug. Checklist:

  1. Open the policy decision audit for the specific blocked request. Every deny should include the rule that triggered it.
  2. Check rule ordering. The first matching rule wins in most policy engines.
  3. Check for deny-by-default policies. If a rule set has no explicit allow for the tool being called, the default action may be deny.

Policy-blocking patterns often surface the same risk categories as the OWASP Agentic AI Top 10, particularly excessive agency, tool misuse, and unbounded consumption. Mapping blocked events to those categories helps distinguish legitimate policy denies from misconfigured rules.

Total Cost of Ownership: SaaS vs Self-Hosted

The cost comparison between SaaS and self-hosted governance is rarely as clean as either vendor pitches it. Here is a realistic five-year model for an organisation running 200 AI agents across 500 users.

Cost Category SaaS Governance Self-Hosted Governance
Software licensing $120k/year ($600k/5y) $0 to $60k/year depending on vendor
Infrastructure (compute, storage) Included in SaaS $8k/year ($40k/5y)
PostgreSQL operations N/A $15k/year ($75k/5y) partial SRE allocation
Deployment and rollout $30k one-time (professional services) $40k one-time (internal engineering)
Upgrades and patching Included $10k/year ($50k/5y)
Compliance audit effort High (vendor controls in scope every audit) Low (internal controls already audited)
Incident response Vendor-led Internal-led
Data residency compliance May require paid premium region Built into infrastructure choice
Five-year total $630k plus premium region fees $205k to $505k

Data sources: author cost model drawing on vendor public pricing tiers, FedRAMP authorisation cost benchmarks, and SRE allocation norms for PostgreSQL operations; applicable 2026-04. Individual organisations will see variance based on existing platform engineering capacity.

The headline numbers favour self-hosted, but the comparison depends on factors that vary by organisation:

  1. Do you already run PostgreSQL? If yes, the $75k PostgreSQL operations cost is approximately zero. Your existing database team absorbs the governance database as one more schema.
  2. Do you already have an SRE function? If yes, the $50k upgrade and patching cost is approximately zero. Your existing runbooks cover one more service.
  3. What is the cost of a compliance finding? A single SOC 2 finding related to vendor data handling can cost more than five years of SaaS governance fees. This is rarely modelled in the comparison but is the largest financial driver in regulated industries.
  4. What is the value of deployment speed? If your compliance programme blocks deployment for 18 months pending vendor risk assessment, the opportunity cost of that delay dwarfs the software cost.

The honest answer is that self-hosted is cheaper for organisations that already run infrastructure and more expensive for organisations that do not. The breakeven point is usually around the scale where an organisation has a dedicated platform engineering team, which in practice means 200 engineers or more.

Common Pitfalls

Six failure modes account for most of the self-hosted governance mistakes we see.

Pitfall 1: Deploying on a single host with no backups. The governance database holds your audit trail. If the host dies and there are no backups, the audit trail is gone. Regulators will ask for it during the next incident. Run PostgreSQL with daily backups and tested restore procedures from day one.

Pitfall 2: Exposing the admin interface to the public internet. The governance platform has an admin dashboard. That dashboard should not be reachable from the public internet. Put it behind a VPN, an internal load balancer, or a zero-trust network access broker. Treat it like any other high-privilege internal tool.

Pitfall 3: Using a local filesystem for the audit log when you have multiple instances. If you run more than one governance instance for high availability, the audit log must live in a shared store. Most deployments use PostgreSQL, which solves this automatically. Deployments that use local file output break when events are written to two hosts that never reconcile.

Pitfall 4: Not testing the air gap. Vendors claim zero egress. Your deployment must verify zero egress. Run a packet capture on the governance host during normal operations and confirm no outbound connections escape the boundary. Document the result as compliance evidence.

Pitfall 5: Treating the governance platform as "install and forget." Self-hosted governance needs the same operational discipline as any production service. Monitoring, alerting, on-call rotation, patch management, capacity planning. "Install and forget" is how you end up with a three-year-old governance binary running CVEs you never noticed.

Pitfall 6: Buying self-hosted when you do not need it. Self-hosted governance is a specific answer to specific constraints. If your organisation has no data residency requirement, no air-gapped networks, and no mature platform engineering function, SaaS governance is almost certainly the right call. The worst outcome is an organisation that buys self-hosted because "it sounds more secure" and then operates it poorly, which is less secure than a well-managed SaaS deployment.

This guide is the pillar for the broader enterprise AI governance cluster. The sibling guides below each cover one specific aspect in depth:

Read the sibling guides in any order. Each stands alone and links back to this pillar.

How systemprompt.io Addresses This

systemprompt.io was designed from the first line of code for self-hosted deployment. Not as an afterthought. Not as a "private cloud option." As the primary deployment model.

Single binary. ~50MB, statically linked, zero runtime dependencies beyond PostgreSQL. Copy it to a server and run it. Millisecond startup. No installation procedure. No package manager. No container orchestrator. It runs on any Linux server from a Raspberry Pi to a cloud VM.

Zero outbound connections. The binary makes no outbound network connections. No telemetry. No update checks. No licensing calls. No CDN requests. Your firewall rules can block all egress from the governance server and it will continue to function indefinitely.

Built-in authentication. The platform issues and validates JWT tokens locally. No external IdP required (though integration with SAML and OIDC providers is supported for connected deployments). In an air-gapped environment, user management is local and self-contained.

Single-process architecture. No separate worker processes. No message queues. No background services to monitor. One process, one configuration file, one log stream. The operational model is as simple as the deployment model.

Upgrade path. Download the new binary. Replace the old one. Restart. The platform runs database migrations automatically on startup. There is no separate migration step, no version compatibility matrix, and no multi-step upgrade procedure.

For organisations evaluating self-hosted AI governance, the total cost of ownership calculation is straightforward. A Linux server, a PostgreSQL database, and the time to manage both. Compare that to the cost of demonstrating compliance when your governance data sits in a vendor's cloud, and for regulated industries, self-hosted wins on total cost even before factoring in the operational benefits.

See the self-hosted platform feature page for deployment documentation and the compliance feature page for framework-specific guidance.