Deploy a Personal AI Agent to the Cloud in 10 Minutes

From Nothing to a Running Agent

This guide shows how to deploy a personal AI agent to the cloud in roughly ten minutes, starting from an empty terminal. By the end you will have a running agent, its API keys stored as secrets rather than plaintext, and a restart policy so it survives a reboot. We will cover both a quick Docker path on a plain server and a managed one-command path, so you can pick the one that matches how much infrastructure you want to own.

Ten minutes is an honest estimate for getting an agent live, not for making it production-grade. We will be clear about what the fast path leaves out at the end. If you want more depth on the two hosting models, the VPS walkthrough covers the self-managed route and running AI agents on Kubernetes covers the cluster route. The first-agent primer is the gentlest place to begin if this is all new.

What You Need Before the Clock Starts

Three things, none of which take long to gather:

1. An agent to run. Pick a template rather than building from scratch. Sokko ships four: OpenClaw (a gateway assistant across chat channels), Hermes (a self-improving research agent), Paperclip (a multi-agent orchestrator), and OpenSRE (an SRE assistant). Any of them works for this tutorial.

2. A model API key. Most agents call a hosted model, so you will need a key from your provider. Keep it in your clipboard, not in a file you might commit.

3. A place to run it. Either a small cloud server you can SSH into, or a managed platform account. Both paths are shown below.

Have those ready and the ten minutes is spent on deployment, not shopping.

Choosing which template fits your task

Picking the wrong agent for the job is the most common way people waste their first deploy, so match the template to what you actually want done. OpenClaw is a gateway assistant: one persistent assistant you reach across chat channels like WhatsApp, Telegram, Slack, and Discord, with a large library of community skills and tool-use. Hermes is the self-improving research agent: it keeps persistent memory and a skills library that sharpens after each task, so it crawls, reads, and summarizes well and is a good first choice for this tutorial. Paperclip is a multi-agent orchestrator: an agent org chart with roles, goals, and budgets, which suits running a whole team of agents rather than a single task. OpenSRE is the operations assistant, meant to sit near your infrastructure and help with incident triage and routine checks.

If you are unsure, start with Hermes. It exercises the full deploy flow (keys, workspace, restarts) without demanding a large server, so you learn the mechanics before you commit to a heavier agent. You can always redeploy a different template once the workflow is familiar.

How to Deploy a Personal AI Agent in Three Steps

The whole flow, whichever host you choose, is three moves: give the agent its keys, start it, and make it durable. Here is the fast Docker version on a server you already have SSH access to.

Step 1: Provide API keys as environment secrets

Never bake a key into an image or paste it into a command that lands in your shell history. Put it in a file with tight permissions and load it at runtime:

# On the server, store the key outside the container
sudo mkdir -p /etc/agent
printf 'ANTHROPIC_API_KEY=sk-ant-your-real-key\n' | sudo tee /etc/agent/agent.env
sudo chmod 600 /etc/agent/agent.env

# On the server, store the key outside the container
sudo mkdir -p /etc/agent
printf 'ANTHROPIC_API_KEY=sk-ant-your-real-key\n' | sudo tee /etc/agent/agent.env
sudo chmod 600 /etc/agent/agent.env

The chmod 600 means only the owner can read the file. That single line separates a private key from one that every user on the box can cat.

Step 2: Deploy the agent

Pull the template image and start it, mounting a host directory so the agent's working files persist:

# Install Docker if it is not already present
curl -fsSL https://get.docker.com | sh

# Create a durable workspace on the host
sudo mkdir -p /srv/agent/workspace

# Start the agent
docker run -d --name agent \
  --env-file /etc/agent/agent.env \
  -v /srv/agent/workspace:/workspace \
  --restart unless-stopped \
  registry.example.com/hermes:latest

# Install Docker if it is not already present
curl -fsSL https://get.docker.com | sh

# Create a durable workspace on the host
sudo mkdir -p /srv/agent/workspace

# Start the agent
docker run -d --name agent \
  --env-file /etc/agent/agent.env \
  -v /srv/agent/workspace:/workspace \
  --restart unless-stopped \
  registry.example.com/hermes:latest

The --restart unless-stopped flag tells Docker to bring the container back after a crash or a host reboot, and the -v mount keeps /workspace on the host disk so a restart does not erase the agent's memory of its work.

Step 3: Verify it is running and keep it alive

Confirm the container is up and watch its logs:

docker ps --filter name=agent
docker logs -f agent

docker ps --filter name=agent
docker logs -f agent

If you see the agent's startup banner and no crash loop, it is live. For a belt-and-suspenders restart guarantee beyond Docker's own policy, wrap it in a systemd unit as shown in the VPS guide; that survives cases where the Docker daemon itself is restarted.

When the first deploy does not come up

Two failures account for most bad first deploys, and both are quick to diagnose. The first is a crash loop, where docker ps shows the container restarting every few seconds. Run docker logs agent and read the last lines: the usual cause is an authentication error because the API key is wrong, expired, or the environment variable name does not match what the image expects. Fix the value in /etc/agent/agent.env, then run docker rm -f agent and start it again so it picks up the new file.

The second is a container that starts but does nothing, which almost always means a missing environment variable other than the key, such as a model name or an endpoint the template needs. The image's documentation lists its required variables; add them to the same env file and restart. Checking logs first, before changing anything, saves you from guessing, because the agent usually prints exactly what it could not find.

Confirm it actually works, not just that it runs

A container showing as up is not proof the agent can do its job. The real test is a task. Send the agent a small request through whatever interface the template exposes (an HTTP endpoint, a CLI, or its chat interface) and watch it complete a full round trip: read the input, call the model, and return a result. For a research agent like Hermes, ask it to summarize a single short page. For a coding agent, ask it to describe a file in a repository you have mounted. If that round trip succeeds, the keys are valid, the network path to the model works, and the workspace is writable, which are the three things most likely to be broken on a fresh deploy.

Do this before you walk away. It takes under a minute and it is the difference between believing the agent is live and knowing it is. A deploy that passes docker ps but fails its first real task is the most frustrating kind, because it looks healthy from the outside while doing nothing useful.

The One-Command Managed Path

The Docker route above is real and it works, but you just took on a server to maintain. The managed alternative collapses all three steps into one. On Sokko you pick a runtime, add your model key, and create the instance from the dashboard in a couple of clicks. If you prefer the terminal, the same thing is one command:

sokko instances create --runtime hermes --name research-agent \
  --byok --provider anthropic --api-key sk-ant-...

sokko instances create --runtime hermes --name research-agent \
  --byok --provider anthropic --api-key sk-ant-...

Either way, Sokko provisions the agent on secure, always-on infrastructure we run for you, keeps your model key in secure storage so it never lives in your code, runs it in its own private space walled off from everyone else's, and gives you a URL. Your agent's files and memory are saved automatically, so they survive restarts. There is no server for you to patch, no systemd unit to write, and no firewall to harden. Checking on it is a click in the dashboard, or a single list command:

sokko instances ls

sokko instances ls

The honest tradeoff between the two paths is ownership, not capability. The Docker path costs a few dollars a month and hands you the operating system to maintain. The managed path costs more per month and hands you back the time you would have spent on patching, monitoring, and restarts. For a personal agent you plan to actually rely on, that is usually the better trade.

Comparing the Two Paths

Both get you a running personal agent. They differ in who does the upkeep afterward.

What "10 Minutes" Leaves Out

Getting an agent running in ten minutes is real. Getting it production-ready is not a ten-minute job, and it would be dishonest to imply otherwise. Here is what the fast path does not include.

Monitoring is the first gap. A running container is not a healthy one. You need something watching CPU, memory, and disk, plus an alert when the agent wedges in a loop or the disk fills. Docker's restart policy handles a clean crash, but not a silent hang where the process is up and doing nothing useful.

Updates are the second. The image you pulled will get security fixes and feature releases. On the Docker path you are responsible for pulling the new tag, restarting cleanly, and making sure the in-flight task is not lost mid-write. Skipping updates is how a fresh deploy becomes a stale, vulnerable one over a few months.

Backups are the third. The /workspace volume accumulates the agent's real work. On a single server that directory needs a backup schedule and a restore you have actually tested, because a corrupted volume or a failed host otherwise means starting over. This is exactly the kind of durable-state handling that pushes larger setups toward the patterns in running AI agents on Kubernetes.

None of these block you from deploying today. They are the difference between a demo and something you trust with real tasks, and they are worth planning for the day after your ten minutes are up.

Next Steps

You now have two working ways to deploy a personal AI agent: a Docker plus systemd path on a cheap VPS, and a one-command managed path on Sokko where persistence, secrets, and network isolation come wired in. Start with whichever matches your appetite for operations. If you are experimenting, the VPS route teaches you the moving parts and the official Docker documentation is a solid reference. If the agent is going to matter, the managed one-command deploy with a persistent workspace that survives restarts saves you the maintenance that the ten-minute quickstart quietly skips. Either way, the hard part was never the first ten minutes.