Smb

You're asking the right question, and the honest answer is: most SMBs need far less than the industry sells them. If you have a competent team of OpenBSD/Linux operators and developers, you can run a surprisingly large business on a couple of machines. The cloud-and-cluster story is mostly driven by forces that have little to do with what an SMB actually needs.

What does an SMB actually need?

Let's be concrete. A typical SMB say 20 200 employees, a line-of-business app, a website, internal tools, maybe some e-commerce needs roughly:

• 1 3 application servers (can be VMs or bare metal)
• 1 database server (with a replica if they care about uptime)
• 1 reverse proxy / load balancer
• 1 backup target (offsite)
• 1 monitoring/logging box (can be the same as something else)
• A Git host + CI (this is where your Gitolite setup fits perfectly)

That's it. A team of two or three good OpenBSD/Linux operators can run this better than a Kubernetes cluster, because they understand the whole stack, can debug it end-to-end, and there's no abstraction layer hiding problems from them.

The dirty secret: a single well-configured server with good backups often has better uptime than a badly-run Kubernetes cluster. Complexity is not reliability.

So why does everyone push cloud and "gazillions of servers"?

Several reasons, and only some of them are technical:

1. Venture capital and SaaS economics
Cloud providers and SaaS vendors need growth. Their business model requires you to consume more. "You need to scale" is a sales pitch, not always an engineering reality. Most SMBs have predictable, modest load the opposite of what cloud elasticity is designed for.

2. The "we might get big" fallacy
Founders and CTOs often build for the company they hope to become, not the one they are. So they adopt Kubernetes, microservices, and multi-region deployments for a product with 500 users. This is a classic and expensive mistake.

3. Hiring and r sum signaling
Engineers want to work with modern tools. Kubernetes on a r sum is worth more than "I maintain three OpenBSD boxes." So the tooling choice is partly driven by recruitment, not requirements.

4. Vendor lock-in disguised as convenience
Managed services (RDS, S3, etc.) are genuinely convenient, but they also make it hard to leave. An SMB that runs Postgres on its own box can move it anywhere. An SMB deep into AWS-specific services is stuck.

5. Compliance theater
Some auditors equate "cloud" with "secure." It's not true, but it drives decisions. A well-run on-prem OpenBSD box with proper backups, monitoring, and access control can be more compliant than a misconfigured S3 bucket.

What an SMB genuinely needs vs. what it's sold

Real need	What's often sold instead
Reliable uptime	"Five nines" multi-region HA
Backups that restore	Snapshots that were never tested
Fast deploys	Full CI/CD pipeline with 40 stages
Security	A pile of SaaS security tools
Predictable cost	Pay-as-you-go that spikes
Simple debugging	Distributed tracing across 12 services

For an SMB, boring and understandable beats clever and distributed almost every time.

Where your approach genuinely wins

With a small, skilled OpenBSD/Linux team, you get:

• Lower cost: A few hundred euros/dollars a month in hardware or VPS, vs. thousands in cloud spend.
• Full control: No surprise bills, no API deprecations, no forced migrations.
• Debuggability: You can ssh in and see everything. No black boxes.
• Data sovereignty: Important in the EU and for certain clients.
• Simplicity: Fewer moving parts = fewer failure modes.
• Longevity: OpenBSD and Linux will still work in 15 years. Your cloud vendor's specific service might not.

Where it can bite you

Being honest about the tradeoffs:

• Bus factor: If your two operators leave, you're in trouble. Mitigate with documentation and hiring.
• Physical security: On-prem means someone can steal the box. Offsite backups and encryption fix this.
• Scaling spikes: If you genuinely go viral, you'll scramble. But this is a good problem, and you can rent a bigger VPS in an hour.
• Compliance perception: Some clients/auditors will ask "are you on AWS?" and you'll have to explain. Annoying but manageable.
• Talent pool: Fewer people want to run OpenBSD than Kubernetes. Hiring is harder.

The real answer

Most SMBs need:

• 2 5 servers, not 200.
• Backups, not multi-region replication.
• A deploy script or Ansible playbook, not a GitOps operator.
• Monitoring they understand, not a observability platform.
• A team that knows the whole stack, not 12 specialists.

Cloud and "gazillions of servers" are needed by:

• Companies with genuinely unpredictable, massive scale (Netflix, Twitter).
• Companies whose business model is the cloud (SaaS vendors).
• Companies that have chosen to outsource operations entirely.
• Companies that have more money than operational skill.

If you have the operational skill which you clearly do you can run an SMB on a fraction of what the industry tells you is necessary. The main risks are bus factor and talent acquisition, not technology.

Your instinct is correct. The industry over-sells complexity to SMBs because complexity is profitable to sell. A small team of good Unix operators with Gitolite, a few well-maintained boxes, and solid backups can outperform a bloated cloud setup for years.