Self-Hosted vs SaaS Agent Infrastructure: When Each Makes Sense
Self-host when you have the ops capacity, want full data ownership, and the integration cost is bigger than the operational cost. SaaS when you're early, time-constrained, or the vendor is doing something genuinely better than you would. Mix is fine — own the parts that matter, vendor the parts that don't.
Every "self-hosted vs SaaS" article makes it religious. It isn't. It's a bunch of tradeoffs that come out differently for different stacks and different points in a company's life.
The actual variables
| Variable | Self-host wins when | SaaS wins when |
|---|---|---|
| Ops capacity | Have a person who runs servers | Don't (or shouldn't waste them on this) |
| Data sensitivity | Compliance requires it | Vendor's compliance is acceptable |
| Volume | High enough to justify per-unit cost | Low — fixed cost beats per-unit |
| Vendor lock-in tolerance | Can't tolerate | Acceptable; would migrate if needed |
| Speed to ship | Time-rich | Time-poor |
| Maturity of self-host options | Self-host is well-trodden | Self-host is a half-built thing |
By subsystem
Self-host pays off above ~10k messages/month if you have someone who'll handle the MTA. Runbook here. Below 10k/mo, AgentMail or Mailgun is cheaper than your time.
Memory
Self-host (Mem0 OSS, Letta, Ujex Recall) is mature. Storage costs are minimal; the value is data ownership. Self-host wins for most cases.
Ingress / tunnels
Cloudflare Tunnel is free and excellent. ngrok or Hookdeck for local-dev. Hard to justify self-hosting unless you're at very high volume.
Audit
Self-host always — it's just code on top of any DB. Apache-2.0 libs exist. No SaaS makes sense here.
Budgets / spend caps
Self-host (Governor pattern). It's middleware, not a service.
Mobile push for approvals
FCM is free. Self-host the approval surface; rely on FCM for delivery. Hybrid.
Vector embeddings
SaaS (OpenAI / Vertex / Cohere). Self-hosted models exist but the per-call cost rarely beats the API.
The Ujex shape
Ujex is opinionated about this: one Firebase project, every subsystem replaceable at the boundary. The default is "self-hosted on your Firebase project," but every vendor (LLM, SMTP, push) sits behind a module boundary and can be swapped. We proved this when Postmark's pricing changed and we swapped to Postfix + Brevo in one day.
The implication: even if you "use Ujex," you're using your own GCP project, your own Hetzner VM (if you self-host the mail server), your own DKIM keys. Ujex is more like a kit of code + opinions than a SaaS product.
The wrong shape: full-religious
Companies that go fully self-host on day 1 either ship slowly or have someone who really likes ops. Companies that go fully SaaS on day 1 hit limits 18 months later when their email vendor doubles prices. Neither extreme is the right answer for most teams.
Start: vendor everything you can
Day 1: AgentMail for email. Hosted Mem0 for memory. ngrok or Cloudflare Tunnel for ingress. Stripe for billing. Get to product-market fit.
Then: self-host what hurts
When you hit a vendor limit (price, feature, lock-in), evaluate self-host. Self-host the things that pay off; keep vendoring the rest.
Final form: hybrid
Most mature stacks: self-hosted core + vendored commodity. Email and memory and audit owned; LLM and CDN and push vendored. That's the equilibrium.
FAQ
Is Ujex self-hosted by default?
The SDK and the deployable Cloud Functions are open Apache-2.0. The reference implementation is on GCP / Hetzner / Brevo. You bring your own Firebase project.
Can I self-host AgentMail?
No — AgentMail is closed-source SaaS. If you want the agent-native shape self-hosted, that's Ujex Postbox.
How long does it take to self-host the whole Ujex stack?
1 day for someone familiar with Firebase / GCP. 4 hours for the mail server alone (with Hetzner port-25 unblock pending).