Probo GRC Platform: Self-Hosting, APIs, and First CLI Use

Probo's GRC Scope and Intended Engineering Teams

Probo addresses the operational side of governance, risk, and compliance rather than serving as a static policy library. The README describes a platform for engineering and security teams that need to identify risks, track controls, assess vendors, manage data-processing records, run access reviews, conduct audits, collect evidence, and approve documents. Repository topics include SOC2, GDPR, ISO27001, ISO27701, ISO42001, and HIPAA, while the documented product capabilities include privacy assessments, Statement of Applicability records, audit programs, and compliance workflows.

The intended user is therefore not only an auditor. The design assumes some combination of engineering, security, privacy, and compliance work must be represented in a system that developers can access from a terminal or automation client. The web console is positioned as the daily interface, while the command line and APIs serve scripts, CI/CD workflows, and MCP-compatible agents.

That distinction matters because Probo is a platform to evaluate, not a one-time compliance checklist. Its feature set creates a larger adoption surface than a repository containing only SOC2 policy templates. An organization has to decide whether centralized records, review campaigns, evidence chains, document approval, and vendor tracking belong in one self-hosted system. It also has to account for the work required to keep those records current. Probo can represent the work, but the README does not claim that it removes the need for compliance judgment or internal control ownership.

Shared Data Access Across Probo's Go Backend and React Console

Based on the repository layout and technology table, Probo is a monorepo with a Go backend, PostgreSQL persistence, a React and TypeScript frontend, and several client interfaces. The backend exposes GraphQL and Model Context Protocol APIs. The repository contains `apps/`, `cmd/`, `internal/`, `pkg/`, and `packages/`, indicating that server code, command-line programs, internal packages, and shared or integration packages occupy separate areas.

The README states that every entity is available through the web console, the `prb` CLI, an MCP API, and GraphQL. That creates a common data-access model around GRC resources rather than limiting automation to exports. The CLI documentation says that `prb` covers more than 44 resource types, while the MCP documentation says that the platform exposes more than 270 tools covering entities and operations. The MCP contract is available in `pkg/server/api/mcp/v1/specification.yaml`, which is useful for teams that need to inspect supported operations before connecting an agent.

The local infrastructure follows the same self-hosted orientation. `compose.yaml` defines PostgreSQL, SeaweedFS with S3 support, Grafana, and Prometheus, and it publishes PostgreSQL on port 5432. The README also names Loki and Tempo as part of the observability stack, although the displayed Compose excerpt does not include every service. This is more infrastructure than a typical single-process application. The design gives an operator control over databases, stored objects, and telemetry, but it also creates backup, monitoring, patching, and capacity-management responsibilities.

Local Development Setup and First `prb` Commands

The README presents the following sequence as a local development setup, not as the production deployment procedure. It requires Go 1.27 or later, Node.js 24.15 or later, npm 12.0.2 or later, Docker, and mkcert. The `package.json` specifies the npm package manager as `[email protected]`, while `go.mod` declares Go 1.27.2. Clone with submodules because the development setup may depend on them, then download both Go and npm dependencies before starting the local services.

The next block builds Probo, generates its local configuration, and starts the server. The README says the web console should then be available at `http://localhost:8080`.

git clone --recurse-submodules https://github.com/getprobo/probo.git
cd probo
go mod download
npm ci
make stack-up
make build
make dev-config
bin/probod -cfg-file cfg/dev.yaml

For a first CLI action, authenticate and list open risks with the commands shown in the README. The `prb` client must be available and configured to reach the running instance before these commands can act on its data.

prb auth login
prb risk list

The README also shows control creation and evidence upload. Here, `<id>` is the placeholder used in the project example, not a documented identifier format.

prb internal-control create --name "MFA enforced on all production systems" --category "Security"
prb evidence upload ./screenshot.png --internal-control <id>

The repository refers developers to `CONTRIBUTING.md` for the complete development environment walkthrough, including the frontend development server and code generation. For production use, the README directs users to the self-hosting guide and identifies Docker Compose or Kubernetes as deployment choices.

CLI, MCP, GraphQL, and n8n Automation Boundaries

Probo's most distinctive design choice is the number of supported access paths. The `prb` CLI is documented as a client for scripting, automation, and CI/CD integration. Its resource commands cover the same broad GRC areas as the console, which makes targeted shell workflows possible without using the graphical interface for every operation.

MCP support is broader than a read-only reporting layer. According to the README, MCP clients can read and write GRC data, draft policies, run risk assessments, and generate evidence packs. That capability may fit an organization that wants an agent-assisted compliance workflow. It also makes permission design and agent configuration part of the adoption review. The README names policy-based RBAC and immutable audit logs as platform controls, but it does not provide an MCP-specific permission matrix. Teams should inspect `pkg/server/api/mcp/v1/specification.yaml` and the linked MCP setup documentation before granting write access.

The n8n community node takes a different path. It connects workflows to Probo over GraphQL and is intended for no-code automation. Compared with the CLI, n8n moves execution into a visual workflow runtime. Compared with MCP, it uses a fixed GraphQL-oriented node rather than general agent tool calls. The choice depends on where automation should live. The README does not document retry behavior, partial-failure semantics, credential rotation, or a rollback mechanism for these interfaces.

Operational Boundaries of a Self-Hosted Compliance Platform

The clearest limitation is operational scope. Probo is not described as a managed SaaS. Self-hosting it means the adopting organization must host and operate the server, database, object storage, and observability components. The development Compose file exposes PostgreSQL with the documented credentials `postgres` and `postgres`, which suits the described development environment but is not presented as production guidance. The README points production operators to a separate self-hosting guide instead of declaring this Compose file production-ready.

Feature breadth introduces another boundary. The platform includes risk scoring and treatment strategies, control maturity, vendor assessments, DPA and BAA tracking, DPIA and transfer assessments, rights requests, access review campaigns, audit findings, evidence, document signatures, public compliance pages, and cookie consent management. Each area introduces configuration and process decisions. A team that only needs a small control register may find that deployment, access design, workflow adoption, and ongoing data entry outweigh the benefit of one consolidated GRC interface.

The README is also silent on several details an engineer would normally need before production adoption. It does not state backup and restore procedures, supported upgrade paths, database migration policy, high-availability architecture, or a rollback procedure. Those topics may exist in the linked self-hosting documentation, but they cannot be inferred from the README. The stated audit features also should not be interpreted as automatic certification. The platform can track or collect records, but the repository does not state that any deployment is automatically audit-ready.

A real alternative is to use separate purpose-built systems for only the domains a team operates, then connect them through scripts or an automation platform. That approach requires fewer Probo-specific records but loses the shared GRC model. A managed GRC service changes the infrastructure boundary by moving operation to its provider, although the README does not name or document a specific managed alternative.

MIT Licensing, Release Activity, and Upgrade Ownership

Probo is distributed under the MIT license, and the repository's `package.json` also declares `"license": "MIT"`. This supports self-hosting and source inspection, but the README does not summarize the license obligations. An organization handling source redistribution, modified deployments, or third-party components should review `LICENSE` and `THIRD-PARTY-NOTICES` rather than rely on the short project description. This is a compliance-review point, not legal advice.

The last push was on 2026-10-16. Releases published on that date include `probod/v0.313.0`, `prb/v0.248.0`, and `@probo/n8n-nodes-probo/v0.250.0`. These release records cover the server, CLI, and n8n package, but they do not establish compatibility guarantees between versions.

The upgrade burden comes from the monorepo's separate parts. Go and npm dependencies must remain compatible, PostgreSQL and object storage persist operational data, and the container and observability configuration also participate in deployment. The repository has `CHANGELOG.md`, `CHANGELOG.archive.md`, and production Compose files, but the README does not give a documented upgrade sequence. Before using Probo for live compliance records, an adopter needs a concrete answer about migration testing, artifact retention, backups, and recovery for the selected release.

Editorial conclusion

Probo fits engineering and security organizations that want a self-hosted GRC system with code-accessible data and would accept responsibility for PostgreSQL, object storage, observability, upgrades, and access controls. It is a poor fit for teams seeking a lightweight compliance checklist or a fully managed service with no infrastructure ownership. Before adoption, verify that `make stack-up`, `make dev-config`, and `bin/probod -cfg-file cfg/dev.yaml` complete in the target environment, then confirm that the `prb` login flow and required integrations fit the intended operating model. The first decision should be whether Probo's documented self-hosting workflow and API-driven compliance model match the resources available to maintain it.

Frequently asked questions

Official sources

1. getprobo/probo on GitHub
2. License: MIT
3. Project website
4. README
5. Releases