What "just self-host it" actually costs
Self-hosting an MCP server is a real option, and this is what it actually involves next to a foro.sh deploy: whose cloud it runs on, how long it takes to get live, what a rushed setup gets wrong, and what you can see once it's running.
| Dimension | foro.sh | Self-hosting it |
|---|---|---|
| Time to a live URL | About a minute, from a Git repo you already have | Days to weeks: a Dockerfile, a reverse proxy, TLS, and a redeploy flow, before the first real deploy |
| Where it runs | OVH Groupe SAS, France - no non-EU parent anywhere in the ownership chain | Usually a US-incorporated hyperscaler, even inside its "EU region" - still reachable by a US CLOUD Act warrant |
| Container & network isolation | One container and one private network per project, by construction | Whatever you design - commonly one shared network until isolation is deliberately built in |
| Secrets | Encrypted at rest with libsodium, injected at container start, redacted from every log | Your own design - a real risk window is a .env committed to git, or a value baked into an image before a secrets pipeline exists |
| TLS & routing | Automatic Let's Encrypt wildcard certificate and routing on every deploy | Your own reverse proxy config, certificate renewal, and DNS to keep working |
| Observability | Per-tool metrics, p95 latency, and live deploy/build/runtime logs, with nothing to instrument | Nothing, until it is built - commonly the piece a first deploy defers past launch |
| Ongoing maintenance | Push to redeploy; health-checked before it goes live, the previous version keeps serving until then | Yours to patch, update, and watch - a skipped update is how a server goes down or stays exposed |
The same fourteen, named on each cloud
Those rows are fourteen separate pieces of infrastructure. Here is what each one is called on AWS, GCP and Azure, so you can price the work rather than take our word for it. Three of the fourteen have no managed equivalent anywhere.
| What you need | AWS | GCP | Azure |
|---|---|---|---|
| Isolated compute per project | ECS Fargate service per project, or an EKS namespace | Cloud Run service per project, or a GKE namespace | Container Apps revision per project, or an AKS namespace |
| Container registry | ECR | Artifact Registry | ACR |
| Build pipeline | CodeBuild, or a self-hosted Actions runner | Cloud Build | ACR Tasks or Azure Pipelines |
| Reverse proxy and routing | ALB with host-based listener rules, updated on every deploy | Cloud Load Balancing with a URL map per project | Application Gateway or Front Door, rules per project |
| TLS certificate | ACM wildcard certificate | Certificate Manager, self-managed: Google-managed certificates do not cover wildcards | Key Vault issued wildcard certificate |
| DNS records | Route 53 wildcard record | Cloud DNS wildcard record | Azure DNS wildcard record |
| Private network per project | VPC subnet and security group per project | VPC and firewall rules per project | VNet and NSG per project |
| Secrets at rest and injection | Secrets Manager with KMS | Secret Manager with Cloud KMS | Key Vault |
| Auth gate on every endpoint | Nothing managed on any of the three. No cloud ships "gate every endpoint by default" - this is code you write and then own. | ||
| Log storage and retention | CloudWatch Logs with an S3 archive | Cloud Logging with a GCS archive | Azure Monitor Logs with Blob Storage |
| Live log streaming | Nothing managed on any of the three. A streaming relay you build, run and keep up. | ||
| Per-tool metrics | CloudWatch custom metrics, plus a sidecar you write to read the protocol | Cloud Monitoring custom metrics, plus that same sidecar | Azure Monitor custom metrics, plus that same sidecar |
| Health-checked rollout and rollback | ECS deployment circuit breaker, configured per service | Cloud Run traffic split between revisions | Container Apps revision traffic split |
| Quotas across projects | Nothing managed on any of the three. Your own accounting, so one runaway agent cannot take the others down. | ||
Managed services shorten some of these. None of them removes the wiring, the per-project provisioning on a first deploy, or the upkeep afterwards. And a push-triggered GitHub Actions workflow is free on all three clouds, but it still has to build the image, roll it out, wait on the health check, roll back when that fails, and create the routing, isolation and secret resources the first time a project deploys.
Build this for more than one team and three more join the list: a state database, a job queue with a worker, and the sign-in and session glue. That is where the number people quote as fifteen comes from, and it is the point at which you have stopped shipping your product and started running a platform.
Whose cloud it actually is
Picking an "EU region" from a US-incorporated hyperscaler satisfies a residency checkbox; it doesn't change which legal system can compel that provider to produce data. A US CLOUD Act warrant reaches the company, not the country the disks sit in - so a self-hosted server on AWS, GCP, or Azure stays reachable that way regardless of region.
foro.sh runs on OVH Groupe SAS, a company incorporated in France, and is operated by a Netherlands sole proprietorship with no US parent anywhere above it. There is no entity in that chain for a CLOUD Act warrant to reach. The full breakdown names the provider, the operating entity, and the narrow paths that do cross a border.
The first afternoon, or the first month
A first self-hosted deploy is usually a Dockerfile, a reverse proxy, a TLS certificate and its renewal, a decision about how containers get isolated from each other, and a redeploy path that doesn't take the server down while it runs - built once, by whoever is doing this for the first time.
foro.sh is that stack, already built: a Git repo becomes a live URL in about a minute, with the reverse proxy, the certificate, and the health-checked redeploy already wired up.
How a rushed deploy leaks data
The common failure mode in a first self-hosted setup isn't a sophisticated attack - it's a container that shares a network with services it has no reason to reach, or a secret that ends up in an image layer or a Dockerfile ARG before anyone builds a real secrets pipeline. Isolation and secrets handling are both things a first deploy tends to defer, not skip on purpose.
Every foro.sh project gets its own container and its own private network by construction, and every secret is encrypted at rest and redacted from logs from the first deploy, not the one after an incident.
What you can't see until it breaks
Metrics and structured logs are rarely part of a first deploy - they get added later, often only once something has already gone wrong and there's nothing to look at. Until then, a self-hosted MCP server is a container you can restart, not one you can actually watch.
foro.sh reports per-tool metrics, p95 latency, and live deploy, build, and runtime logs from the first deploy, with nothing to instrument in your own code.
When self-hosting still makes sense
If isolation, secrets management, and observability are already solved on infrastructure your team operates for other services, adding an MCP server to that stack can be genuinely cheaper than a first deploy elsewhere - the setup cost above is mostly sunk already. foro.sh is aimed at the far more common case: a team without that stack, or one that would rather not put an MCP server on it.
Isn't self-hosting cheaper?
Compute alone, maybe. What that doesn't price in is your time: a Dockerfile, TLS, isolation, secrets handling, and observability are all still yours to build first, and yours to keep patched afterward. Free starts at one server with no payment method - the same comparison with the setup time removed.
We already run infrastructure for everything else - doesn't that make self-hosting cheap for us?
Often, yes. If isolation, secrets, and observability are already solved on a stack you operate, adding one more workload there can genuinely be cheaper than a first deploy. foro.sh is built for the common case: a team without that stack, or one that would rather not put an MCP server on it.
Can I move my server off foro.sh later?
Yes. A project on foro.sh is a Git repo, its own pyproject.toml or package.json, and a standard container image - nothing proprietary to unwind. Leaving is a docker build away, not a migration project.
Your first server, live in a minute.
Sign in, pick your project, click Deploy. No credit card required.