Ops-Center

Run your AI services, tenants, billing, and agents from one self-hosted control plane.

Quick start · Features · Agents · Architecture · Suite

The admin dashboard — infrastructure and operations at a glance.

What is Ops-Center?

Ops-Center is the control plane for people running AI infrastructure and the applications built on it: manage users, organizations, subscriptions, API keys, model providers, and service health in one place. It is self-hosted and part of Unicorn Commander, whose apps connect through shared identity, organization context, entitlements, and usage APIs. The Colonel, its server-management agent, can inspect infrastructure and execute tools; its interactive chat asks humans to confirm actions marked as requiring approval. Choose local inference, federated capacity, or configured cloud providers according to your deployment and routing policy.

Highlights

• One place for accounts and access. Manage Keycloak users, organization membership, roles, API keys, and app grants without maintaining separate access lists in every app.
• Local inference with cloud options. Manage model catalogs, provider credentials, and federated routing so applications can use a shared inference interface.
• Usage attached to the account. Track requests, credits, and model costs alongside subscriptions, invoices, and payment methods through Lago and Stripe integrations.
• An agent that can act. The Colonel exposes infrastructure skills through chat and authenticated A2A calls, including Docker inspection, logs, database diagnostics, and Brigade delegation.
• Apps matched to entitlement. The marketplace combines subscription features with organization grants, while users get a view of the apps they can access.
• Infrastructure in context. Follow service health, system metrics, federation topology, routing audits, and fleet inventory from the same dashboard.
• A configurable platform. Bring provider keys, curate app-specific model lists, customize branding, and configure billing exemptions for your installation.

Feature tour

Model and provider management

Model and provider management — local inference with configured cloud failover.

Manage local inference services and cloud provider connections, curate model lists per application, and control model access by tier. Bring Your Own Key (BYOK) settings let users supply their own provider credentials; platform keys and provider settings remain separate administrative surfaces. Account API keys are stored as bcrypt hashes.

The mounted inference surfaces are:

Provider calls in the LLM API use configured base URLs for OpenAI, Anthropic, OpenRouter, Google, Ollama, and Ollama Cloud. backend/model_adapters covers Ollama, vLLM, embeddings, and reranking. litellm_config.yaml lists additional cloud model entries and fallback groups. Which of these answer depends on the services and credentials you configure. The metered-compute module no longer proxies embeddings or reranking; those remain federation service types and RAG-service records.

Routing and the gateway: Ops-Center's inference API and federation router work alongside an optional LiteLLM proxy. Federation gathers local, peer, and cloud candidates, filters them against request constraints, and applies tier-dependent routing. With no tier, or when the tier is vip_founder, founder_friend, admin, or internal, the search order is local, then peer, then cloud. Any other named tier searches cloud GPU, then cloud, then local, then peer, unless the request sets preferred_node, which uses local, then peer, then cloud. A tier named free is not in that local-first allowlist. Configure and test fallback policy for your deployment before relying on it. When FEDERATION_KEY or FEDERATION_SHARED_SECRET is set, peer calls accept HMAC-SHA256 JWTs that expire in 60 seconds and carry a jti replay check, or that shared key. With no shared key configured, federation verification allows the request. FEDERATION_AUTH_MODE defaults to shared_key; node_keys is the other mode. The default per-peer circuit breaker opens after 3 consecutive failures, waits 30 seconds, and allows one half-open trial.

See model-list management, the BYOK guide, and the routing implementation for the configuration boundaries.

Usage and metering

Usage and metering — understand where requests and credits go.

Inspect credit balances, ledger transactions, and recorded usage alongside account and organization billing. Lago supplies subscription and metering integration; Stripe supplies checkout, payment-method, invoice, and webhook flows. Plans and prices come from configured subscription tiers. If that lookup fails, the plan page shows a built-in list: Trial ($1/week), Starter ($19/month), Professional ($49/month), and Enterprise ($99/month). Those figures are the fallback, not the live catalog.

Users can review their plan, manage payment methods, and upgrade, downgrade, or cancel. Cancellation is recorded through Lago. Administrators can manage subscriptions, pricing, credit packages, and organization feature grants. Notification preferences are stored per user. The metered-compute reporting API also accepts usage from configured services, including audio workloads.

Some legacy analytics endpoints still generate sample data, and the Usage Metrics page falls back to demo charts when its API fails. Use the credit ledger and configured billing services to reconcile actual spend; a populated chart alone is not evidence of recorded usage.

For installations that do not charge for inference, the backend supports BILLING_ENABLED and CREDIT_EXEMPT_TIERS. These control inference credit checks; they do not provision or remove the billing services. See the billing reference and credit model.

The app marketplace

The app marketplace — discover applications and see your access.

The marketplace uses app definitions and feature grants to present available applications. My Apps resolves subscription features together with organization grants, giving users a launcher for the services they can access. Administrators manage the catalog and the features associated with plans.

Keycloak-backed applications can share sign-in. App definitions contain launch URLs and access metadata; connecting an app still requires its own deployment, identity setup, and integration. Existing integrations include Brigade, Open-WebUI, Bolt.diy, Presenton, and Forgejo, with configurable catalog entries for other services.

Service health

View Docker-backed service status, inspect logs, and manage service lifecycle operations on a configured host. System monitoring exposes CPU, memory, storage, and available GPU information; federation views show peer nodes and their advertised services. Host inspection and management require the relevant Docker, filesystem, and device access.

Additional administrative surfaces cover Traefik routes and certificates, storage and backups, alerts, website monitoring, and analytics. Optional Prometheus, Grafana, and Umami integrations use their configured services. Fleet inventory accepts UUDA registration and heartbeats, while the fleet-map integration ingests topology snapshots.

Users, organizations, and access

The dashboard above is the entry point for account administration. Search and filter users, import and export CSV, change subscription tiers in bulk, assign or remove an individual realm role, and send password-reset or onboarding messages through Keycloak. Sign-in maps Keycloak groups and roles onto admin, power_user, user, and viewer. GET /api/v1/admin/users/roles/available returns a different hardcoded list: admin, moderator, developer, analyst, and viewer.

Organizations have membership and role-management APIs, settings, billing views, and feature grants. User details bring profile, access, organization, and subscription information together. Account API keys have creation, regeneration, revocation, and scope controls; service credentials support application-to-application calls. The Guide, described below, can prepare API-key create, revoke, and rotate actions that wait for a human confirmation.

Role checks, session authentication, and authorization remain part of the backend. User impersonation, the per-user activity feed, the per-user role list, bulk role assignment, and the administrative user-session endpoints are still placeholders in this checkout. Use the implemented routes and integration guide for the supported contract.

Built for agents

The Colonel: chat and A2A

The Colonel ships 18 skill definitions and 67 registered action executors. These are Colonel function-calling actions, not a count of public MCP tools. The skill files use Markdown with YAML front matter and are loaded from backend/colonel/skills.

Useful actions include:

Interactive chat streams responses and tool activity over WebSocket, with Redis-backed sessions and PostgreSQL persistence. Actions marked for confirmation go through a human confirmation prompt in chat. Brigade registration and delegation use BRIGADE_API_URL and BRIGADE_SERVICE_KEY; the local memory graph can defer to Brigade when that integration is configured.

The mounted agent interface is HTTP JSON-RPC at /a2a:

• Discovery: /.well-known/agent-card.json, with a legacy card at /.well-known/agent.json and an agent index at /.well-known/api-catalog.
• Authentication: Authorization: Bearer <a2a-shared-secret> or X-Service-Key: <a2a-shared-secret>. The server uses A2A_SHARED_SECRET, falling back to BRIGADE_SERVICE_KEY, and refuses calls when neither is configured.
• Methods: skills/list, skills/invoke, agent/status, colonels/list, and the legacy tasks/send. tasks/get is not implemented; A2A streaming and push notifications are not advertised.
• Invocation: supply skill, action, and parameters. An optional colonel (or colonel_id) is stored on the audit row and selects the Colonel for agent/status and named agent cards. skills/invoke runs the shared executor map; it does not load a different tool set per Colonel.

A2A is a privileged service interface. Its direct skills/invoke handler calls executors without the interactive chat confirmation flow. Give its credential only to trusted callers and enforce any required human approval in that caller's workflow.

Copy this curl client configuration, replace the placeholders, and run it against your deployment to list available skills:

curl --config - <<'CURL'
url = "https://<ops-center-host>/a2a"
request = "POST"
header = "Authorization: Bearer <a2a-shared-secret>"
header = "Content-Type: application/json"
data = "{\"jsonrpc\":\"2.0\",\"id\":\"readme-discovery\",\"method\":\"skills/list\",\"params\":{}}"
silent
show-error
fail-with-body
CURL

For a read-only status action, change the JSON body to:

{
  "jsonrpc": "2.0",
  "id": "readme-status",
  "method": "skills/invoke",
  "params": {
    "skill": "system-status",
    "action": "full_status",
    "parameters": {}
  }
}

MCP discovery and application hooks

Ops-Center serves the suite MCP directory at /.well-known/mcps.json. It is a discovery index for other applications, not a general-purpose MCP server mounted by this app. MCP transport, authentication, and tool counts belong to each target server; inspect that server's discovery document and authenticated tool list before configuring a client. The committed directory contains deployment-specific locations and must be reviewed for your installation.

The main server does not mount the legacy MCP callback connector or the separate MCP metering and UUDA MCP gateway routers present in the source tree. Their presence is not a working public MCP endpoint, so there is no mcpServers configuration for Ops-Center itself here.

Other mounted hooks include API-key validation for applications, entitlement lookup, federation agent discovery and invocation, and service-authenticated metered-compute reporting. The Guide, a separate account assistant, provides account help and confirmation-based API-key lifecycle actions without the Colonel's host-management toolset.

See the agent interface, skill router, and application integration guide.

Quick start

Docker: connect to a provisioned suite

This checkout requires shared services. Have PostgreSQL, Redis, Keycloak, and an HTTPS reverse proxy available before starting the authenticated dashboard. Billing needs Lago and Stripe configuration; inference and agent chat need configured model services or providers. The repository does not include a complete, portable suite bootstrap, and SKIP_AUTH in the environment template is not an implemented dashboard bypass.

The shortest self-contained application build uses the checked-in Dockerfile. Its frontend stage is Node 20, which is not the version in .nvmrc. The existing direct Compose file is a deployment-specific overlay: it expects external networks and services, references a prebuilt image, and includes embedded environment settings that override an env file. It needs operator review before reuse. The proxy Compose files do not create the backend, database, cache, or identity provider.

Prepare your identity and storage services:

• Provide an Ops-Center database and a database account able to apply its startup migrations. Review the migration notes; an existing database should be backed up before an upgrade.
• Provide Redis reachable from the application container. Configure both the split Redis settings and REDIS_URL consistently, including authentication.
• In Keycloak, create a confidential client whose client id is ops-center. The login, callback, and identity-provider hint routes hardcode that id in backend/server.py. Setting OAUTH_CLIENT_ID does not change it. Use the authorization-code flow. Register https://<ops-center-host>/auth/callback as its redirect URI and your HTTPS application origin as an allowed web origin. Put the client secret in OPS_CENTER_OAUTH_CLIENT_SECRET. If that variable is unset, the login handler uses a placeholder compiled into the same file.
• Make the user's roles or groups available to the user-info response. Assign the admin role or an admins group for the first administrator; the role mapper lists supported mappings. /auth/login/google, /auth/login/github, and /auth/login/microsoft only add a Keycloak identity-provider hint. The providers still have to be enabled in the realm.
• Set KEYCLOAK_REALM to the realm that holds application users. If it is unset, /auth/login and the identity-provider hint routes default to master, and /auth/callback defaults to uchub.
• User-management calls request an admin token from the master realm with KEYCLOAK_CLIENT_ID (code default admin-cli when the variable is unset), KEYCLOAK_ADMIN_USER, and KEYCLOAK_ADMIN_PASSWORD. That request does not send KEYCLOAK_CLIENT_SECRET. Logout's end-session URL prefers KEYCLOAK_CLIENT_ID, then OAUTH_CLIENT_ID, then ops-center. The template sets KEYCLOAK_CLIENT_ID=ops-center, which matches the browser client and does not match the admin-token default. One variable serves both jobs in this checkout.
• Route your HTTPS application host to the application port, including /auth, /api, /ws, /a2a, and /.well-known. Preserve the original host and scheme and enable WebSocket forwarding.

Clone and prepare a private runtime configuration. On 2026-10-23 the public Unicorn-Commander organization did not list a repository named Ops-Center. Clone the URL of the checkout you are reading. The commands below assume the directory name Ops-Center.

git clone <repository-url>
cd Ops-Center
cp .env.example .env.auth
chmod 600 .env.auth

Edit .env.auth for your services before continuing. Replace the template's deployment defaults, credentials, and hostnames. Set the PostgreSQL, Redis, Keycloak, and optional provider variables listed under Configuration, and add these runtime settings missing from the template:

EXTERNAL_HOST=<ops-center-host>
EXTERNAL_PROTOCOL=https
OPS_CENTER_OAUTH_CLIENT_SECRET=<ops-center-client-secret>
SESSION_SECRET_KEY=<random-session-secret>
REDIS_URL=<authenticated-redis-url>
ENCRYPTION_KEY=<persistent-fernet-key>
BYOK_ENCRYPTION_KEY=<persistent-byok-fernet-key>

Use a hostname without a scheme or path for EXTERNAL_HOST. Keep encryption keys stable across restarts. The current SSO login and callback handlers construct an HTTPS redirect; a plain HTTP localhost address is useful for diagnostics, but is not the complete sign-in path.

Build and start the application on an existing Docker network that can reach your shared services. Replace <suite-network> with that network's name:

docker build --tag ops-center:local .

docker run --detach \
  --name ops-center \
  --network '<suite-network>' \
  --publish 127.0.0.1:8084:8084 \
  --env-file .env.auth \
  --mount type=volume,source=ops-center-data,target=/app/data \
  --mount type=volume,source=ops-center-avatars,target=/app/public/avatars \
  --entrypoint /bin/sh \
  ops-center:local \
  -c 'cp -a /app/dist/. /app/public/ && exec uvicorn server:app --host 0.0.0.0 --port 8084'

The startup command stages the newly built frontend into public, which the server checks before dist. The loopback port is for a reverse proxy on the Docker host; a containerized proxy on the same network can use the container's application port directly.

For host service inspection and control, add the Docker socket mount to that docker run command before the image name:

--mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock

Docker socket access grants control over the host's Docker daemon. GPU and host filesystem features need their own device or directory mappings; the basic application container does not automatically gain those capabilities.

Check that the backend responds, then complete sign-in through your configured HTTPS host:

curl --fail --silent --show-error http://localhost:8084/api/v1/system/status
docker logs --tail 100 ops-center

Open https://<ops-center-host>/auth/login and verify that the admin dashboard loads after Keycloak sign-in. A successful status response alone does not verify database initialization, authentication, billing, or inference. Review startup errors before enabling those integrations.

Compose files in this repository

These files describe separate deployment pieces. Review their mounts, service names, credentials, and external-network assumptions before combining them with your own suite deployment.

Run from source

Use the Node version selected by .nvmrc, npm compatible with package.json, and Python matching the backend's Dockerfile. Backend dependencies are in backend/requirements.txt. The same database, cache, identity, and HTTPS prerequisites apply to source development.

From the repository root, install the frontend and backend dependencies:

npm ci
python3.10 -m venv .venv
. .venv/bin/activate
python -m pip install -r backend/requirements.txt python-dotenv

python-dotenv is not in backend/requirements.txt. The uvicorn --env-file flag requires it.

Use the prepared .env.auth, with service addresses reachable from your development machine. Start the backend from the repository root:

. .venv/bin/activate
python -m uvicorn server:app \
  --app-dir backend \
  --env-file .env.auth \
  --host 127.0.0.1 \
  --port 8085 \
  --reload

In another terminal:

npm run dev -- --host 127.0.0.1

Vite serves the frontend on http://localhost:8084 and proxies /api and /ws to the backend on 8085. It does not proxy /auth. For a full signed-in development session, route /auth, /api, /ws, /a2a, and /.well-known from your HTTPS development host to the backend, and other paths to Vite. Use that HTTPS host in Keycloak and EXTERNAL_HOST.

Build the frontend with:

npm run build

The build writes dist/. A locally built frontend is not automatically deployed by that command. For a container deployment, rebuild the image and use the Docker startup path above; source changes do not require copying a build into tracked assets.

Configuration

.env.example is a starting template, not a complete runtime contract. The table below lists important template variables read by the current integrations; fill in your own values in .env.auth.

Additional settings used by current code but absent from the template:

The template's KEYCLOAK_CLIENT_SECRET is not the browser-login secret. The login handler reads OPS_CENTER_OAUTH_CLIENT_SECRET, and the admin token request does not send KEYCLOAK_CLIENT_SECRET. Similarly, ENABLE_BILLING, SECRET_KEY, and SKIP_AUTH are not substitutes for BILLING_ENABLED, SESSION_SECRET_KEY, or a working Keycloak setup. Keep runtime configuration out of Git.

Frontend analytics initialize only in production builds with the corresponding build-time identifier configured. Changing container runtime variables alone does not alter an already compiled frontend; the stock Dockerfile does not pass these analytics variables into its frontend build stage.

Architecture

flowchart TD
    Human[Administrator or account user] --> Edge[HTTPS reverse proxy]
    Agent[Trusted agent client] -->|Authenticated A2A| Edge
    Edge --> UI[React and Vite frontend]
    Edge --> API[FastAPI application]
    UI -->|Session APIs and WebSocket| API
    Human <-->|Sign-in| Identity[Keycloak]
    API <-->|OIDC and user administration| Identity
    API --> DB[(PostgreSQL)]
    API --> Cache[(Redis)]
    API --> Billing[Lago and Stripe]
    API --> Inference[Inference API and federation router]
    Inference --> Local[Local model services]
    Inference --> Peers[Federated peers]
    Inference --> Cloud[Configured cloud providers and optional LiteLLM]
    API --> Colonel[The Colonel]
    Colonel --> Host[Docker and host tools]
    Colonel --> Brigade[Unicorn-Brigade]
    Fleet[UUDA and fleet-map collectors] -->|Registration, heartbeat, or ingest| API

• Frontend — src: React, Vite, Material UI, React Router, context providers, and charting components. Admin, account, organization, billing, model, and federation pages share the application shell.
• Application — backend/server.py: FastAPI mounts the feature routers, handles browser sign-in and sessions, serves the frontend, and starts integration services.
• Persistence: PostgreSQL stores application and billing-related records; Redis supports sessions, caching, and coordination. Startup applies selected feature and core migrations; inspect the migration logs on deployment.
• Identity and access: Keycloak supplies identity. Browser login uses the hardcoded client id ops-center. Backend session checks, route-specific authorization, bcrypt-hashed API keys, and federation HMAC-SHA256 JWTs cover different entry points.
• Inference — backend/federation and backend/litellm_api.py: Provider routing, usage accounting, peer discovery, pipelines, and optional cloud GPU management.
• Agents — backend/colonel: Skill loading, execution, interactive confirmations, memory, sessions, and A2A integration. Brigade can provide delegation and agent memory.
• Operations: Docker, Traefik, billing providers, and monitoring services are external integrations. Compose describes deployment topology; it does not replace the services themselves.

Ops-Center/
├── backend/
│   ├── server.py                # Application, startup, auth, router registration
│   ├── colonel/                 # Agent chat, skills, memory, and A2A
│   ├── federation/              # Nodes, discovery, routing, and pipelines
│   ├── routers/                 # Infrastructure and integration APIs
│   ├── migrations/              # SQL migrations and migration manifest
│   ├── user_management_api.py   # Administrative user operations
│   ├── org_api.py               # Organizations and membership
│   ├── litellm_api.py           # Inference, usage, and provider operations
│   ├── my_apps_api.py           # App catalog and entitlement resolution
│   └── requirements.txt         # Python dependencies
├── src/
│   ├── App.jsx                  # Application shell and routes
│   ├── pages/                   # Admin and account pages
│   ├── components/              # Shared interface components
│   └── contexts/                # Shared frontend state
├── public/                      # Static assets
├── docs/                        # Guides, references, and historical reports
├── tests/                       # Integration and browser tests
├── Dockerfile                   # Frontend build and Python application image
├── package.json                 # Frontend version, dependencies, and commands
└── vite.config.js               # Frontend build and development proxy

Part of Unicorn Commander

Public repositories on the Unicorn-Commander organization, checked 2026-10-23. Names below are the published repository names, not the product names used in older notes.

Ops-Center connects through shared Keycloak identity, application entitlement and API-key validation APIs, and inference and metering services. This tree also registers and delegates the Colonel through Brigade, accepts UUDA device registration and heartbeats, and ingests fleet-map topology. On the date above, the public organization did not list repositories named Unicorn-Brigade, Knowledge-Ops, Security-Ops, Tax-Planning-Ops, Brand-Ops, Podcast-Ops, UUDA, or fleet-map.

Development

Use CONTRIBUTING.md for the contribution workflow. The frontend manifest defines Vitest and Playwright commands; backend test configuration lives in pytest.ini, with extra dependencies in tests/requirements-test.txt.

# Frontend tests, a single run
npm run test:run

# Production frontend build, including the dependency precheck
npm run build

# Backend test dependencies, in your activated virtual environment
python -m pip install -r tests/requirements-test.txt

# Backend tests: configure isolated test services before running the full suite
python -m pytest

Browser tests need a running test deployment and the fixtures required by the selected tests. Install the browser and explicitly select your test URL:

npx playwright install chromium
BASE_URL='https://<test-ops-center-host>' npm run test:e2e -- --project=chromium

Review the selected specs for additional service URLs and account requirements before execution. If BASE_URL is unset, playwright.config.js uses https://magicunicorn.dev. Some tests use other deployment-specific defaults. Use disposable test accounts and service instances.

The GitHub test workflow runs Ruff and Black from backend/ as required steps, and MyPy with continue-on-error. It does not run Bandit. The GitHub CI/CD pipeline runs Ruff, Black, MyPy, and Bandit from backend/, each continue-on-error. The Forgejo CI/CD pipeline runs Ruff, Black, and MyPy from backend/ with || true; it installs Bandit and does not run it. Those three workflows install ESLint in the job and run it against src, with continue-on-error or || true. .forgejo/workflows/ci.yml does not run these linters. There is no npm run lint script in the current manifest. Install Ruff explicitly for a local check:

python -m pip install ruff
python -m ruff check backend/

Frontend build and test commands above are available. This README does not imply that all application tests or lint checks currently pass.

Documentation

Long-form references and historical implementation reports remain in the repository. Some predate the current routing and deployment model; use the current source and this README's startup prerequisites when a guide differs.

• User guide — account, dashboard, and administrative workflows.
• Application integration guide — identity, application access, and API integration.
• Billing API reference and billing systems reference — billing surfaces and service relationships.
• Credit model — credit accounting concepts and billing terminology.
• Model-list reference — catalogs and per-app model access.
• BYOK user guide and BYOK architecture — user and platform credential flows.
• Traefik user guide and Traefik API reference — routes, services, middleware, and certificates.
• Monitoring setup — optional monitoring infrastructure.
• Migration notes and SQL reference — database setup and schema changes.
• Legacy local-auth policy — why local authentication is separate from Keycloak sign-in.
• Tests, backend tests, and browser tests — suite-specific fixtures and execution.
• Troubleshooting — historical operational issues and diagnostics.
• Technical notes — detailed implementation context and deployment history.
• Changelog — release history. Entries that match this tree include campaign and invite-code work in 3.12.4, Brigade-aware Colonel memory (COLONEL_LOCAL_GRAPH) in 3.12.2, and the 3.12.0 inference notes for embeddings, reranking, and failover configuration. Earlier entries record federation routing, circuit breakers, routing audits, cloud GPU provisioning, and Colonel delegation to Brigade. Hostnames and hardware names in those notes are one installation's examples.
• Historical roadmap — planning context, not a statement of current completion.

The running FastAPI application also exposes /docs and /openapi.json. Those describe mounted routes more accurately than an old endpoint inventory; administrative session cookies, app API keys, service keys, and federation credentials serve different authentication paths.

Troubleshooting the first run

For bugs and feature requests, use this repository's issue tracker. A public issues URL under Unicorn-Commander/Ops-Center was not listed on 2026-10-23. For general support, email support@magicunicorn.tech.

Ops-Center builds on FastAPI, React, Material UI, Keycloak, Lago, and LiteLLM.

Security

Report vulnerabilities privately to security@unicorncommander.ai; see SECURITY.md for what to include. Do not put credentials, personal data, or exploitable details in a public issue.

The implementation includes session authentication, route-level role checks, CSRF protection, rate limiting, hashed account API keys, encrypted provider credentials, and federation authentication and audit components. These have distinct scopes and configuration requirements. Terminate HTTPS at your proxy, restrict host-management access, and treat Colonel A2A credentials as privileged execution credentials.

Licence

Ops-Center is licensed under the Apache License 2.0. You can use, change and redistribute it, including commercially, under its terms. Our names and logos are covered by TRADEMARKS.md.

Copyright © Magic Unicorn Unconventional Technology & Stuff Inc.

Built by Magic Unicorn · part of Unicorn Commander