Why We Don't Run OpenClaw on Laptops (And What We Use Instead)

The Mac Mini Problem

Most OpenClaw deployments start on someone's personal machine. A developer's laptop. A Mac mini in the corner of the office. This is fine for testing. It is a serious problem the moment a real client depends on that agent being available.

There are four failure modes in laptop and personal machine deployments that cannot be engineered around. The machine goes to sleep. It gets OS updates that require reboots. It sits behind a home or office network that is not designed for production services. And when the person who owns it leaves the company, the agent — along with its credentials and configuration — goes with them.

None of these problems are fixable by being more careful. They are structural properties of personal hardware, and they will eventually cost you.

What Actually Breaks

Availability. A laptop that sleeps at 10 PM is an agent that does not respond at 10 PM. If your client is in a different time zone, or if their customers contact them outside business hours, a sleeping laptop is a production outage. There is no alerting. No self-healing. The agent is simply gone until someone opens the lid.

Reliability. Operating system updates require reboots. Reboots kill running processes. Without a proper service manager and health checking, the agent does not restart cleanly after a reboot — and nobody finds out until the next time something should have happened and didn't.

Security. Credentials stored on a developer's personal machine travel with that machine. They show up in backups. They are present when the machine is used for personal tasks. When the developer leaves the company, the only way to fully revoke access is to rotate every credential they had — assuming you know what they had.

Auditability. When a client asks "what did your agent do last Tuesday at 2 PM," a laptop deployment has no answer. No logs. No audit trail. Nothing.

The Hidden Cost Nobody Calculates

The most insidious problem with personal machine deployments is not availability or security — it is the cost of the first serious incident.

When a client's agent goes offline because a developer's laptop battery died, someone has to explain what happened and why. When a client asks for logs from a specific interaction and there are none, someone has to explain that too. When a developer leaves the company and the only person who knew the admin password is gone, someone has to spend a day reconstructing the deployment.

These costs — in client trust, in engineering time, in stress — never get counted against the personal machine setup. They get absorbed. They don't show up in any cost comparison. But they are real, and they happen at the worst possible time.

A $50/month AWS infrastructure spend is cheap compared to the first client incident on a laptop deployment.

What a Production Cloud Deployment Looks Like

Every production agent should run on AWS EC2, in a private subnet, inside an Auto Scaling Group. Here is what that actually means in practice.

Private subnet. The instance has no public IP address. There is no inbound firewall rule that accepts connections from the internet. No port is exposed. An attacker scanning the internet cannot find the instance, because it does not exist on the internet. This is not security theater — it eliminates an entire category of attack surface that a publicly addressed machine carries permanently.

Auto Scaling Group with health checks. The ASG monitors whether the instance is healthy. If the instance stops passing health checks — because the gateway crashed, because the machine ran out of memory, because anything went wrong — the ASG marks it unhealthy and replaces it automatically. The agent restarts without human intervention. Teams are typically notified of the failure and the replacement before they would have noticed from the outside.

Lifecycle hooks. When a new instance starts, it does not begin receiving traffic until the gateway is fully healthy. This prevents situations where a partially initialized instance starts handling requests before it is ready. The lifecycle hook holds the instance in a pending state, the startup script runs, the gateway comes up and passes its health check, and only then does the instance join the load balancer. New deployments go out cleanly.

Zero-downtime rolling deploys. When an update is pushed, new instances start and become healthy before old instances are terminated. There is no gap in service. The agent does not go offline during deployments. A laptop cannot do this — there is one machine, and updating it requires stopping the agent.

Encrypted EBS volumes. All storage on every instance should be encrypted at rest. No exceptions.

How the Auto Scaling Group Is Configured

The ASG configuration is worth understanding in detail because it is what makes self-healing possible.

Configure a minimum of one instance and a maximum based on expected load. The health check should not be an EC2 health check (which only detects if the instance is reachable) — it should be an ELB health check that pings the gateway's /health endpoint. If the gateway process dies but the instance is still up, the EC2 health check passes and nothing happens. The ELB health check fails, the instance is marked unhealthy, and the ASG replaces it.

Lifecycle hooks should be configured for both launch and termination. On launch, the hook holds the instance in InService:Pending state until the startup script signals that the gateway is healthy. On termination, the hook drains active connections before the instance exits. This prevents abrupt connection termination during rolling deploys.

CloudWatch alarms should watch the ASG's GroupInServiceInstances metric. If it drops to zero — meaning all instances have failed — an alarm fires immediately to the on-call channel. This is the scenario where automated recovery is also happening, but human awareness in parallel is essential.

Credentials Never Touch a Developer's Machine

On a laptop deployment, the credentials for the agent typically live in a config file. That config file is on the developer's machine. It gets committed to git — accidentally, or because someone thought it was fine. It gets backed up. It travels.

In a proper cloud deployment, credentials live in AWS Secrets Manager. The EC2 instance has an IAM role that is authorized to read one specific secret — its own. At boot time, the instance fetches the config from Secrets Manager and injects it into the running process. The credentials never touch disk as plaintext. They never exist on a developer's machine. If a developer leaves the company, there is nothing to revoke on their machine because the credentials were never there.

Each IAM role should be scoped to read exactly one secret. A compromise of one instance's IAM role does not expose credentials for other clients. The blast radius is bounded by design.

IMDSv2 should be enforced on every instance — http_tokens = required in the launch template. This blocks the class of server-side request forgery attacks where a compromised agent queries the EC2 instance metadata endpoint to extract the IAM role credentials. It is a one-line configuration that closes a real attack vector.

Soul Documents on EFS, Not Local Disk

Soul documents — the behavioral configuration files that define how the agent acts — belong on AWS EFS, not on the instance's local disk. The EFS volume should be mounted read-only on every instance.

This means soul documents are consistent across every instance in the Auto Scaling Group without any synchronization step. It also means soul documents survive instance replacement. When the ASG replaces a failed instance with a new one, the new instance mounts the same EFS volume and reads the same soul documents. Nothing is lost.

The read-only mount is a security control in addition to a consistency mechanism. A prompt-injected agent cannot modify its own soul documents because the filesystem rejects the write at the OS level. This is covered in more detail in the post on read-only soul documents.

Admin Access Without Exposing Anything

The instance is in a private subnet with no inbound rules. How do you manage it? Tailscale.

Tailscale creates an encrypted peer-to-peer mesh network. SSH access to the instance from an authorized machine is possible without exposing port 22 to the internet. No bastion host. No VPN concentrator to maintain. No inbound firewall rules. The instance is invisible to everything except the machines that have been explicitly authorized.

This is not just convenient — it eliminates an entire class of attack surface. An instance that cannot receive inbound connections from the internet cannot be port-scanned, brute-forced, or hit with known-exploit attempts from automated scanners.

Tailscale uses WireGuard as its underlying transport. Authentication is through Tailscale's identity provider. Access for a specific machine or user can be revoked in Tailscale's admin console, and the revocation takes effect immediately without any changes to the instance.

When Something Goes Wrong, You Know

On a laptop deployment, you find out the agent is down when a client calls to ask why it hasn't responded.

In a cloud deployment, CloudWatch captures everything the agent does. Gateway logs. Session logs. Health check results. When something goes wrong, an alert fires before the client notices. The instance marks itself unhealthy, the ASG replaces it, and the alert tells you what happened.

Every agent session should be logged to CloudWatch with retention configured to meet the client's requirements. When a client asks what happened during a specific interaction, the exact session log is there. The agent's inputs, its reasoning, its outputs — all of it. This is the audit trail that a laptop deployment can never provide.

Health alerts should route through a dedicated monitoring Lambda function. The monitoring system should have its own isolated Secrets Manager secret — the alerting infrastructure cannot access the main config secret. This means even if the monitoring system itself were compromised, it could not reach the client configuration.

The Cost

A t4g.small instance on AWS runs under $15 per month. The EFS mount for soul documents adds a few dollars. CloudWatch logging, Secrets Manager, the auto-scaling configuration — the total infrastructure cost for a single-client deployment is somewhere between $25 and $50 per month depending on usage.

For that cost, you get uptime when the developer closes their laptop, credentials that never touch personal hardware, an audit trail for every action the agent takes, and automatic recovery when something breaks. The reliability and security are worth far more than the cost of the alternative.

The comparison is not $50/month vs. $0/month. It is $50/month vs. the cost of the first client incident on infrastructure that was not designed for production.

Associates AI builds and manages this exact infrastructure for clients — EC2 in private subnets, Auto Scaling Groups with proper health checks, Tailscale for admin access, CloudWatch for full observability — so teams can deploy OpenClaw with production-grade reliability from day one. If you're evaluating OpenClaw for your business, book a call.

FAQ

Q: What cloud provider should I use? A: AWS is the natural choice for OpenClaw deployments given the depth of managed services available — EC2 for compute, EFS for shared filesystem mounts (soul documents), Secrets Manager for credentials, CloudWatch for logging and alerting. The specific services are AWS-specific, but the principles apply to GCP and Azure as well.

Q: How do you access the OpenClaw instance for management? A: Tailscale. The instance has no public IP and no inbound firewall rules. Tailscale provides encrypted peer-to-peer connectivity between authorized machines and the instance without exposing anything to the internet. This is cleaner and more secure than maintaining a bastion host or opening SSH to the world. Revoking access for a specific team member is a single operation in the Tailscale admin console.

Q: How much does a production OpenClaw cloud deployment cost? A: The baseline infrastructure — EC2 instance, EFS mount, Secrets Manager, CloudWatch — runs between $25 and $50 per month for a typical single-client deployment. This does not include API costs for the underlying AI models, which vary based on usage volume. A t4g.small instance alone is under $15/month at current on-demand pricing. The EFS mount and CloudWatch logging are the next-largest cost items, both in the single-digit dollar range for typical usage.

Q: What happens if the instance goes down? A: The Auto Scaling Group detects the failed health check and replaces the instance automatically. The lifecycle hook holds the new instance until the gateway is healthy before it starts handling traffic. Depending on the failure mode, recovery typically takes two to five minutes. CloudWatch alerts notify the team when this happens, so the root cause can be investigated even though the system has already recovered. The client typically does not notice the interruption.

Q: Can we run multiple clients on one instance to save money? A: One client per instance is the right approach — this is a security and isolation decision, not primarily a cost one. If one client's agent is compromised, the blast radius does not extend to other clients. If one client needs updated soul documents or a configuration change, the deployment does not affect other clients. The per-client infrastructure cost is low enough that this isolation is worth it.

Q: What does the deployment process look like? A: A rolling deploy triggered by pushing to the deployment branch in the git repository. The CI pipeline builds a new AMI with the updated configuration, the Auto Scaling Group launches new instances using that AMI, and lifecycle hooks verify gateway health before marking instances ready. Old instances are terminated only after new instances are healthy. A full rolling deploy takes about ten minutes from push to completion. The agent is available throughout.