Self-Hosting AI Infrastructure Looks Free Until You Add Up the Hours
The Appeal of Self-Hosting
The pitch for self-hosting AI infrastructure is straightforward: you control everything, your data never leaves your servers, and you avoid recurring subscription costs. For the right team in the right situation, that trade-off makes sense.
But "the right team" is narrower than most people assume when they're setting it up.
What follows is an honest look at what self-hosting an AI agent platform actually requires — the infrastructure, the ongoing maintenance, the security burden — and where managed cloud infrastructure like OIDO Studio genuinely saves you time, money, and operational pain.
What You're Actually Running When You Self-Host
A production AI agent stack is not a single service. Here is what OIDO's self-hosted deployment requires:
services:
- traefik # reverse proxy + TLS termination
- oido-studio # Next.js frontend
- oido-core # Go API server
- oido-inference # embedding + reranking service
- postgres # database with pgvector extension
- rustfs # S3-compatible object storage
- n8n # workflow automation
- sandboxes # isolated execution environments
Each service needs to be configured, networked, and kept running. Traefik needs TLS certificates — which means pointing DNS, managing ACME challenges, and handling certificate renewal. PostgreSQL needs the pgvector extension specifically, not just any Postgres install. The inference service needs to be running and reachable by the API server. Object storage needs to be provisioned and connected.
On a good day this takes a few hours to set up. On a day where a certificate expires quietly in the background, or a database migration fails on an update, or pgvector breaks on a Postgres upgrade, it takes longer.
The Ongoing Cost Nobody Budgets For
Setup time is visible. Maintenance time is invisible until it's not.
Security patches — The AI tooling ecosystem moves fast. Dependencies change, vulnerabilities are disclosed, model APIs update. Someone needs to track these and apply updates on a schedule. A self-hosted instance that hasn't been updated in three months is running known vulnerabilities.
Authentication hardening — A production auth system requires brute-force protection, session management, rate limiting, and lockout policies. These aren't features you add once; they need to be monitored and tuned. OIDO's cloud deployment enforces exponential backoff on failed logins, automatic lockouts after five failures, and session expiry by default. In a self-hosted environment, you configure this yourself or you don't have it.
SSL certificate management — Let's Encrypt certificates expire every 90 days. Automatic renewal works until it doesn't — wrong permissions, a DNS propagation issue, a Docker restart that didn't come back up. When a certificate expires silently, your agents stop responding and your users see a browser error.
Database maintenance — Postgres needs vacuuming, index maintenance, connection pool tuning, and backup verification. The pgvector extension needs specific version compatibility. Adding a team member who runs a schema migration incorrectly can take your entire agent stack offline.
Monitoring — How do you know something broke at 2 AM? A self-hosted deployment without alerting is a deployment where you find out about outages from users. Building meaningful monitoring for all the above services is itself a project.
None of this is extraordinary — it's standard infrastructure work. But it's work that doesn't build your product, serve your customers, or improve your agents. It keeps the lights on.
The Team Management You Build or Buy
Multi-user access to an AI platform has its own surface area.
When you add a second person to a self-hosted deployment, you need to answer questions like: can they create agents? Can they access all integrations? Can they see other users' sessions? Can they change the model configuration?
OIDO's cloud deployment includes role-based access control with fine-grained permissions across every resource:
| Resource | Actions controlled |
|---|---|
| Agents | use, create, edit, delete, share |
| Extensions | use, create, edit, delete |
| MCP servers | use, create, edit, delete |
| Providers | use, create, edit, delete |
| Tools | use, create, edit |
| Storage | use, create, edit, delete |
An admin can lock down tool access for non-admin members, restrict which integrations specific teams can use, or prevent agents from being shared outside the organization. This permission model is already built and tested. In a self-hosted deployment, you build it yourself or you run with everyone having full access to everything.
Features That Require Infrastructure You May Not Have
Some OIDO features have non-trivial infrastructure dependencies:
Semantic search (Wiki) requires pgvector — not just Postgres, but Postgres with the vector extension compiled and installed. Many managed Postgres providers support it now, but a standard self-hosted Postgres install won't have it without extra steps.
Embedding and reranking requires a dedicated inference service (oido-inference) running a compatible embedding model. This is a separate process that needs compute and memory, especially for larger documents or high ingest volume.
Channels (Slack, Discord, email, webhooks) require publicly accessible endpoints with valid SSL certificates. A self-hosted deployment on a home network or a VPN-isolated server can't receive webhooks without additional tunneling setup.
Scheduled agents require the scheduler service to be running continuously, with reliable system time and process management. If the host server reboots, your scheduled agents need to come back up automatically.
In OIDO Studio's cloud deployment, all of this is provisioned as part of the platform. You enable the feature; we run the infrastructure.
Who Should Actually Self-Host
Self-hosting is the right choice in specific situations:
Data residency requirements — Regulated industries (healthcare, finance, legal in certain jurisdictions) may have hard requirements that data never leaves a specific geographic region or a specific network perimeter. If your compliance officer has said "no data in US data centers," that constraint overrides convenience.
Existing infrastructure teams — If you have a dedicated DevOps function that already runs Kubernetes, manages Postgres clusters, and handles certificate automation, the marginal cost of adding OIDO to that stack is low. They have the tooling and the expertise.
Air-gapped deployments — Security teams operating in classified or isolated environments where any external dependency is a risk need to run everything on-premises. OIDO supports on-premise deployment on the Enterprise plan for exactly this reason.
Very high volume — At some token volume, the economics of cloud change. If you're running millions of inferences per day, the cost of managed infrastructure can exceed the cost of running your own hardware. Most teams don't hit this threshold.
If none of these apply to your situation, you're paying an ongoing operational tax that doesn't serve your core work.
What You Get on Day One With OIDO Studio
When you sign up for OIDO Studio, you get:
- Multi-user team management with RBAC, no configuration required
- Usage tracking by agent, user, session, and model — visible immediately
- All supported LLM providers pre-integrated; connect your API key and go
- Channels, MCP servers, extensions, and scheduled agents available on the appropriate plan
- TLS, authentication, brute-force protection, and session management handled
- Wiki with pgvector search, inference service for embeddings, and daily rollup jobs running in the background
- Updates applied to the platform automatically — new model support, security patches, feature releases
The free tier gives you enough to build a real agent and understand the platform. Pro and Enterprise tiers add higher limits, team features, and SSO/SAML for organizations that need it.
The Honest Comparison
Self-hosting isn't inherently bad. It's a trade-off. The question is whether you want to spend engineering time on AI infrastructure operations or on the things your users actually need.
For most teams — startups, small-to-medium businesses, product teams inside larger companies, agencies deploying AI for clients — the answer is clear. The operational complexity of a self-hosted AI stack is real, it compounds over time, and it doesn't build your product.
OIDO Studio is built for teams who want the capability without the complexity. Deploy your first agent in five minutes. Add your team without a permissions audit. Watch token usage across every model without setting up monitoring. Let the platform handle the infrastructure.