A self-hosted infrastructure starter kit for solo founders (what to self-host and what not to)

Three years ago I paid for 47 separate SaaS subscriptions to run a sole operator practice. Today I pay for 11. The other 36 are self-hosted on machines I own. The math worked out to about £18,000 a year that stays in my pocket, and that's before counting the things I now own outright. The numbers are the small part of the story. The bigger part is that I now understand my own stack, my own data lives on hardware I can touch, and no vendor can sunset a feature I depend on for a Monday morning client deliverable.

I want to give you the playbook I wish someone had handed me. This is not a list of cool tools. It is the decision frame, the actual starter kit, the things you should never self-host, the honest costs, and a 7-day sprint to get a usable self-hosted stack running. By the end you will know whether this path is worth your time, and if it is, you will know where to start.

The starter-kit decision frame

Before you self-host anything, run it through four questions.

One: does this need to be available when I am asleep on a different continent? A personal note-taking app does not. A payment processor that drives client checkout does. The first you can self-host without a second thought. The second you should not touch.

Two: does this contain data I cannot afford to lose to a vendor pivot? If a SaaS vendor raises prices 4x, deprecates the export feature, or gets acquired and sunsets your tier, can you walk away with your data intact? For most operator-facing tools (notes, files, code, client records) the answer should be a clean yes. Self-hosting solves this.

Three: does the SaaS pricing scale with usage in a way that punishes growth? Per-seat pricing, per-API-call pricing, per-record pricing. These are tax on success. If your usage is going to grow with your business, owning the infrastructure caps your costs.

Four: am I the only operator, or does a team need access? Solo means you have full control of the environment. The moment you have collaborators, the calculus shifts because you become the support desk. For a one-person shop, that is fine. For a five-person team, you need someone whose job is keeping it running.

If a tool clears three of those four hurdles, it is a self-hosting candidate. If it clears two or fewer, leave it on SaaS.

The 10-category starter kit

Here is what I would actually self-host first, in priority order, if I were starting over as a solo operator today.

1. Mesh VPN. This is the foundation. Every other service binds to a private network only your devices can reach. WireGuard is the underlying protocol. You can run it directly or use a mesh-style overlay that handles key rotation for you. Once this is running, your laptop, phone, and any servers you own can talk to each other as if they were on the same LAN, from anywhere. Setup is one afternoon. Everything downstream gets simpler.

2. Self-hosted git. Your code, your configs, your notes, your client deliverables. All of it deserves to live somewhere you control. A self-hosted git platform on a small server gives you GitHub-like workflow without trusting a third party with your most valuable IP. Migration from GitHub is straightforward, and you can keep GitHub as a mirror for public repos. I keep 38 repos on mine. It costs nothing extra to add another.

3. Password manager. A self-hosted password vault that speaks the same protocol as the popular SaaS option means your existing browser extensions and mobile apps work unchanged. The vault file lives on your hardware, accessible only over the mesh VPN. I have 312 credentials in mine. Losing access to them would end my business in 48 hours, which is exactly why I do not want them sitting on someone else's servers.

4. Reverse proxy + TLS. Once you have services running on private IPs, you want clean HTTPS URLs to access them. A modern reverse proxy handles TLS termination automatically using Let's Encrypt. You point a DNS record at your server, the proxy handles certificate provisioning, and you get https://service.yourdomain.com without thinking about it. This is the glue that makes everything else feel professional.

5. Container orchestration. Docker is the workhorse. On a Mac Mini, OrbStack is the local-machine wrapper of choice for performance and battery. On a Linux server, plain Docker Compose is enough for solo-scale deployments. Every service in this list runs as a container. The compose file is your stack documentation, version-controlled in the self-hosted git from step two.

6. Metrics and dashboards. InfluxDB for time-series data, Grafana for dashboards. This sounds excessive for a solo operator. It is not. The moment you have three or four services running, you want to know which one is using all your RAM, which API is costing you money, which workflow is taking 40 seconds instead of four. Grafana gives you that view. I have 13 dashboards. The one I check daily takes 30 seconds to scan.

7. File and photo management. Immich for photos (it is what Google Photos pretends to be, but local), plus a paperless-style document scanner that OCRs every PDF you feed it. Receipts, contracts, ID documents, anything paper. You scan once. You search for "invoice March 2024 acme" five years later and find it in two seconds. This is the category most people underestimate, because the savings are non-obvious until you have used it for a year.

8. Personal RAG and local AI. Qdrant is a vector database. Ollama runs language models on your own hardware. Together they let you embed your entire knowledge base, your client notes, your past emails, and query them with a local LLM. No data leaves your machines. The models are not as capable as Claude or GPT-4, but they are good enough for personal-knowledge search, classification, and summarisation. The marginal cost is zero once you have the hardware.

9. Self-hosted analytics. If you run a website, you want traffic data. The SaaS analytics options range from invasive (Google) to expensive (Fathom). The self-hosted options are mature, lightweight, and put no third-party JavaScript on your site. Your visitors get faster page loads, you get the data, and nobody gets a GDPR headache.

10. Newsletter platform. Audience size is the one asset you do not want renting from a vendor. A self-hosted newsletter platform handles list management, double opt-in, click tracking, and templating. You still need a transactional email relay (see the next section) but you own the list, the templates, and the analytics. Migrating off the major SaaS newsletter platforms is harder than it should be. Better to start self-hosted than retrofit it later.

What NOT to self-host

Five categories where I have learned, sometimes painfully, that SaaS is the right answer.

Email delivery. Sending email from your own IP address is a five-year project in reputation management, and getting it wrong means your client invoices land in spam. Use Resend, Postmark, or AWS SES as a relay. You can still host the application that composes the email. Just hand off the actual delivery.

Payment processing. Stripe. Done. Do not self-host this. The compliance surface is enormous, the fraud-detection infrastructure you would need to build is a full company, and the cost of getting it wrong is your business.

Identity for B2B. If clients need SSO into anything you operate, use an established identity provider. The standards are well-defined, but the edge cases (recovery flows, account merging, audit logs) are a swamp.

Critical alerting. If your phone needs to ring at 3am because production is down, you want a vendor whose entire business is making that phone ring. Self-hosted monitoring is fine for everyday observability. For pager-grade alerting, pay PagerDuty or Opsgenie.

LLM inference for production. Local models on Ollama are useful for personal tooling and prototypes. For client-facing AI features, the per-token economics of Claude, GPT-4, or Gemini are still better than running your own GPU. You do not want to be the GPU operations team for your own product.

The 7-day starter sprint

Here is how to bootstrap a working self-hosted stack in a single week.

Day 1: Buy or repurpose a Mac Mini M4 (£600) or a Linux mini-PC. Add external storage (£200). Set up the mesh VPN. Get your laptop, phone, and the new machine talking to each other on a private network.

Day 2: Install Docker or OrbStack. Stand up the reverse proxy. Point a wildcard DNS record at your server. Verify you can get a Let's Encrypt certificate.

Day 3: Spin up the self-hosted git platform. Migrate three of your most-used GitHub repos. Set up SSH access over the mesh VPN. Configure GitHub as a mirror remote.

Day 4: Deploy the password manager. Import your existing vault. Configure browser extensions and mobile apps to point at the new server. Verify autofill works on three sites.

Day 5: InfluxDB and Grafana. Build one dashboard: CPU, RAM, disk, network. Watch it for an hour. Add a second dashboard for whatever else matters to you.

Day 6: Photos and documents. Immich for the photo library. Paperless-NGX for the document store. Start with one month of receipts and see how the OCR feels.

Day 7: Document what you built. Update the compose files in your self-hosted git. Write a half-page recovery playbook for your future self. Take the day off. You earned it.

The honest costs

Hardware: Mac Mini M4 around £600, external SSD £200, modest cloud server around £20/month for the always-on services. First-year total around £1,000.

Time: 80 hours of setup spread across that first month if you have never done this before. Ongoing maintenance averages 5 hours a month once stable, less in steady weeks, more when you upgrade.

What breaks first: SSL certificates if you misconfigure auto-renewal, Docker disk usage if you forget to prune images, and your patience the first time a service decides to silently stop running and you have not yet wired up alerting. None of these are fatal. All of them teach you something about your own stack.

What you get back

Data sovereignty. Vendor-lock-out immunity. Lower marginal cost on every new internal tool. Faster iteration, because you control the deployment. Real understanding of what your business actually runs on. And a kind of operational confidence that I think most solo founders never experience, which is knowing exactly where every byte of your business lives.

What you give up

The implicit reliability of SaaS. The "it just works" experience. Vendor support tickets. Plug-and-play integrations between tools. A clean Monday-morning email from a customer success manager. If you are early in your career and you need to focus 100% of your attention on the business itself, the SaaS path is the correct trade. If you are five years in and the SaaS bills are starting to feel like rent on a house you wish you owned, this path is for you.

My current stack snapshot

For shape, not for replication. The point is the ratio.

Self-hosted: source code, password vault, photos and documents, container orchestration across two physical sites, observability stack, personal RAG, mesh VPN, internal automation engine, self-hosted git mirror of GitHub, newsletter platform, content delivery for client deliverables, knowledge-base search.

Still on SaaS: payment processing (Stripe), email delivery relay, domain registration, transactional SMS, two production AI APIs, cloud object storage for off-site backups, vendor-supplied identity for client SSO, monitoring for pager-grade alerting.

The ratio is roughly 75% self-hosted, 25% SaaS. I suspect that is close to the right answer for most solo operators.

10-step playbook for starting today

1. Buy the hardware. Mac Mini M4 or equivalent Linux box.
2. Register a domain you do not mind being tied to your internal services.
3. Set up the mesh VPN. Get three devices on the network.
4. Install Docker or OrbStack on the new machine.
5. Stand up the reverse proxy. Confirm Let's Encrypt is working.
6. Migrate one critical SaaS workflow to a self-hosted alternative. Just one.
7. Run both versions in parallel for two weeks.
8. Decommission the SaaS subscription. Cancel it. Feel the small shiver of independence.
9. Repeat steps 6 through 8 for the next category on the list above.
10. Document everything as you go in your self-hosted git.

If you complete this list, you will have built a usable starter kit within three months. The compounding starts at month four, when you stop needing new SaaS subscriptions for new internal tools because the infrastructure to self-host them is already there.

FAQ

Is this practical for someone who is not technical? If you can follow a Docker Compose tutorial, you can do this. If you have never touched a terminal, hire someone for the first weekend. I genuinely think the agency tier for operators who'd rather buy this expertise than build it is the right move for most non-technical founders. See the agency tier for operators who'd rather buy this expertise than build it.

What happens when my Mac Mini dies? Backups. You restore from off-site backups to a new machine. The recovery playbook from day 7 of the sprint is what makes this a 2-hour task instead of a 2-week project.

Is this GDPR-friendly? More so than most SaaS, because your processor list shrinks dramatically and the data residency story is whatever you decide it is.

Can I sell access to anything I self-host? Read the licences. Most of the open-source tools in this stack are AGPL or MIT. AGPL has implications if you offer the service over a network to third parties.

What is the institutional version of this? Running your own facilities-management discipline, like the institutional equivalent of self-hosting. Same instinct, different scale.

Where do I learn more? Start with my brand context page, then read Cornerstone 1 on building the agent-readiness layer, then browse the skills index for the granular how-to material.

---

Built by Weir Digital Media.