Running a business from one laptop and six servers

The setup, plainly

I run my business off one laptop and six servers. The laptop is where I work: browser, terminal, editor, the usual. The servers do the things that need to run whether or not I’m awake. That split sounds obvious once you say it out loud, but most solo operators blur it, and then they’re the single point of failure for everything from rendering a video to answering a customer.

The laptop is disposable in a way the servers aren’t. If it dies tonight, I lose a few hours of local work and nothing else. The servers hold state: databases, running services, scheduled jobs, the actual infrastructure customers touch. That asymmetry is the whole point of the design. You want your daily driver to be replaceable and your infrastructure to be boring and stable.

Why six servers and not one

People assume “six servers” means six times the complexity. In practice it means less complexity per server, because each one has a narrow job. One runs customer-facing services. Others handle background processing, monitoring, or isolated workloads that I don’t want sharing resources or blast radius with anything customer-facing. When something breaks, and things do break, the failure is contained to whatever that box was doing.

The alternative, cramming everything onto one big machine, feels simpler until the day a runaway process on one service takes down an unrelated one because they were fighting over the same CPU and memory. I’ve had that happen. Splitting workloads across machines isn’t over-engineering, it’s just removing shared failure points you didn’t choose on purpose.

None of this requires exotic orchestration. It’s SSH, cron, systemd, and scripts that do one thing. The unglamorous stuff is what actually stays up.

Where AI agents actually fit

I use AI agents daily, but not as a magic layer that runs the business for me. They’re tools that operate inside a boundary I define. An agent that touches my content pipeline can draft, tag, and queue an article. It cannot publish without a rule-based check passing first. An agent that watches infrastructure can flag an anomaly and even take a predefined remediation step, like restarting a specific service, but it doesn’t get free rein over servers holding customer data.

This is the tradeoff nobody selling AI wants to say out loud: agents are useful in proportion to how well you’ve scoped what they’re allowed to touch. A vague instruction to “manage the servers” is a bad idea regardless of which model is behind it. A specific instruction wired to a specific tool, with a specific and narrow set of permissions, is where agents actually save time. The narrower the job, the more reliably it gets done.

I don’t believe agents replace the judgment calls that come with running a business. They replace the repetitive parts that used to eat my day: checking logs, drafting first passes of content, watching dashboards for a pattern I’d otherwise have to notice manually. The decisions about what to build, what to ship, what to fix first, those stay with me.

MCP as the wiring, not the magic

Model Context Protocol is what lets an agent talk to a specific tool in a structured way instead of me copy-pasting context back and forth. Practically, that means an agent can query a database, read a file, or call an API through a defined interface, and I can see exactly what it asked for and what it got back. That visibility matters more than people give it credit for. When something goes wrong, I want to be able to read the tool call, not guess what the model “decided” to do based on a black box.

The honest caveat here: wiring up MCP tools takes real setup work, and a badly scoped tool is worse than no tool, because now the agent has a large permission surface and an unclear boundary. I’ve had to walk back access I gave too liberally more than once. Start narrow. Expand only when you’ve watched the tool behave correctly under normal conditions for a while.

Local vs cloud, and why it’s not a religious choice

I render video locally because I’m doing it constantly and the recurring cost of cloud compute for that workload adds up in a way that local hardware, paid for once, doesn’t. That’s a workload-specific decision, not a philosophy. For other things, like the actual servers running customer infrastructure, cloud or a hosted VPS makes more sense because I need uptime, redundancy, and remote access that a machine sitting in my house can’t reliably give me.

The mistake I see a lot of people make is picking a side, local or cloud, and forcing every workload onto it. Local AI models are genuinely useful for tasks where latency, privacy, or repetition make the local hardware cost worth it. Cloud AI is better when you need a capability your local hardware can’t run well, or when the workload is bursty enough that owning hardware for it would sit idle most of the time. I use both, on different parts of the stack, because they solve different problems.

What actually breaks

Servers going down isn’t rare. Devices drop, routes flap, brick failures happen, disks fill up. The reason this doesn’t take down the whole business is the same reason the servers are split in the first place: each server’s failure is a contained, known-shape problem. I have monitoring that pages me when something specific goes wrong, not a generic “something is wrong somewhere” alert that forces me to investigate from scratch every time.

The monitoring itself is simple: scripts that check a specific condition on a specific service and notify me if it’s off. No AI in that loop, because a deterministic check that fires reliably beats a probabilistic one for infrastructure health. I use AI to summarize or triage after something fires, not to decide whether it should fire.

The actual workload split

Rough shape of a day: the laptop is where I write, review agent output, approve or reject what gets published, and do anything that needs a human decision. The servers run the content pipeline, the customer-facing services, backups, and the monitoring that watches all of it. Agents sit between those two halves, doing bounded work: drafting, tagging, flagging, occasionally executing a predefined fix.

This isn’t a “future of work” story. It’s closer to what a small ops team would do if I had one, except the repetitive parts are handled by scripts and scoped agents instead of a second or third hire for tasks that don’t need a person’s judgment. The parts that do need judgment, I still do.

What I’d tell someone setting this up

Don’t start with six servers. Start with the laptop and one server, and split further only when you can point to a specific reason: a workload that needs isolation, a service that needs uptime the laptop can’t give it, a failure you’ve already had that a split would have contained. Infrastructure that grows in response to actual problems stays legible. Infrastructure built in anticipation of problems you haven’t hit yet usually turns into complexity you maintain for no reason.

Same goes for agents. Don’t wire one up to a broad set of tools because it’s possible. Wire up one narrow task, watch it run for a while, and only expand its scope once you trust the boundary you set. The setup I run today looks the way it does because it grew one contained problem at a time, not because I planned it upfront on a whiteboard.

If you want to see how this plays out in practice, on the content and automation side specifically, browse more on the home page.

Get new guides and videos first — join the Telegram channel.