Turning Services Off

Whole services — the Knowledge Engine, browsers, the crawler, the sandbox, and so on — can be switched off in two places:

Switch	Scope	Set by
CONSOLE_DISABLED_SERVICES / CONSOLE_ENABLED_SERVICES	The whole deployment	The operator, in the environment (Helm env)
The license services claim	One workspace (tenant)	Cognipeer, when the license is issued

Both are optional and both only ever turn services off. With no environment variable set and a license without the claim — which is every license issued before the claim existed — every service stays on. Existing licenses do not need to be re-issued.

Switching a service off never deletes anything: its records stay in the database and come back as they were when the service is switched on again.

Environment

Variable	Meaning	Default
CONSOLE_DISABLED_SERVICES	Comma-separated service ids to switch off.	(empty)
CONSOLE_ENABLED_SERVICES	Comma-separated service ids to keep on; every other switchable service is off. Use it when only a few services should run.	(empty)

# Everything except browsers and the crawler
CONSOLE_DISABLED_SERVICES=browser,crawler

# Only models, agents and the Knowledge Engine (plus what they need)
CONSOLE_ENABLED_SERVICES=models,agents,rag,vector,files

An unknown service id, or an always-on id in CONSOLE_DISABLED_SERVICES, is a configuration error: production refuses to start and logs the offending id, so a typo never leaves a service running that you believe is off. Changes take effect when the process restarts.

In the Helm charts, set them under env:

env:
  CONSOLE_DISABLED_SERVICES: "browser,crawler,sandbox"

License

A license can carry a services claim:

{
  "services": {
    "allow": ["models", "agents", "rag", "vector", "files"],
    "deny": ["browser"]
  }
}

• allow keeps only the listed services on; deny switches the listed ones off. Either or both.
• An empty allow list is refused at activation.
• A service id this release does not know is ignored, so a license issued for a newer release still activates on an older one. The activation response lists such ids under warnings.unknownServices.
• An expired license falls back to the free tier, which has no claim.

The environment is a ceiling: a license cannot turn a service back on that the operator switched off.

The License page (Settings › License) lists every switchable service at the bottom: whether it is on, and when it is off, whether the deployment or the license switched it off. GET /api/license returns the same list:

{
  "services": [
    { "service": "browser", "label": "Browsers", "enabled": false, "source": "env" },
    { "service": "rag", "label": "Knowledge Engine", "enabled": false, "source": "license", "via": "vector" },
    { "service": "models", "label": "Model Hub", "enabled": true }
  ]
}

Dependencies

A service that cannot work without another one is off together with it:

Service	Needs
agents	models
rag	models, vector
memory	vector
portals	agents
realtime, evaluations, redteam, analysis, prompt-optimizer, ai-app-gateway	models

The chain is followed to any depth: with models off, agents is off and so are portals. The reason reported for such a service names the switched-off service (via).

Only hard needs are listed. An agent that merely uses a knowledge engine, MCP server, tool, browser, web search, memory store, file or sandbox keeps running when that service is off — the binding is dropped and the agent runs without it.

Always-on services

The administration surface cannot be switched off, so somebody can always sign in, manage access and read the license: tokens, members, projects, providers, config, license, audit, iam, resources.

Service ids

Id	Service	Edition
models	Model Hub (chat, embeddings, images, audio, batch)	Community
prompts	Prompt Studio	Community
agents	Agents	Community
tools	Agent Tools	Community
memory	Agent Memory	Community
tracing	Agent Observability	Community
automations	Automations	Community
rag	Knowledge Engine	Community
vector	Knowledge Index (vector stores)	Community
files	Document Store	Community
crawler	Crawler	Community
ocr	OCR Jobs	Community
reranker	Reranker	Community
websearch	Web Search	Community
browser	Browsers	Community
mcp	MCP servers	Community
guardrails	Guardrails	Community
pii	PII Service	Community
evaluations	Evaluations	Community
redteam	Red Team	Community
analysis	Conversation Analysis	Community
inference-monitoring	Model Monitoring	Community
alerts	Alerts & Incidents	Community
webhooks	Webhooks	Community
aegis	Aegis (legacy)	Community
abacus	Abacus	Enterprise
ai-app-gateway	AI App Gateway	Enterprise
cluster	Cluster	Enterprise
cost	Cost Management	Enterprise
gpu-fleet	GPU Fleet	Enterprise
health	Entity Health	Enterprise
ldap	LDAP Directory	Enterprise
mcp-hub	MCP Hub catalogs	Enterprise
portals	Portals	Enterprise
prompt-optimizer	Prompt Optimizer	Enterprise
realtime	Realtime	Enterprise
reports	Service Reports	Enterprise
sandbox	Sandbox	Enterprise
sso	Single Sign-On	Enterprise

What a switched-off service does

API calls answer with an error that names the service and the reason:

Switched off by	Status	code
Environment	403	service_disabled
License	402	service_not_licensed

{
  "error": "The \"rag\" service is switched off on this deployment.",
  "code": "service_disabled",
  "service": "rag",
  "source": "env"
}

The client API's OpenAI- and Anthropic-style endpoints, and the AI App Gateway, carry the same code inside their own error envelope. Public MCP servers, MCP Hub catalogs, A2A agent cards and inbound hooks answer as if the resource did not exist. Portal chat and embeds answer with the same 403/402 codes. Realtime sockets close with code 4403 (environment) or 4402 (license), and inbound calls are rejected. With sso or ldap off, sign-in behaves as if that method were not configured.

Calls from other services stop too, not only the service's own API: a model call refuses when models is off, an agent run refuses when agents is off, a Knowledge Engine query from an agent tool refuses when rag is off.

Background work:

• A queued job of a switched-off service fails with service_disabled (or service_not_licensed) and is not retried.
• Scheduled work (crawler schedules, alert evaluation, red-team and analysis schedules, agent triggers) is skipped while the service is off and runs again on the next slot after it is switched back on. A one-time agent trigger waits; it fires when the service comes back within the trigger's one-hour misfire grace, and is closed as missed after that.
• Housekeeping keeps running: retention, cleanup reapers, usage accounting.

Guardrails and PII are skipped, not enforced, while their service is off: requests pass through unchecked. Each skip is logged as a warning and written to the audit log (service.safety_check_skipped) once per workspace and process, so the decision is on record. Switch them off only when another layer covers the same checks.

How fast a change applies

• Environment: on restart.
• License: on the node that activated or removed the license, immediately; on the other nodes within a few seconds (they share the license cache; a deployment without a shared cache follows within the cache's 30-second lifetime).

See also

• Configuration — every environment variable
• Licensing
• Deployment