Cloud vs Self-Hosted

Decision Factors

Choose Durabull Cloud When

• You want the fastest time to value.
• You do not want to operate API/web infrastructure.
• You prefer managed availability and maintenance overhead offload.

Choose Self-Hosted When

• You require full infrastructure control.
• You need private-network-only operation.
• You want custom deployment topologies and security controls.

Self-Hosted Responsibilities

If self-hosting, plan for:

• deployment and upgrades
• secrets management
• network segmentation and edge protection
• monitoring and alerting
• backup and restore strategy (Postgres + Redis as needed)

Hybrid Pattern

Some teams start in cloud for onboarding speed and move to self-hosted when governance requirements increase.

MCP (unified deployment)

Durabull ships MCP on the same origin and process as the API and web app. There is no separate MCP container or port.

Deployment	MCP URL
Durabull Cloud	https://app.durabull.io/mcp (example)
Self-hosted	{APP_BASE_URL}/mcp on your published app port

Requirements for both modes:

• Set APP_BASE_URL to the public origin clients use (required for OAuth resource URI and Host allowlist).
• Keep DURABULL_AUTHLESS=false on internet-facing production.

Post-deploy validation: MCP operations runbook (health + PRM on every environment; mcp:e2e on staging/local only).

See MCP Server.

Migration Readiness Checklist

• mode and env var parity documented
• connection source strategy decided (env vs DB)
• auth mode aligned to security model
• production backup and rollback plan validated
• APP_BASE_URL matches public ingress used for /mcp OAuth resource binding

Screenshot placeholder: architecture comparison chart (cloud vs self-hosted).

Video placeholder: migration strategy overview.