Where Control Ends: Self-Hosting, Security, and Human Judgment
OpenSEO's deployment choice determines more than where the dashboard runs. It determines who protects the endpoint, stores the credentials, pays the provider, updates the application, configures MCP identity, and responds when evidence is incomplete. This chapter compares hosted OpenSEO, Docker self-hosting, and Cloudflare self-hosting so the reader can choose a control boundary deliberately and state which agent actions still require human approval.
The previous chapter showed that every evidence surface has operating conditions. Deployment is one of those conditions. A local crawl, a hosted OAuth grant, a personal API key, and a Cloudflare Access application create different assumptions about who can reach the system and what an agent can do when they arrive.
Three operating paths, three responsibility bundles
The hosted option minimizes infrastructure work. OpenSEO operates the application, while the user connects an agent to the hosted MCP endpoint, authenticates, selects or creates a project, and pays for hosted access and usage under the service's rules. This is usually the simplest way to test whether the workflow fits a real SEO problem. It is also the option with the least direct control over deployment details, release timing, and the underlying runtime.
Docker self-hosting is positioned as the simple path for running OpenSEO locally. The published image and compose setup make the initial installation approachable, and the operator supplies a DataForSEO key through the environment. But the local mode uses AUTH_MODE=local_noauth and a local administrator identity. The documentation is explicit about the consequence: the application must remain behind an operator-managed authenticated reverse proxy, tunnel, private network, or equivalent boundary before it is exposed beyond a trusted machine.
That warning is not a minor configuration note. If a service has no application-level authentication, the network boundary becomes the authentication boundary. A temporary tunnel or public hostname can turn a convenient local setup into an internet-facing application without the protections the operator assumes are present. The operator must know which addresses are reachable, which proxy is enforcing identity, how secrets are stored, and how the service is recreated after an environment change.
Cloudflare self-hosting is aimed at internet-facing use across multiple devices or with a team. The documented deployment provisions the Workers, D1 database, KV namespaces, R2 storage, migrations, and a Cloudflare Access login gate. Access policies can limit the application to specified email addresses, and the deployment can provide a shared workspace for approved teammates. Those conveniences reduce some application work, but they do not remove the need to understand the Cloudflare account, access policy, deployment stage, secrets, updates, and data deletion.
Connecting MCP to a Cloudflare deployment introduces another boundary. Managed OAuth must be enabled and configured with the redirect URIs used by the clients. A user can reach the web application and still fail to expose tools to an MCP client if the OAuth registration path is incomplete. The MCP endpoint is not merely another URL; it is a credentialed interface whose identity and redirect configuration must agree with the client.