It's one engineer. On purpose.

No agency, no account managers, no junior doing the work a brochure promised a senior would. The person who reads your bill is the person who designs the migration and runs the servers. Here's why that's an advantage — and where I'm honest about the limits.

You work directly with the person doing the work

When you hire a firm, your problem gets passed down a chain — sales promises it, a manager scopes it, a junior builds it, and the senior you were sold appears only when something breaks. With me, there's no chain. I read your cloud bill, I design the target, I do the migration, and I run it afterwards. Nothing is lost in translation because there's no translation.

My incentives point the same way as yours

I'm not a reseller and not an affiliate — I take no commission from OVH, Hetzner, Cloudflare, or anyone. I'm not paid more when you use more. The managed plan makes this literal: a flat base plus a share of the savings I can prove against your starting bill, so I make money when your infrastructure gets cheaper and stays boring. That's why I'll tell you when not to migrate, and why I price the cost of running things honestly instead of selling you a "near-zero cost" fantasy.

A bigger firm's incentive is a bigger engagement. Mine is a smaller bill you stop thinking about.

The fair question: "what if you're unavailable?"

One engineer is a real single point of failure, and you should ask about it. So here's the honest answer — the whole setup is built so you are never dependent on me:

• Standard open-source only. Everything I deploy is mainstream OSS (Postgres, nginx/Caddy, Restic, SeaweedFS, Prometheus) that any competent engineer — or your own team — can run. No proprietary glue, no lock-in to me.
• You own the setup, fully documented. Runbooks, configs, and credentials are yours from day one, in your accounts and your repos. If I vanished tomorrow, you'd have a working, documented system and could hand it to anyone.
• Clear boundaries in writing. Managed plans state exactly what's covered, response windows, and the escalation path — including a backup contact for genuine emergencies. No vague "trust me."
• Insured. Professional liability cover and contractual caps, like any serious provider.

The irony: a self-hosted, standard-OSS setup you own is less locked-in than a cloud account wired to one vendor's proprietary services. Independence from me is the same independence I'm selling you from AWS.

Where I'm honest about the big dependencies — including Cloudflare

I use good tools where they earn their place. Cloudflare's free tier, for example, is the best free DDoS and global-network protection you can get, and I'll often put it in front of your origin. But I'll say plainly what most consultants won't:

Cloudflare is one of the largest single points of failure on the internet. It sits in front of a huge share of the web, and when it has a bad day, an enormous number of sites go down with it — through no fault of their own. Convenient, yes. But being dependent on it is the very centralization risk you're leaving AWS to escape.

So I design for it: your origin works without Cloudflare, you can fail away from it, and nothing critical assumes it's there. It's a layer you benefit from, not a vendor you're hostage to. The whole point of going distributed is simple — the fewer giant shared dependencies your business shares a fate with, the more resilient you are when one of them stumbles. That principle applies to AWS, to Cloudflare, and yes, to me.

Where this is heading

The more independent businesses run their own infrastructure, the more they can back each other up. The natural next step — once enough like-minded companies are doing this — is a small, trusted mesh where each one contributes a little spare capacity so the group depends less on any single giant provider. That's the direction. For now the win is concrete and immediate: your own anchor, honest failover, a predictable bill, and no shared fate with one hyperscaler (AWS, Azure or Google).

Who I am

What gets me out of bed is the seam between software and infrastructure — and the real-world bill that seam quietly generates. I'm mindful of the unglamorous parts most teams under-invest in until they hurt: database efficiency, backups, disaster recovery, and infrastructure that stays resilient without breaking the bank or making you a captive customer of Google, AWS or Microsoft/Azure. I lean hard on free, open-source tools precisely because they keep your stack portable and resilient — you can pick it up and move it, instead of being locked into one provider's dialect. And I don't believe in rip-and-replace: the right move is usually a gradual, low-risk path — reduce dependence on the big three one workload at a time, shift to cheaper-but-just-as-reliable services, and where it makes sense bring parts of the system into your own office — all without disruption.

I'm Ami Heines, a senior infrastructure, systems, and applied-cryptography engineer. I don't just recommend self-hosting — I run production services this way myself: mail, storage, DNS, and live applications on servers I own, behind dynamic DNS, in the real world with real uptime. I've felt every sharp edge this work has, which is exactly why I can tell you which ones are worth it and which ones aren't.

Before infrastructure I spent more than 20 years as a software developer — not only running servers, but building the applications on them. I started in databases (MS Access, then Microsoft SQL Server) and built systems through Visual Basic, PHP and MySQL, and later Node.js, including security-sensitive work on logins and key management (WebAuthn, blockchain wallets). That's why I can take the whole move off AWS from plan to a finished migration: it isn't only an operations job — someone has to safely move your application and your data, and write the code that connects it all. I can design the new setup and build it, not just recommend it — and the database, the part most teams are afraid to touch, is where I started.