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. Configuration is not readiness:

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:

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
• OpenBao seal/recovery lifecycle
• OpenBao static seal trust warning
• Google KMS pricing
• Google VM service-account changes
• Google general-purpose VM prices
• Google disk prices
• Google external IPv4 prices
• Keycloak container memory guidance