# Daedro MCP Hub: operations requirements

Status: specification input, not a deployed configuration. Reviewed November 4,
2026. This document does not authorize or perform infrastructure changes.

## Product boundary

The first publishable product is a shared MCP marketplace with personal profiles,
workspace-scoped credentials, private data and visible job outcomes. Dedicated
customer infrastructure is a later delivery mode. Customers must not manage
OpenBao root tokens, unseal shares, SSH tunnels, shell scripts or container hosts.
Those are operator concerns behind the product.

A shared deployment is not permission to share identity, secrets or outputs.
Every operation resolves user and workspace on the server, including object
uploads/downloads, job status, secret updates and support diagnostics. Catalog
metadata may be public; connector credentials and call data may not. A private
checkbox must describe the real isolation guarantee, not imply a dedicated VM.

## Verified baseline and gaps

The local user configuration contains eleven connectors; the repository catalog
contains thirteen service contracts including `cleaning` and `text-stats`. These
are overlapping inventories, not a single count of running services. See the
[inventory reconciliation](../mcp-inventory.md). Configuration is not readiness:

| Connector | Evidence available | Missing product acceptance |
| --- | --- | --- |
| S3 | Authenticated bucket listing succeeded with existing local credentials | OpenBao import, browser invocation through new auth, scoped object browsing |
| Audio | Local container healthy; authenticated capabilities succeeded | Provider-secret migration; real upload, transcription, job and result flow |
| Video | Local container healthy; authenticated capabilities succeeded | Video upload and delegated audio processing through the user interface |
| Text, WhatsApp archive | Configured; not running in the last checked deployment | Launch, handshake, authorization, private input/output acceptance |
| YouTube | Configured; database stopped in latest local inventory | Complete API/worker/database lifecycle and external-source boundary |
| Discord read | Existing read-only implementation; default token file absent | Explicit credential source and authenticated read validation |
| AdsPower | Cached implementation/version identified | Pinned execution, narrow tool allowlist and browser-profile ownership |
| Telegram | Existing Compose entrypoint | Session-file isolation and connector ownership |
| Factory, agent-factory | Existing entrypoints | Lifecycle tool allowlist; external-action and infrastructure permissions |

The local Docker inventory also includes created or stopped development stacks.
They must not be silently presented as available products or automatically
started as a side effect of viewing the catalog.

Existing `internal/managed` admission caps replicas by CPU, RAM and a global
budget. It reconciles occupancy conservatively. Existing fleet tests cover
private-instance visibility and global capacity. This is useful machinery, but
it does not establish public multi-tenant isolation or paid-provider cost caps.
Existing private Secrets UI keeps sessions in memory and reports a duration/run
reference. Its token expiry, local process lifetime and one-off tunnel are not a
reliable public-service lifecycle. No central tenant-facing audit, cost ledger,
trace explorer or availability SLO has been demonstrated.

## Required lifecycle

A connection has separate `configured`, `credentials_needed`, `checking`,
`ready`, `degraded`, `paused` and `unavailable` states. Each state includes its
last checked time, safe reason and next action. Store configuration, secret
version references, operator approval and lifecycle intent durably. A successful
capabilities call means connection verified, not transcription verified.

Jobs use durable IDs and state transitions: accepted, queued, running, succeeded,
failed, cancelled. Record idempotency keys, current execution attempt, ownership
and output retention. Only the current attempt may publish a terminal result.
Client retry cannot duplicate a charged provider action. Non-idempotent calls
with unknown provider outcomes require reconciliation, not blind retries.

All long-running services have supervised startup, health/readiness checks,
bounded restart backoff and clean shutdown. New requests fail closed while
identity, secret storage or resource occupancy is uncertain. Startup must not
reinitialize an existing vault. UI errors should identify the unavailable
service without exposing credentials or asking customers to open a terminal.

## Observability and customer visibility

Maintain three separate records:

- **Job history:** workspace-owned operation, timestamps, state, progress, safe
  error category, output references and estimated/final usage.
- **Security audit:** actor, workspace, action, target identifier, outcome,
  timestamp, request/trace ID and secret version identifier. Include enrollment,
  login, recovery, membership, credential write/use/revoke and administrative
  access. Never record secret values, authorization headers, TOTP seeds/codes,
  raw uploaded content, provider request bodies or arbitrary exception dumps.
- **Operational telemetry:** bounded-cardinality counts and latency histograms
  for requests, queue age, failures, retries, worker occupancy, quota rejection,
  dependency readiness and secret-lease failures. Restricted traces may include
  opaque job/tenant identifiers; public metrics must not contain customer IDs,
  object names or payloads as labels.

The user sees only their workspace history and costs. Support access must be
explicit, time-bounded and audited. Admins see aggregate capacity and dependency
health; raw customer contents are not the default diagnostic view. Redaction is
applied before data leaves the process, with synthetic-secret leak tests. Set
retention and deletion policies for jobs, artifacts and audit records separately.

## Admission, scaling and spending

Enforce per-user, per-workspace and global concurrency, queue length, request
size, execution time, CPU/RAM, storage, egress and replica caps. Resolve the most
restrictive applicable budget before spawning a worker. Default-deny connector
egress and block cloud metadata endpoints for worker containers. Untrusted
uploads require a different execution boundary from the identity/vault host.

Provider spend needs an atomic reservation before admission and reconciliation
after completion. Distinguish estimate, actual provider usage and unknown cost.
A spend ceiling rejects new paid work; infrastructure billing alerts alone do
not cap expense. Do not start extra VMs merely because all MCP replicas are busy.
Provide an operator kill switch for new executions while preserving job records.

## Recovery and internal secret storage

Cloud KMS auto-unseal is the recommended internal mechanism for an always-on
cloud vault. It removes the laptop from normal restart availability. Mac
Keychain is suitable for the private operator's recovery copy, not as the only
unseal service for a public product. Use a dedicated VM service account scoped
to the single seal key; do not distribute service-account JSON credentials.
OpenBao 2.7 requires the external GCP KMS plugin: pin and verify that artifact.
Recovery material remains an operational concern; passkey/TOTP login must not
be advertised as sufficient to decrypt a lost vault seal.

Use encrypted Raft snapshots with tested off-host retention and a separate
recovery-material custody plan. A restore drill must verify login, workspace
ACLs and one real credential-backed operation. KMS key destruction can make
snapshots unusable; restrict destruction rights and keep required key versions.
Bootstrap root is temporary and revoked after scoped administrator access and
recovery are verified. Runtime identity has no policy-administration privilege.

The old pilot has unavailable recovery material. Retaining its disk is evidence
preservation, not a verified recoverable backup. Stopping its unsealed process
loses that operational state. Replacing it must import still-available original
connector credentials; never promise restoration by simply restarting the old
container. Attaching a service account to the existing Google VM requires a VM
stop, so this issue must be addressed before any deployment change.

## Capacity and budget proposal, not a deployment decision

The current 2 GiB VM is insufficient to claim reliable co-location of Keycloak,
PostgreSQL, OpenBao capped at 768 MiB, hub and operating system. Keycloak's
container guidance recommends a 2 GiB limit for smaller production deployments.
Do not substitute development mode/H2 for a durable product database.

An optional same-host 4 GiB pilot has the following 730-hour monthly baseline in
Iowa, before free allowances/credits, tax, traffic, backups and workload/provider charges:

| Item | Approximate USD/month |
| --- | ---: |
| e2-medium | 24.46 |
| One in-use external IPv4 | 3.65 |
| Existing 20 GiB standard disk | 0.80 |
| One software Cloud KMS key version | 0.06 |
| Base total | 28.97 |

KMS cryptographic operations add $0.03 per 10,000 operations. Treat this as an
estimate, not a quote or cap. Verify container memory/startup peaks before
selecting this topology. It leaves approximately $21 of the $50 budget for
variable costs, but not unlimited media processing. Keep heavy/untrusted workers
separate. The existing 24-hour STOP guard is incompatible with an always-on
service; replacing it changes recurring consumption and needs an explicit
operational/budget decision. Free Trial must not be silently upgraded.

## Gates before public launch

1. Two distinct users cannot enumerate or access each other's secrets, uploads,
   jobs, outputs or traces through HTTP, MCP or guessed identifiers.
2. Browser-only enrollment, login, lost-device recovery and credential connection
   succeed on supported devices; no operator secret is exposed in the browser.
3. S3 and at least one real audio/video job pass end to end; catalog status and
   documentation match the actual tested operations.
4. Restart and backup-restore drills preserve ownership, idempotency and secret
   access; no root token is used for normal requests.
5. Fault tests exercise expired credentials, sealed/unreachable vault, provider
   timeout, duplicate delivery, worker crash, quota exhaustion and disk pressure.
6. Cost reservations, retention, redaction and security audit are verified. A
   customer can understand each failure and its next action from the interface.

## Primary sources

- [OpenBao GCP KMS seal](https://openbao.org/docs/configuration/seal/gcpckms/)
- [OpenBao seal/recovery lifecycle](https://openbao.org/docs/concepts/seal/)
- [OpenBao static seal trust warning](https://openbao.org/docs/configuration/seal/static/)
- [Google KMS pricing](https://cloud.google.com/kms/pricing)
- [Google VM service-account changes](https://docs.cloud.google.com/compute/docs/instances/change-service-account)
- [Google general-purpose VM prices](https://cloud.google.com/products/compute/pricing/general-purpose)
- [Google disk prices](https://cloud.google.com/compute/disks-image-pricing)
- [Google external IPv4 prices](https://cloud.google.com/vpc/pricing)
- [Keycloak container memory guidance](https://www.keycloak.org/server/containers)