Why We Self-Host Everything on One Server
When people ask what Archevi runs on, I tell them: one server. One DigitalOcean droplet. The website you sign up on, the CMS where I write blog posts, the database that stores your family's documents, the analytics, the AI privacy layer -- all of it lives on one machine.
That's not a temporary setup. That's the architecture.
Why not just use SaaS?
The obvious path for a startup is to stitch together hosted services. Vercel for the frontend. Supabase or PlanetScale for the database. Some managed CMS. Analytics from whoever's free tier looks good this quarter. You can have a working product in a weekend.
I looked at that path. Supabase was the one I seriously considered for the database. But every hosted service adds a line item, and those line items don't shrink as you grow -- they scale with you, which sounds good until you realise it means your costs scale before your revenue does. I didn't want to pass that overhead on to families who are already paying for a service they're trusting with their most sensitive data.
So I started self-hosted from day one. Not as a migration, not as a cost-cutting exercise after the fact. As a deliberate decision.
What actually runs on the server
If I were explaining this to a neighbour, I'd say the server does four things.
First, it hosts the website -- the one you visit at archevi.com, the one you sign up through. Second, it runs Strapi, which is the content management system I use to write and publish everything you read on the blog, the changelog, the feature pages. Third, it runs Umami, which is our analytics tool -- privacy-respecting, no cookies, no tracking scripts phoning home to Google. Fourth, it runs the entire AI pipeline: the document processing, the search engine, and the privacy layer that anonymises your data before it ever touches an external API.
All of that. One machine. Docker containers orchestrated to work together.
The stack includes PostgreSQL, Strapi 5, Next.js, Umami, Archevi Cortex (custom API backend), Peppermint (internal tooling), and the custom RAG pipeline. Each service runs in its own Docker container with shared networking.
The real cost
The infrastructure savings from self-hosting are significant compared to assembling the same capabilities from hosted services. But the real return isn't the money I save on subscriptions -- it's that every dollar I'm not spending on platform fees goes back into building a better experience. Better search, faster responses, more document types supported. The savings compound into the product itself.
Building this way from day one also meant I learned how every piece works together. Each tool was chosen for its ability to integrate with the others -- not because it had the slickest marketing page, but because it made the whole stack stronger.
The one thing I won't self-host
The elephant in the room is the language model. I looked at self-hosting an LLM. The privacy benefit would be enormous -- no data leaving the server at all, ever.
But GPU prices are volatile, and a server capable of running a useful language model would mean passing on a cost to users that doesn't make sense for a product aimed at families -- not enterprises with IT budgets.
So we use external LLMs (Groq and Cohere), but we built the anonymisation layer so that what leaves the server is stripped of anything personal. It's a compromise, and I've written about how that works in detail. But it's an honest one.
Self-hosting isn't all or nothing. The question isn't "can you self-host everything?" -- it's "which parts give you the most control for the least cost?" For us, that's everything except the LLM inference.
What nobody warns you about
Self-hosted software has limitations that hosted services have already solved for you. Some features are paywalled behind enterprise tiers. Documentation can be patchy or outdated. API endpoints change without much notice.
And the big one: if something breaks at 2am, there's no support team to call. No status page to check. No incident response from a vendor. It's on me. I built it, I maintain it, and when it goes down, I'm the one who fixes it.
I've built monitoring and alerting so I know when something goes wrong -- any issues, any leaks, anything that could affect a user. But there's no pretending: the tradeoff for control is responsibility. Every piece of the stack that I own is a piece of the stack I have to maintain.
Why it matters
Here's the thing that makes all of that worth it: when a family uploads their mortgage documents, their insurance policies, their kids' medical records to Archevi, I can tell them I know exactly where that data is. Not "it's in the cloud somewhere." Not "our provider handles that." I know the server. I know the database. I know every container that touches their information.
The more third parties a product is built on, the more risk. Every integration is a dependency, and every dependency is a point where you lose control. By self-hosting, I'm not waiting for someone else's fix. I'm not reading someone else's incident report. I'm accountable -- fully, personally accountable -- for every piece of the system.
That's what building for trust actually looks like. Not a privacy policy. Not a compliance badge. An architecture where the person who built it can point to exactly where your data lives and tell you exactly what happens to it.
If you're considering self-hosting for your own project, start with a clear inventory of what you actually need hosted services for versus what you're paying for out of convenience. You might be surprised how much of your monthly bill is convenience tax.
