Deploy an AI Agent to the Cloud: A Safe First Release

There are many ways to deploy an AI agent, and most are more complicated than a first release needs. This lesson uses one small cloud server running one container. That setup suits your SQLite design, keeps costs predictable and is easy to understand. The ideas apply on any cloud provider.

---

💡 Choose Where to Deploy an AI Agent

Option	Good for	Watch out for
One virtual server	This first release	You maintain the server
Managed container service	Less server work	Long jobs and storage limits
Kubernetes	Many services and teams	Much more to learn and run

Serverless platforms often limit run time and may lose local files, so they fit this worker poorly. The agent’s runs are long, and they need a browser and a persistent disk.

---

🔍 Plan the Server

Browsers need plenty of memory. Start with about 2 CPUs and 4 GB of RAM, then adjust after you have measured real runs.

Need	Our answer
Persistent data	Named Docker volumes
Private access	Bind to 127.0.0.1 behind a VPN or proxy
HTTPS	A reverse proxy in front
Secrets	A protected file outside the image
Updates	A new image version for each release

---

🧩 Define the Service

Create compose.yaml.

services:
  qa-agent:
    image: ghcr.io/your-org/qa-agent:${RELEASE:?Set RELEASE to an image version}
    restart: unless-stopped
    init: true
    env_file: /etc/qa-agent/agent.env
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - agent-data:/app/data
      - agent-artifacts:/app/artifacts
      - agent-reports:/app/reports
    security_opt:
      - no-new-privileges:true
    mem_limit: 4g
    cpus: 2
    shm_size: 1gb

volumes:
  agent-data:
  agent-artifacts:
  agent-reports:

Setting	Why
RELEASE is required	You always state which version runs
127.0.0.1:8080	Nothing is exposed directly to the internet
Volumes	Data survives when the container is replaced
no-new-privileges	The process cannot gain extra rights
mem_limit and cpus	A browser cannot starve the whole server
shm_size	Chromium needs shared memory

---

🛠️ Store Secrets on the Server

Create /etc/qa-agent/agent.env on the server, and let only root read it.

sudo mkdir -p /etc/qa-agent
sudo touch /etc/qa-agent/agent.env
sudo chmod 600 /etc/qa-agent/agent.env

Add your settings to that file, after reading AI Agent Access Control. Use AUTH_MODE=token, and never local-dev.

---

📌 Keep It Private

Run the service on a private network, or behind a VPN, whenever you can. If it must be reachable from outside, place a reverse proxy in front to provide HTTPS. Only your proxy and your VPN should be able to reach port 8080.

---

🔑 Deploy It

export RELEASE=your-image-version
docker compose up -d
docker compose ps
curl http://127.0.0.1:8080/readyz

---

💡 Point It at Your Test Environment

The image starts the local demo so that you can prove the deployment first. Only use a real test environment once you are authorised. Then make these changes:

1. Set BASE_URL to your approved test environment.
2. Remove the webServer block from playwright.config.ts.
3. Change the Dockerfile’s last line so that it starts only the service.
4. Replace 'demo' in the environments list with your environment’s name.

---

🔍 Roll Back

export RELEASE=previous-image-version
docker compose up -d

Practise this before you need it. Database changes need extra care, so make them backward compatible, as you will see in Prompt Versioning and Evaluation Gates.

---

🌍 Real-Life Example: The Disk That Vanished

A tester deploys to a container platform with temporary storage. The agent works well until a routine restart wipes its database and every report. A named volume, or the right kind of persistent disk, would have kept them.

---

🧪 Try It Yourself

1. Compare the options above for your team.
2. Write down your server’s size and region.
3. Draw your network, including what can reach what.
4. If you have a cloud account, deploy the demo.
5. Practise a rollback.

---

📋 Ready-to-Copy Prompt

You are a cloud engineer reviewing a first deployment of a QA agent service.

Plan:
[describe the hosting, network and storage with no secrets]

Check public exposure, persistence, outbound network limits, secrets,
updates and rollback. Suggest the cheapest setup that is still safe.

Tell me to confirm current details in my cloud provider's documentation.

---

⚠️ Common Mistakes

• Starting with Kubernetes for one small service
• Exposing the service directly to the internet
• Using temporary storage for the database
• Deploying without a rollback plan
• Allowing unrestricted outbound network access

---

🎯 Key Takeaways

• A small server is enough for a first release.
• Data must live on persistent storage.
• Keep the service private, and limit outbound traffic.
• Practise your rollback before you need it.

---

🎤 Interview Questions

1. How would you deploy a browser-based AI agent?

Model answer: I would run a pinned container on a small server with persistent storage, private network access and secrets provided at runtime.

2. Why might serverless be a poor fit?

Model answer: Runs can be long, browsers need significant resources and local files may not persist. A worker on a server or container service suits it better.

3. How do you limit damage if the agent misbehaves?

Model answer: I restrict its outbound network access, give it narrow credentials, cap its resources and keep it away from production systems.

4. Why bind to 127.0.0.1 on the server?

Model answer: It keeps the application off the public interface. Access must then pass through a controlled proxy or VPN.

5. How do you roll back a bad deployment?

Model answer: I redeploy the previous pinned image. I keep database changes backward compatible, so the older version can still run.

---

📝 Assignment

Write a deployment plan covering hosting, network, storage, secrets and rollback. If you can, deploy the demo to a small server, then destroy it when you finish so that you are not charged for it.

---

❓ FAQ

Which cloud provider should I use?

Any major provider can run this design. Use the one your company has approved.

Can a team use my service without a VPN?

Only with strong protection, such as HTTPS and proper sign-in. A private network is the safer first choice.

---

🚀 Next Steps

Well done on finishing this lesson. Complete the assignment, then continue with AI Agent Access Control: Secrets, Sign-In, Roles and Network Limits.