This is a submission for the OpenClaw Writing Challenge

Just Lightsail, IAM, and Route 53:

How My Agent Built My Site For Me In Minutes

AWS has over 200 services.
I used three.

No VPCs.
No EC2 security groups.
No CloudFormation templates.
No Lambda functions.
No S3 bucket policies.

Just Lightsail to run things, IAM to grant permissions, and Route 53 for DNS.

That's the entire infrastructure for an AI Agent that builds WordPress Multisite installations and writes SEO blog content from scratch, in under 30 minutes, for people who've never touched a server.

This is the story of how I built it with OpenClaw, and why staying in the shallow end of AWS was the whole point.

The Problem I Wanted To Solve

The monotony of manual labor...
Setting up WordPress Multisite manually is a multi-hour ordeal even for developers. You SSH into a server, edit wp-config.php by hand, hope you didn't miss a semicolon, configure Apache, set up a static IP, mess with DNS records, install SSL, restart services, Google the error, and try again.

For a beginner? It's a wall.
Most people give up somewhere between "what's SSH?" and "Error establishing database connection."

I didn't want to write another tutorial that people would bookmark and never finish. I wanted to build an AI agent that does the whole thing for you step by step, in plain language, while explaining everything along the way. And I wanted it to run entirely in the cloud so beginners don't need to install anything on their computer.

Why Lightsail (and only Lightsail)

Most AWS tutorials assume you're comfortable with the full ecosystem. They'll casually tell you to "create a VPC with two subnets" or "configure a security group with the following inbound rules" as if that's a normal thing beginners do on a Sunday afternoon...even though it's quite simple, it's just too many services and a confusing dashboard.

Lightsail exists specifically to avoid that.
It's AWS for people who don't want to think about AWS:

• Fixed monthly pricing.
• Instances that just work.
• Networking that's already configured.
• A console that doesn't require a PhD to navigate.

For this project, Lightsail gave me everything I needed:

1. An OpenClaw Instance: AWS has an official OpenClaw blueprint. Click create, pick the blueprint, and you have a running AI gateway in two minutes.
   No Docker, no environment variables, no dependency hell.

2. A WordPress Instance: same deal. Bitnami WordPress blueprint. Click, wait, done.

3. Static IPs: free while attached to an instance.

4. Firewall Rules: built into the instance management page.
   No security group rabbit holes.

5. Browser-Based SSH: click "Connect using SSH" and you're in.
   No key management, no PuTTY, no terminal setup.

The only other AWS services I touched were IAM (to grant the OpenClaw instance permission to create Lightsail resources and use Bedrock) and Route 53 (for DNS, and only if you want a custom domain).
That's it.
Three services.
The rest of AWS might as well not exist for this project.

What I Built

An OpenClaw agent with two skills:

Skill 1

WordPress Multisite Builder

An 8-phase guided workflow that walks beginners through creating a Lightsail instance, configuring WordPress, enabling multisite, setting up domains, and installing SSL. Uses browser automation to navigate the AWS console and SSH to configure the server.

Skill 2

Blog Content Engine

A 6-phase content generation system that researches what people are searching for in your niche, writes SEO-optimized blog posts, and publishes them directly to your WordPress site via WP-CLI.

The whole thing runs on a Lightsail OpenClaw instance.
No local install.
You chat with the agent from a browser dashboard, Telegram, or WhatsApp, and it builds your website and writes your content.

The Architecture

You (browser / Telegram / WhatsApp)
    │
    ▼
Lightsail OpenClaw Instance (~$12/mo)
    │  Amazon Bedrock → Claude Opus 4.6
    │
    ├── browser tool ──► AWS Lightsail Console + WordPress Admin
    ├── exec tool ─────► SSH + WP-CLI on the WordPress server
    ├── web_search ────► Keyword research + trending topics
    ├── web_fetch ─────► Competitor analysis + content research
    └── file I/O ──────► Progress tracking, content calendar, posts
    │
    ▼
Lightsail WordPress Instance (~$12/mo)
    └── WordPress Multisite with auto-generated content

Two Lightsail instances.
One IAM role.
Optionally Route 53 for DNS.

How I Built It

Step By Step Guide

Step 1: The OpenClaw Instance

I went to the Lightsail console, clicked "Create instance," picked the OpenClaw blueprint under Linux/Unix, selected the 2 GB plan (~$12/month), named it WordPressAgent, and clicked Create.
Two minutes later it was running.

The pairing process was straightforward: click "Connect using SSH" to open a browser terminal, copy the dashboard URL and access token from the welcome message, paste the token into the dashboard, and approve the pairing prompts in the SSH terminal. Dashboard showed "OK."
Connected.

Step 2: Enabling Bedrock

The Lightsail OpenClaw blueprint comes pre-configured to use Amazon Bedrock you just need to grant the permissions. On the instance's "Getting started" tab, there's a "Copy the script" button. I copied it, launched CloudShell, pasted, and ran it. The script creates an IAM role (LightsailRoleFor-i-xxxxx) with Bedrock access.

I tested it by typing "Hello" in the OpenClaw dashboard chat. Got a response. Bedrock was working.

Step 3: The IAM Permission That Made Everything Click

Here's where I hit my first snag. The agent needed to create Lightsail resources (the WordPress instance, static IPs, etc.) but the IAM role only had Bedrock permissions. When I ran aws lightsail get-instances from the SSH terminal, I got:

AccessDeniedException: User is not authorized to perform: lightsail:GetInstances

The fix was simple: I went to the IAM console, found the AmazonLightsailInstance role, clicked "Add permissions" → "Attach policies," searched for AmazonLightsailFullAccess, and attached it.

One policy. That's all it took.
Lightsail is self-contained: instances, networking, DNS, snapshots, key pairs, everything is under one permission set.
No cross-service IAM policies.
No resource-based permissions.
No condition keys.
This is what makes Lightsail great for beginners: the permission model is as simple as the service itself.

Step 4: Escaping The Sandbox

The next issue: OpenClaw told me it was "running in a sandboxed environment" and couldn't execute commands on the host. By default, OpenClaw runs tools inside a Docker container for security. That's smart for untrusted inputs, but it blocks the agent from doing real work.

Three config lines fixed it:

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.ask off
openclaw config set tools.exec.security full
openclaw gateway restart

This tells OpenClaw to run tools directly on the gateway host instead of in the sandbox. For a personal agent that only you control, this is the right tradeoff.

Alternatively, you can give your agent permission to use your browser and run commands during the initial Security setup process.

Step 5: Building The Agent Workspace

OpenClaw agents are defined by markdown files in a workspace directory. No code, no SDK, no compilation.
Just files that tell the agent who it is, how to behave, and what to do.

I created five core files by pasting them directly into the SSH terminal using cat > file << 'ENDOFFILE' blocks.
No git clone.
No file transfers.
No local tools needed.

IDENTITY.md — defines who the agent is:

You are WP Multisite Builder + Content Engine, an AI assistant that helps
complete beginners:

1. Set up WordPress Multisite on Amazon Lightsail
2. Research trending search topics and generate SEO-optimized blog posts
3. Publish content directly to their WordPress sites

SOUL.md — defines the personality and safety rules. This was important because the agent is aimed at beginners:

## Personality
- Warm and encouraging, like a helpful friend who happens to know tech
- Never condescending. If someone doesn't know what SSH means, that's fine
- Celebrate small wins ("Nice, your instance is running!")

## Safety rules
- NEVER proceed without user confirmation on actions that:
  - Create or modify AWS resources (costs money)
  - Change passwords or security settings
  - Install software on their server
  - Modify WordPress configuration
- Always explain what something will cost before creating resources
- Never store or display AWS credentials in chat history

AGENTS.md — the operating instructions and greeting message. When a user first connects, the agent says:

"Hey! I can help you with two things: set up a WordPress website that can run multiple sites all on Amazon Lightsail, or write blog posts based on what people are actually searching for. We can do both, or just one. What sounds good?"

TOOLS.md — a reference for which OpenClaw tools the agent uses: browser for navigating the Lightsail console and WordPress admin, exec for SSH and WP-CLI commands, web_search and web_fetch for keyword research and troubleshooting, and file I/O for saving progress.

Step 6: The WordPress Multisite Skill

This is the core of the project. I created skills/wp-multisite-lightsail/SKILL.md — an 8-phase guided workflow:

Phase 1: Pre-flight Checks. Confirms the user has an AWS account and login ready. If not, walks them through creating one.

Phase 2: Create a Lightsail Instance. The agent opens the Lightsail console using the browser tool, takes a snapshot of the page to identify clickable elements, and walks through instance creation: Linux/Unix platform, WordPress blueprint, $5/month plan. It stops and confirms the cost before clicking "Create instance," then waits for "Running" status.

Phase 3: Get WordPress Credentials. SSHs into the new instance and reads the default Bitnami password. Tells the user to write it down. Verifies WordPress loads in the browser.

Phase 4: Static IP. Creates and attaches a free static IP so the address doesn't change on restart.

Phase 5: Enable Multisite. This is the complex part that usually trips people up. The agent edits wp-config.php via SSH to add WP_ALLOW_MULTISITE, navigates to Tools → Network Setup in wp-admin via the browser, recommends subdirectories for beginners, applies the multisite configuration constants, updates .htaccess, and restarts Apache. It makes a backup of wp-config.php before any edits. But, it will choose the Multisite Instance from the get go, unless it doesn't.

Phase 6: Domain Setup. If the user has a domain, the agent guides them through DNS configuration at their registrar (using web_search to find the right settings page for GoDaddy, Namecheap, Cloudflare, Route53 etc.) and updates WordPress via WP-CLI.

Phase 7: SSL certificate. Runs Bitnami's bncert-tool for free Let's Encrypt SSL.

Phase 8: Wrap-up. Saves a summary with all URLs, login info, monthly costs, and next steps.

The skill also includes error handling for every common failure such database connection errors, SSH failures, SSL issues, missing config entries. The agent searches the web for solutions when it hits something unexpected.

Step 7: The Content Engine Skill

After the site is built, the agent offers to generate blog content. I created skills/blog-content-engine/SKILL.md with 6 phases:

Phase 1: Keyword Research. Asks the user their niche, then fires off multiple web_search queries to find trending questions, "People Also Ask" data, long-tail keywords, and competitor content. Compiles 10-15 keyword opportunities.

Phase 2: Content Planning. Creates outlines with titles, meta descriptions, target keywords, H2 structure, and FAQ sections.

Phase 3: Writing. Generates 1,200-2,000 word SEO-optimized posts with proper heading structure, keyword placement, short paragraphs, and 8th-grade reading level.

Phase 4: Publishing. Pushes to WordPress via WP-CLI (or browser fallback). For multisite, asks which subsite to target. Never auto-publishes without explicit approval.

Phase 5: Batch Generation. Handles multiple posts with a content calendar.

Phase 6: Ongoing Suggestions. Offers fresh trending topics each time the user comes back.

Step 8: Connecting Telegram and WhatsApp

After everything was working in the dashboard, I connected messaging channels so I could manage the site from my phone.

Telegram took about three minutes: create a bot via @botfather on Telegram, copy the bot token, run openclaw channels add in SSH, select Telegram, paste the token. Then configure the allowlist with my numeric Telegram user ID (get it from @userinfobot) and approve the pairing.

WhatsApp was even simpler: run openclaw channels add, select WhatsApp, scan the QR code with my phone's Linked Devices feature. Done.

Now I can message my bot on Telegram or WhatsApp and say "write a blog post about beginner gardening tips" and it researches, writes, and publishes all from my phone.

The Moment It All Worked

I opened the OpenClaw dashboard, typed "Help me set up WordPress Multisite," and the agent greeted me. It asked if I had an AWS account. It opened the Lightsail console in its browser.

It walked me through creating the instance, explaining every step. It confirmed the cost before clicking Create. It waited for the instance to boot. It SSHed in, grabbed the credentials, set up the static IP, edited the config files, enabled multisite, and verified everything worked.

Under 30 minutes. The whole thing. An AI agent, running on Lightsail, building a WordPress Multisite on another Lightsail instance, using browser automation and SSH. And I never left the Lightsail console (plus one quick trip to IAM to attach a policy).

What OpenClaw Gets Right

Skills Are Just Markdown. Each skill is a SKILL.md file with YAML frontmatter and instructions. No SDK, no compilation, no deployment pipeline. Write markdown, drop it in the workspace, restart the gateway. The agent picks it up on the next session. This is the right abstraction for teaching an agent how to do something complex.

Browser Automation Is Built In. Most AI agents are limited to APIs and CLIs. OpenClaw's browser tool controls an isolated Chromium instance: the agent can navigate web consoles, click buttons, fill forms, and take screenshots. That's a massive unlock for automating things that don't have an API, like the Lightsail console's instance creation wizard.

The Lightsail Blueprint Is A Cheat Code. Going from zero to a running AI gateway in two minutes, with Bedrock pre-configured, HTTPS auto-managed, and daily token rotation...that's the kind of developer experience that makes you want to build things.

Multi-Channel Is Trivial. Dashboard, Telegram, WhatsApp all connected in minutes. The agent doesn't care where the message comes from. Same skills, same personality, same workflow.

The "Confirm Before Acting" Pattern Works. My agent never creates resources or spends money without asking first. This isn't just good UX. It's the difference between a tool beginners trust and one they're afraid of.

What I Learned About Staying In The Shallow End

The biggest lesson: you don't need the deep ocean of AWS to build real things. The instinct is always to reach for EC2, VPCs, security groups, load balancers, auto-scaling groups. But for a personal AI agent running a WordPress site?

Lightsail does everything, and it does it without the cognitive overhead.

The permission model tells the story. I needed exactly two IAM policies: one for Bedrock (auto-created by the setup script) and AmazonLightsailFullAccess (one click in the IAM console). Compare that to the typical EC2 setup where you're writing JSON policy documents with resource ARNs and condition keys.

Route 53 was optional. Only needed if you want a custom domain. And even then, the agent handles the DNS configuration by guiding the user through their existing registrar.

Three services. That's the whole stack. And it's not a toy.
It's a production-capable AI agent that builds infrastructure, manages servers, and generates content.

Try It Yourself

Everything is reproducible. You need:

1. An AWS account
2. A Lightsail OpenClaw instance (2 GB plan, ~$12/month)
3. AmazonLightsailFullAccess attached to the instance's IAM role
4. The workspace files pasted into ~/.openclaw/workspace/ via SSH

The full deployment takes about 15 minutes. Here's the condensed version:

# After creating the OpenClaw instance, pairing, and enabling Bedrock:

# Create skill directories
mkdir -p ~/.openclaw/workspace/skills/wp-multisite-lightsail
mkdir -p ~/.openclaw/workspace/skills/blog-content-engine

# Paste each workspace file (IDENTITY.md, SOUL.md, AGENTS.md, TOOLS.md,
# and both SKILL.md files) using cat > file << 'ENDOFFILE' blocks

# Configure tool permissions
openclaw config set tools.exec.host gateway
openclaw config set tools.exec.ask off
openclaw config set tools.exec.security full
openclaw gateway restart

# Open the dashboard and type: "Help me set up WordPress Multisite"

No GitHub repo needed.
No local install.
No dependencies.
Just an SSH terminal and some copy-paste.

The cost breakdown

About $25/month for the infrastructure, plus whatever Bedrock charges for the AI conversations. For a self-hosted AI agent that builds and manages WordPress sites and writes your blog content, that's a pretty good deal.

Where To Next?

Well, the foundation is solid. Some things I'm thinking about, dependent on your use case:

• More Skills: WooCommerce setup, backup automation, security hardening, performance optimization
• Multi-tenant: let the agent manage multiple WordPress Multisites for different clients if you're the entrepreneaurial sort.
• Scheduled Content: use OpenClaw's cron tool to auto-research and draft posts on a schedule
• Analytics Integration: pull Google Analytics data to inform content strategy

The possibilities are endless!
But honestly, the most exciting part is how accessible this is.

A beginner with an AWS account can have a working WordPress Multisite with AI-generated content in under an hour.
No terminal on their laptop.
No config files on their desktop.
No "install these 7 prerequisites first."

Just Lightsail, IAM, and Route 53.
The shallow end of AWS.
And it's plenty deep enough.

Built with OpenClaw on Amazon Lightsail. Powered by Amazon Bedrock (Claude Opus 4.6). Three AWS services. Zero Local Installs.