DEV Community: Erik Hanchett

5 Things to Do After Installing OpenClaw (Before You Break It)

Erik Hanchett — Mon, 11 May 2026 18:51:25 +0000

I've been running OpenClaw for a while now and I think it's pretty awesome.

If you haven't heard of it, OpenClaw is a self-hosted AI agent that runs on your own hardware: a spare laptop, a Mac Mini, or a VPS. At AWS we have Amazon Lightsail which is a great option for running OpenClaw on a dedicated instance. (Full disclosure: I'm a Developer Advocate for AWS, so I'll be recommending AWS services where relevant. Feel free to use whatever VPS provider you'd like.) It's not a chatbot you open in a browser tab. It's always on. It connects to your messaging apps (Telegram, Discord, WhatsApp), reads your files, runs scheduled tasks, and takes action on your behalf. By default, a heartbeat runs every 30 minutes, it checks for instructions in HEARTBEAT.md and acts proactively. You can customize the interval or disable it entirely, but it's on out of the box.

The whole thing is built around plain-text markdown files. Your agent's personality lives in SOUL.md. Its long-term memory lives in MEMORY.md. Its knowledge of you lives in USER.md. These files are your agent.

The default install is not entirely production ready. Your gateway might be exposed to the public internet. Your default model might be eating your API budget. And without a few key configuration steps, your agent has no idea who you are or what it's allowed to do.

These are the five things that I would do after you install OpenClaw.

FYI: OpenClaw moves fast — updates ship 2–3 times a week and the UI changes regularly. The steps here are based on v2026.5.x. If something looks different in your version, check the official docs first. And as always, be careful giving any agent access to your files, accounts, and messaging apps. Start with read-only tasks and expand permissions as you build trust.

Opening the Dashboard
1. Lock Down Your Gateway
2. Switch to a Cheaper Model
3. Write Your SOUL.md With Boundaries
4. Seed Your Memory Files
5. Back Up Your Workspace and Use /new
Resources

Prerequisites

OpenClaw installed and running
Access to your API provider dashboard (Anthropic, OpenAI, or similar)

Opening the Dashboard

The dashboard runs at http://127.0.0.1:18789 by default. The easiest way to open it with your token already attached is to run this from the terminal on the machine where OpenClaw is installed:

openclaw dashboard

This opens the dashboard in your browser with a clean URL. If it asks for a token, run this to get it:

openclaw config get gateway.auth.token

Then paste it into the dashboard login prompt. See the dashboard docs for more detail.

If you've already logged in before, just go straight to http://127.0.0.1:18789. Your browser should have the session cached.

Steps

1. Lock Down Your Gateway

Good news: the default install gets this right. Bind mode is loopback and auth mode is token out of the box. If you installed via the quick-start script, verify this. Some install paths skip token setup during onboarding.

The reason this is still Step 1 is that it's easy to accidentally break, and most people never verify it.

Go to Settings → Infrastructure and confirm these two settings.

Gateway Bind Mode: should be loopback for a local setup. This controls who can reach the port at all — loopback means only 127.0.0.1, so nothing outside the machine can connect regardless of auth settings. lan binds to all network interfaces, which is fine on a home machine where your interfaces are private. On a VPS where the network interface has a public IP, lan puts the port on the internet. That's where the real exposure happens. If you need remote access, use tailnet (Tailscale) rather than lan — it keeps the port off the public internet.

Gateway Auth Mode: should be token. This controls what happens once someone reaches the port. If it's none, anyone who can reach the port connects with no credentials at all. On loopback that's low risk. On a public bind it's a disaster. There are thousands of OpenClaw instances exposed on the public internet right now, most of them are the result of changing bind mode without realizing what that exposes.

While you're here, check two more things:

Insecure Control UI Auth Toggle: may be enabled from your initial setup. Turn it off. When on (allowInsecureAuth: true), it lets localhost Control UI sessions bypass device identity checks in non-secure HTTP contexts, it's a compatibility workaround that shouldn't be left on in normal use. The security audit will flag it if it's enabled.
Control UI Allowed Origins: should list your specific origins (e.g., http://localhost:18789). Never set this to *.

To verify from the command line:

openclaw config get gateway.auth.mode
# should print: token

openclaw config get gateway.bind
# should print: loopback

If either prints something different, fix it in the dashboard before moving on.

Run the security audit. OpenClaw has a built-in security audit command. Run it now:

openclaw security audit

For a more thorough check that includes live probes:

openclaw security audit --deep

If it flags issues, --fix applies the safe defaults automatically:

openclaw security audit --fix

Then tell your agent to keep checking:

Read https://docs.openclaw.ai/gateway/security, run `openclaw security audit --deep`,
and send me a summary of any findings. Then schedule yourself to repeat this twice a day.

Pin your version. OpenClaw ships updates 2–3 times a week and some of them break things. The community built a tracker: isitstable.com/openclaw. Check it before you update, then install the recommended stable release:

openclaw update --tag <stable-version>

This handles the doctor check and gateway restart automatically. If you need to roll back to an older version, the manual fallback is npm i -g openclaw@<version> followed by openclaw doctor and openclaw gateway restart.

When you're ready to update, check the tracker, read the changelog, then update during a quiet period.

2. Switch to a Cheaper Model

Someone in the community went from $47/week to $6/week with two changes. It's one of the most upvoted posts in r/openclaw. That's the whole story for this step.

The default model on most OpenClaw installs is whatever was set during onboarding, often a top-tier model like GPT-5 or Opus. That's great for setup, you want the best reasoning when configuring your workspace files and personality. For daily use it works fine too, but it gets expensive fast. Your agent is checking calendars, drafting short replies, and running heartbeat tasks every 30 minutes. None of that needs frontier-model reasoning, and you're paying frontier-model prices for all of it.

Here's a breakdown of what the community recommends based on your budget and hardware:

If you want the best results and don't want to think about cost, Opus with Sonnet as fallback is the standard recommendation. Just be warned. It's expensive.

The cheapest option: use your ChatGPT Plus subscription. If you're already paying $20/month for ChatGPT Plus, you can connect OpenClaw to it via OpenAI Codex OAuth. That means you're using your existing subscription instead of paying separately per token. OpenAI explicitly supports this for third-party tools like OpenClaw. To set it up:

openclaw onboard --auth-choice openai-codex

Or if you're already past onboarding:

openclaw models auth login --provider openai-codex

This opens an OAuth flow to sign in with your ChatGPT account. Once connected, set your model to openai/gpt-5.5 and OpenClaw automatically uses the Codex subscription runtime. Usage limits apply. Check OpenAI's plan comparison for current details on what Plus vs Pro covers.

Note: Anthropic does allow Claude subscription auth (Claude Pro or Max) via Claude CLI reuse — run openclaw models auth login --provider anthropic --method cli --set-default. For production use, an API key is more reliable.

If you want to keep bills low without going local, Minimax M2.7 via API is worth knowing about. It's not as capable as Opus or Sonnet but it's significantly cheaper and the community rates it as surprisingly good for most daily tasks.

If your machine has 32GB+ RAM, local models become viable and can bring your API costs close to zero for routine work. A common setup: Opus or Sonnet for planning and complex reasoning, then a local model like Qwen Coder (8B parameter, free to run) for the actual code generation. On Apple Silicon (Mac Mini, MacBook Pro) the unified memory means RAM alone is enough for good performance on smaller models. On a PC or Linux box, a dedicated GPU makes a big difference, without one, local models run on CPU and can be slow enough to be frustrating for interactive use.

Where to change it: First, make sure your API key is set. The cleanest way is to add it to ~/.openclaw/.env:

# ~/.openclaw/.env
ANTHROPIC_API_KEY=sk-ant-...
OPENAI_API_KEY=sk-...

OpenClaw picks this up automatically at startup. Make sure this file isn't committed to a public repo, it contains your credentials.

Then go to Settings → AI & Agents → Models tab and edit the Model JSON field directly:

{
  "primary": "anthropic/claude-sonnet-4-5",
  "fallback": "anthropic/claude-haiku-4-5"
}

The fallback kicks in if the primary is rate-limited or unavailable. Hit Save → Apply.

The SOUL.md trick: The second change that made the $47→$6 difference was adding one line to SOUL.md:

Only use a more powerful model when I explicitly ask for deep analysis.

This lets the agent self-route. Routine tasks stay cheap. You ask for "deep analysis" when you actually need it.

Check your costs: Go to Control → Usage in the sidebar. It shows total tokens, cost, and a breakdown by model. Check it daily in your first week until you understand your baseline. Keep an eye on the cache hit rate, a high rate means you're not paying full price for repeated context, since cached tokens cost significantly less than fresh input tokens.

3. Write Your SOUL.md With Boundaries

SOUL.md is the character sheet for your agent. It defines personality, voice, temperament, and what it's allowed to do. Most people fill it in during onboarding with vague answers and never touch it again. That's a mistake.

The file lives in your OpenClaw workspace alongside a handful of other markdown files: AGENTS.md, MEMORY.md, USER.md, IDENTITY.md. Together these plain-text files are your agent. If you ever migrate to new hardware, these files are what you bring with you.

Go to Agent in the sidebar and click the SOUL button, under Files. The default template is already there and it's actually pretty good. What it doesn't have is your specific boundaries. Add these at the bottom:

## Identity
You are [name]. You are a collaborator, not an assistant.
Push back when I'm wrong. Challenge ideas during brainstorms.
When I'm heads-down, keep it crisp.

## Defaults
Only use a more powerful model when I explicitly ask for deep analysis.
For routine tasks, use the cheapest capable model.

## Boundaries
Never delete files without explicit confirmation.
Never send messages on my behalf without showing me the draft first.
Never make purchases or API calls that cost money without asking.
If a task fails twice with the same error, stop and report. Do not retry.

That last section is easy to skip. Without explicit boundaries, your agent will make reasonable-sounding decisions that you didn't actually authorize.

The aggressive note-taker trick: Add this to both SOUL.md and AGENTS.md:

You are an aggressive note-taker. After every significant session,
write key decisions, preferences, and facts into your daily log.

SOUL.md gets it so the behavior is part of the agent's core identity. AGENTS.md gets it so it's enforced as an operating rule. Together they make it stick. Without both, the agent may follow the instruction in some sessions but not others. This is the single biggest thing you can do to prevent memory degradation over time.

4. Seed Your Memory Files

The biggest complaint from people who've been using OpenClaw for a few weeks is that it starts forgetting things. The experience gets less magical and more frustrating as you keep re-explaining context it should already know.

This is a known problem in the community and it's not fully solved. But it's manageable if you set things up right from the start.

Seed MEMORY.md before your first real session. Go to Agent in the sidebar, then click the MEMORY button. On a fresh install it shows as "MISSING". Clicking it opens an empty editor and saving creates the file.

MEMORY.md is for curated, distilled facts the agent needs to remember across every session: standing rules, key decisions, strong preferences. It gets injected into the context window on every turn, so keep it lean. This is not a journal or a log:

# Memory

## Preferences
- Communication style: direct and concise, skip filler phrases
- Response length: brief by default, thorough when I ask for detail
- Don't ask clarifying questions for simple tasks. Just do it.

## Standing Rules
- Always show me a draft before sending anything externally (email, messages, posts)
- Ask before making calendar changes or bookings
- If a task fails twice with the same error, stop and report. Don't keep retrying.
- Never modify config files without telling me what you're changing and why

## Key Context
- Main tools I use: [e.g. VS Code, GitHub, Notion, Slack]
- Current focus: [e.g. shipping a feature, writing content, job search]
- Things I'm working on this month: [1-3 active projects]

Keep MEMORY.md short. If it gets too long, OpenClaw truncates it when injecting into context, which means the stuff at the bottom silently disappears. Detailed notes belong in memory/YYYY-MM-DD.md daily logs, not here.

USER.md is different. Click the USER button on the same page. This is the agent's profile of you as a person: your background, role, working style, what you care about. The agent builds this over time, but seeding it upfront saves weeks of it figuring things out:

# User Profile

## Who I Am
- Name: [your name]
- Role: [what you do, e.g. "frontend engineer at a fintech startup"]
- Location / timezone: [city, UTC offset]
- Working hours: [e.g. 9am–6pm weekdays]

## How I Work
- I prefer [async / real-time] communication
- I get annoyed when: [e.g. things are over-explained, asked obvious questions]
- I work best when: [e.g. given context upfront, shown options not just answers]

## What I'm Trying to Do With OpenClaw
- [e.g. automate my morning briefing, manage email triage, track projects]
- My biggest time sink right now: [what you want help with most]

The short version: USER.md is who you are. MEMORY.md is what the agent must remember. AGENTS.md is the agent's operating procedure: how it behaves, what it does on startup, routing rules. All three get injected into every session, so they all matter.

Enable Dreaming. Go to your OpenClaw dashboard, find the Dreaming tab, and toggle it on. This is a beta feature with two phases: a shallow phase that writes session summaries to DREAMS.md, and a deep phase that promotes the strongest memories into MEMORY.md as permanent long-term storage. If you enable it and don't see things showing up in MEMORY.md right away, that's normal. Only the deep phase promotes to permanent memory, and it runs on its own schedule. Without Dreaming, session logs accumulate but never get distilled into anything the agent reliably recalls.

5. Back Up Your Workspace and Use /new

How sessions actually work. Every message you send in a session gets included in every future API call in that session. After a few hours of chatting, you're sending thousands of tokens of old conversation with every new message. It costs money, and it makes your agent slower and more confused as the context gets cluttered.

OpenClaw handles this in two ways.

Compaction happens automatically when the context window fills up. It summarizes older conversation history into a condensed entry to free up space. You can also trigger it manually with /compact before a long task, or guide what it focuses on:

/compact Focus on the deployment task

/new starts a completely fresh session. Your agent keeps everything: SOUL.md, MEMORY.md, USER.md, all your workspace files. You're just clearing the conversation buffer. Use it when you're switching topics or starting a new task. Many people in the community report meaningful cost savings just from using /new regularly. Most people don't know it exists.

Also learn /btw. It fires off a side question without touching your main session context. Great for quick lookups mid-task without opening a whole new session.

The key rule: anything important needs to be written to files, not just said in chat. Session memory dies on compaction. If you told your agent something three days ago in conversation, it may not remember it. If it's in MEMORY.md, it will.

Back up your workspace files. Your agent's entire state (personality, memory, projects, tools) lives in markdown files in the OpenClaw workspace directory. If something goes wrong (and eventually something will), you want to be able to roll back. Make sure to use a private repo. Just ask your agent:

Help me put my OpenClaw workspace files onto a private GitHub repo
and commit changes automatically after each session.

This takes about ten minutes and has saved people from complete resets when their agent went off the rails or a config change broke something.

Check Control → Usage daily in your first week. The usage panel shows total tokens, cost, and a breakdown by model. You're looking for two things: your baseline daily cost, and your cache hit rate. A high cache hit rate means you're not paying full price for repeated context. That's healthy. If costs are higher than expected, check whether your context profile is set too large under Settings → AI & Agents → Agent Defaults → Bootstrap Max Chars.

After the first week you'll have a sense of what normal looks like. Set a budget alert at 2x your daily baseline so you get notified if something starts running away. A misconfigured heartbeat task or a loop in an automation can burn through tokens fast without any visible output.

Resources

🚀 Try Amazon Lightsail — run OpenClaw on a dedicated VPS
OpenClaw docs
OpenClaw security audit docs
ClawHub skills marketplace
Is it stable? — check before you update
Tina's OpenClaw setup guide — the video that inspired a lot of this post

Conclusion

These five steps take a bit of time to do right. The config changes (gateway, model, SOUL.md) take about 30 minutes. Getting your memory files properly seeded and GitHub backup set up will take a bit longer, but it's worth doing before your first real session.

Let me know in the comments if I missed anything. I'm still learning this thing too.

Build Your Own AI Butler - A Scheduled Agent That Runs Itself!

Erik Hanchett — Wed, 06 May 2026 16:00:47 +0000

I want an AI agent that works for me. I want it to search up the latest news, and I want it to deliver it to me in a daily message. I want to chat with it, and get advice. I want to expand its capabilities in the future. And most importantly I want to control it. Basically, I want Jarvis.

Yes Jarvis, the fictional AI character in the Marvel Cinematic Universe (MCU), serving as Tony Stark's butler. I've never had my own agentic butler, and now that I think about it who wouldn't? 😆 A few years ago I would have told you this would have never happened. But today with the rise of agents the future is here.

Well sort of... we are getting closer than ever though!

To take on this task one of the most obvious routes was to use something like OpenClaw. Except, OpenClaw is too new, and a little too much for what I needed, so like any good engineer I decided to roll my own. OpenClaw is an open-source, autonomous AI agent that runs locally on a your machine or VPS to automate tasks.

Recently Amazon Bedrock AgentCore released its managed harness in preview. You define the agent in a config file and a system prompt, and then deploy it. That was it! From my research it looked very straightforward to get up and running, and it could save me a lot of time in the long run. So I decided to take the journey to create my very own Jarvis.

If you want the conceptual breakdown of what a harness actually is in more detail, my friend Morgan's post on dev.to covers that well. This post is the hands-on build.

After several hours of tinkering and research I created "The Pulse." It opens Hacker News in a real browser, grabs Reddit posts via RSS, saves everything to persistent storage, and every 6 hours writes a trending stories digest. It messages me every day, or I can message it anytime and ask what's happening in AI. It reads from the data it's been collecting all day.

If you're more like me and love videos, check out the full video below on how to get started. I'm also including the source code so you can try it yourself. Otherwise continue on and learn all about how to get started! Feel free to let me know how it goes.

Full code:

aws-samples / sample-AgentCore-Managed-Harness-News

AgentCore Managed Harness News Sample — The Pulse

A sample AgentCore managed harness project that runs a scheduled news digest agent ("The Pulse") on Amazon Bedrock AgentCore and posts the results to Telegram.

The agent is scheduled with EventBridge Scheduler, invoked via a Lambda trigger, and uses AgentCore Memory to retain context across runs. It's a realistic end-to-end example of building a recurring, long-running agent on AWS.

What's in here

AgentCore-News-Sample/
├── agentcore/
│   ├── agentcore.json          # Project config (runtimes, memories, etc.)
│   ├── aws-targets.json        # AWS account + region to deploy into
│   ├── cdk/                    # CDK infrastructure (@aws/agentcore-cdk)
│   │   ├── bin/cdk.ts          # CDK entry — synthesizes both stacks
│   │   ├── lib/cdk-stack.ts    # AgentCore stack (agent, memory, roles)
│   │   ├── lib/scheduler-stack.ts  # Scheduler + Lambda trigger
│   │   └── lambda/pulse-trigger/   # Lambda that invokes the harness
│   └── .llm-context/           # Type definitions for AI coding assistants

…

View on GitHub

AgentCore Harness is in preview. The CLI, pricing, and some APIs may change. Check the AgentCore docs for the latest.

Table of Contents

What We're Building
Why Not Just Use Lambda?
Prerequisites
Create the Harness Project
Configure the Agent
Deploy
Test the Hourly Collection
Test the Summary Digest
Ask It Questions
Pull Data Out Without Burning Tokens
Schedule It With EventBridge and Lambda
Troubleshooting
Cost Estimate
Cleanup
What's Next

What We're Building

Don't worry if this diagram looks intimidating! The most complicated part is just getting the EventBridge connected with the correct IAM roles to the harness and dealing with the infrastructure code if you're new to that. Let's break down the flow here.

EventBridge fires every hour and triggers a Lambda. EventBridge is AWS's scheduler service, think of it like a cron job in the cloud. The Lambda makes one API call to the harness. Inside the harness, the agent runs in its own microVM, which is basically a lightweight virtual machine that spins up just for your session with its own CPU, memory, and filesystem. The agent opens a browser, scrapes HN, fetches Reddit RSS, and saves a snapshot. Every 6th run it reads all the snapshots, finds trends, and writes a digest. And because the session ID stays the same across runs, all that data accumulates on /mnt/data. You can also just talk to it anytime through the CLI and ask what's trending.

Why Not Just Use Lambda?

Before we get into the details, one question you may be thinking is couldn't we do all this with just a Lambda, some Strands Agents code, an LLM, and a dream? For a simple one-shot task, you are probably right. But this agent needs a few things Lambda can't give you, which makes this approach well worth it.

First, the agent opens a real browser to scrape Hacker News. Lambda can't spin up a managed browser session. You'd need Fargate plus Playwright, and now you're managing containers. I love containers, but let's skip it for this scenario.

Second, it saves hourly snapshots to /mnt/data/runs/ and reads them back 6 hours later. Lambda's /tmp gets wiped after every invocation. You'd need S3 plus custom read/write logic for every file operation. That's a lot of work for what should be "save a file."

Third, the 6-hour summary run reads all the accumulated data, compares scores across snapshots, identifies trends, and writes a digest. That can take a while. Lambda maxes out at 15 minutes. The harness defaults to a 1-hour timeout per invocation (I set mine to 30 minutes since that's plenty), and the microVM itself can stay alive for up to 8 hours across multiple invocations.

And then there's memory. AgentCore Memory is a built-in service that stores facts, preferences, and conversation summaries across sessions. So "What did I ask about yesterday?" works because the memory carries context forward. In Lambda, you'd need DynamoDB plus a custom integration.

Could you build all of this with Lambda plus S3 plus Fargate plus DynamoDB plus Step Functions? Sure. That's five services instead of one. That's four too many for this tutorial.

Prerequisites

Node.js 20+
AWS credentials configured in a preview region (us-west-2, us-east-1, eu-central-1, or ap-southeast-2)
CDK bootstrapped in your account (cdk bootstrap). CDK is the AWS Cloud Development Kit. It lets you define infrastructure in TypeScript instead of clicking through the console. If you haven't used it before, npm install -g aws-cdk and then cdk bootstrap in your account.
The AgentCore CLI:

npm install -g @aws/agentcore@preview

Bedrock model access for Claude Sonnet 4.6 in your region. As of late 2025, Bedrock gives you automatic access to all serverless models in your region without needing to enable them individually. If your organization uses IAM policies or SCPs to restrict model access, make sure Sonnet isn't blocked. You can verify by opening the Bedrock console and trying the model in the playground.

Create the Harness Project

This is where the fun begins. We'll create our very first managed harness.

agentcore create \
  --name thepulse \
  --model-provider bedrock \
  --session-storage-mount-path /mnt/data

cd thepulse

That one command scaffolds the whole project. Harness config, memory, session storage, CDK app, IAM role. The --session-storage-mount-path flag wires up persistent storage so the platform creates a /mnt/data mount point for you. You don't have to worry about a Dockerfile, or container to manage.

Now add the browser tool. AgentCore Browser is a managed headless Chrome instance that the harness can spin up on demand. Your agent can navigate pages, click elements, extract content, basically anything you'd do with Playwright but without managing the browser infrastructure yourself.

agentcore add tool --harness thepulse --type agentcore_browser --name browser

Here's what you end up with:

thepulse/
├── agentcore/
│   ├── agentcore.json          # Project-level resource config
│   ├── aws-targets.json        # Deployment targets (account, region)
│   ├── .env.local              # Local dev config (gitignored)
│   └── cdk/                    # CDK TypeScript app
├── app/
│   └── thepulse/
│       ├── harness.json        # Agent config
│       └── system-prompt.md    # Agent instructions

Configure the Agent

Our AgentCore CLI already set up the model, memory, and session storage. You just need to tweak the execution limits and write the system prompt.

Edit app/thepulse/harness.json:

{
  "name": "thepulse",
  "model": {
    "provider": "bedrock",
    "modelId": "global.anthropic.claude-sonnet-4-6"
  },
  "tools": [
    {
      "type": "agentcore_browser",
      "name": "browser"
    }
  ],
  "skills": [],
  "memory": { "name": "thepulseMemory" },
  "sessionStoragePath": "/mnt/data",
  "maxIterations": 75,
  "timeoutSeconds": 1800
}

A few things worth mentioning here.

I set maxIterations to 75 because browser interactions are chatty. That eats through iterations fast, and 75 gives room for the full HN browser scrape plus Reddit RSS plus file operations without the agent hitting the ceiling.

timeoutSeconds is 1800 (30 minutes). Browser sessions take time, and the summary run reads a lot of data. I didn't hit too many timeouts when testing, but this was a just-in-case update.

This next setting is really useful. The platform creates the /mnt/data mount point automatically when you set sessionStoragePath. This mount point will be shared per session, no matter if the session times out.

Now edit app/thepulse/system-prompt.md. The CLI created this file with a default prompt. Replace it:

You are The Pulse, an AI research agent that monitors Hacker News
and Reddit for AI/ML stories.

You have two modes:

### HOURLY COLLECTION
When the prompt says "hourly run":

**Hacker News (browser):**
1. Use the browser tool to open https://news.ycombinator.com
2. Extract the top 30 stories: title, score, comment count, URL
3. Close the browser session when done

**Reddit (RSS — do NOT use the browser):**
Reddit blocks automated browser access (403). Use the RSS feed instead:
1. Shell: `curl -s -A 'ThePulse/1.0'
   'https://www.reddit.com/r/MachineLearning/.rss'`
2. Parse the XML to extract post titles, URLs, authors, and dates
3. Note: RSS does not include upvote scores. That's expected.
4. Also try r/artificial: `curl -s -A 'ThePulse/1.0'
   'https://www.reddit.com/r/artificial/.rss'`

**Save the snapshot:**
1. Combine HN and Reddit data into a single JSON file
2. Save to /mnt/data/runs/YYYY-MM-DD-HH.json
3. If a previous hour's snapshot exists (check /mnt/data/runs/),
   compare and flag:
   - Stories that appeared in both snapshots (persistent)
   - HN stories with rising scores

### SUMMARY DIGEST
When the prompt says "generate summary":
1. Read all snapshots from /mnt/data/runs/ for the last 6 hours
2. Identify stories that appeared in multiple snapshots
   (persistent presence = trending)
3. Identify stories with rising scores across snapshots
4. Deduplicate and rank by persistence, score growth, and
   comment activity
5. Write a markdown digest to
   /mnt/data/digests/YYYY-MM-DD-{morning|afternoon|evening|night}.md
6. Include the top 10 trending stories with: title, source
   (HN/Reddit), peak score, trend direction, URL

### INTERACTIVE
When a user asks a question:
- Read from /mnt/data/runs/ and /mnt/data/digests/ to answer
- Use memory for conversational context

## Important
- /mnt/data is persistent session storage. Use the same session ID
  across runs so data accumulates.
- Always create directories before writing:
  `mkdir -p /mnt/data/runs /mnt/data/digests`

I put the collection to be hourly and the snapshots to run every six hours. Retrospectively, this is a lot of data, and I could certainly have expanded that. I'd say collecting twice a day and having a snapshot created once a day would be fine as well. Feel free to tweak this prompt to your liking.

One gotcha I'd like to pass on is that Reddit doesn't like agents scraping its data. The agent kept trying to open Reddit in the browser, getting 403'd, and burning 5-6 iterations before giving up. I sat there watching it retry over and over thinking "please just stop." The RSS feed at reddit.com/r/MachineLearning/.rss works every time. Putting it explicitly in the system prompt saves you from that pain.

Deploy

agentcore deploy

One command. It provisions the harness, memory, IAM role, session storage, and the underlying microVM infrastructure. This takes about 3-5 minutes because it's also spinning up AgentCore Memory and running CDK for the IAM roles.

You can verify what got created:

agentcore status --json

Test the Hourly Collection

To test this out you'll need a stable session ID so /mnt/data accumulates across runs, as I mentioned earlier. The session ID needs to be at least 33 characters (a UUID is 36, so that works). This is important because the same session ID means the same filesystem. That's how data builds up over time.

SESSION_ID="thepulse-$(uuidgen)"
echo $SESSION_ID  # Save this. You'll reuse it for every run.

agentcore invoke --harness thepulse \
  --session-id "$SESSION_ID" \
  --actor-id scheduler \
  "Hourly run. Collect AI/ML stories from Hacker News and Reddit. Save the snapshot."

The agent will open a managed Chrome browser, navigate to news.ycombinator.com, extract stories, fetch Reddit via RSS, and save everything to /mnt/data/runs/.

Verify it worked:

agentcore invoke --exec --harness thepulse \
  --session-id "$SESSION_ID" \
  "ls -la /mnt/data/runs/"

That --exec flag is one of my favorite things about the harness. It runs a shell command directly on the microVM. It's not connecting to any LLM so no tokens are used. You can use it to poke around the filesystem anytime without spending money.

Test the Summary Digest

Run the collection a couple times (or wait a few hours), then:

agentcore invoke --harness thepulse \
  --session-id "$SESSION_ID" \
  --actor-id scheduler \
  "Generate summary. Read all snapshots from the last 6 hours and write a trending stories digest."

The agent reads all the hourly snapshots, identifies stories that appeared multiple times (trending), flags rising scores, and writes a markdown digest.

Ask It Questions

agentcore invoke --harness thepulse \
  --session-id "$SESSION_ID" \
  --actor-id demo-user \
  "What's trending in AI right now?"

The agent reads from /mnt/data/runs/ and /mnt/data/digests/ to answer with real data. Not hallucinated summaries, actual scores and URLs from the snapshots it collected. I really liked this part. The agent isn't guessing. It's reading files it wrote earlier that day.

Schedule It With EventBridge and Lambda

The agentcore create command already scaffolded a CDK app at agentcore/cdk/. We'll add a Lambda trigger and an EventBridge schedule to that existing project. EventBridge Scheduler is the AWS service that fires events on a cron schedule. We'll have it invoke a Lambda every hour, and that Lambda calls the harness. One agentcore deploy handles the harness, one cdk deploy handles the scheduler. I like keeping these separate because you iterate on the agent config way more often than the scheduling infrastructure.

Set Up the Lambda

mkdir -p agentcore/cdk/lambda/pulse-trigger
cd agentcore/cdk/lambda/pulse-trigger
npm init -y
npm install @aws-sdk/client-bedrock-agentcore @aws-sdk/client-secrets-manager
npm install -D typescript @types/node esbuild
cd ../../../..

Create agentcore/cdk/lambda/pulse-trigger/index.ts:

import {
  BedrockAgentCoreClient,
  InvokeHarnessCommand,
} from "@aws-sdk/client-bedrock-agentcore";
import {
  SecretsManagerClient,
  GetSecretValueCommand,
} from "@aws-sdk/client-secrets-manager";

interface TelegramSecret {
  botToken: string;
  defaultChatId: string;
}

const agentCore = new BedrockAgentCoreClient({ region: process.env.AWS_REGION });
const secrets = new SecretsManagerClient({ region: process.env.AWS_REGION });

// Cache the secret across warm invocations
let cachedSecret: { value: TelegramSecret; expiry: number } | null = null;
const SECRET_TTL_MS = 5 * 60 * 1000; // 5 minutes

async function getSecret(): Promise<TelegramSecret> {
  if (cachedSecret && Date.now() < cachedSecret.expiry) {
    return cachedSecret.value;
  }
  const secretArn = process.env.TELEGRAM_SECRET_ARN;
  if (!secretArn) throw new Error("Missing TELEGRAM_SECRET_ARN env var");

  const res = await secrets.send(
    new GetSecretValueCommand({ SecretId: secretArn })
  );
  const value: TelegramSecret = JSON.parse(res.SecretString!);
  cachedSecret = { value, expiry: Date.now() + SECRET_TTL_MS };
  return value;
}

async function sendToTelegram(
  botToken: string, chatId: string, text: string
) {
  // Telegram's message limit is 4096 chars. Split if needed.
  const chunks = text.match(/[\s\S]{1,4000}/g) || [];
  for (const chunk of chunks) {
    const res = await fetch(
      `https://api.telegram.org/bot${botToken}/sendMessage`,
      {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({
          chat_id: chatId,
          text: chunk,
          parse_mode: "Markdown",
        }),
      }
    );
    if (!res.ok) {
      console.error("Telegram send failed:", await res.text());
    }
  }
}

export const handler = async () => {
  const hour = new Date().getUTCHours();
  const sessionId = process.env.STABLE_SESSION_ID!;
  const harnessArn = process.env.HARNESS_ARN!;

  const isSummaryRun = hour % 6 === 0;

  const prompt = isSummaryRun
    ? "Generate summary. Read all snapshots from the last 6 hours and write a trending stories digest."
    : "Hourly run. Collect AI/ML stories from Hacker News and Reddit. Save the snapshot.";

  const command = new InvokeHarnessCommand({
    harnessArn,
    runtimeSessionId: sessionId,
    actorId: "scheduler",
    messages: [{ role: "user", content: [{ text: prompt }] }],
  });

  const response = await agentCore.send(command);

  // Collect the full response text from the stream
  let responseText = "";
  let chunkCount = 0;
  if (response.stream) {
    for await (const event of response.stream) {
      chunkCount++;
      if ("contentBlockDelta" in event) {
        const delta = (event as any).contentBlockDelta?.delta;
        if (delta && "text" in delta) {
          responseText += delta.text;
          process.stdout.write(delta.text);
        }
      }
    }
  }

  console.log(
    `\n[pulse-trigger] Stream complete — ${chunkCount} chunks`
  );

  // On summary runs, send the digest to Telegram
  if (isSummaryRun && responseText) {
    const { botToken, defaultChatId } = await getSecret();
    await sendToTelegram(botToken, defaultChatId, responseText);
  }

  return {
    statusCode: 200,
    hour,
    type: isSummaryRun ? "summary" : "collection",
    digestSent: isSummaryRun,
  };
};

Let's break down what's happening here.

The Lambda passes a stable session ID (from an environment variable) so every hourly run writes to the same /mnt/data. It collects the full response text from the stream and logs it to CloudWatch. On summary runs, it sends the digest to Telegram using a bot token stored in Secrets Manager. Secrets Manager is the AWS service for storing sensitive values like API keys and tokens. You don't want a bot token sitting in an environment variable where anyone with console access can see it. The sendToTelegram function handles Telegram's 4096 character limit by chunking the text. I found the CloudWatch logging really helpful for debugging early on when the agent would occasionally get stuck in a browser loop.

Add the Scheduler Stack

Create agentcore/cdk/lib/scheduler-stack.ts. This is a CDK stack, which is basically a unit of deployment. Everything in this file gets deployed together as one CloudFormation stack.

import {
  Stack, StackProps, Duration, TimeZone, CfnOutput,
} from "aws-cdk-lib";
import { NodejsFunction } from "aws-cdk-lib/aws-lambda-nodejs";
import { Runtime } from "aws-cdk-lib/aws-lambda";
import { Secret } from "aws-cdk-lib/aws-secretsmanager";
import * as iam from "aws-cdk-lib/aws-iam";
import * as scheduler from "aws-cdk-lib/aws-scheduler";
import * as targets from "aws-cdk-lib/aws-scheduler-targets";
import { Construct } from "constructs";
import * as path from "path";

export interface PulseSchedulerStackProps extends StackProps {
  agentRuntimeArn: string;
  harnessArn: string;
  stableSessionId: string;
  telegramSecretArn: string;
}

export class PulseSchedulerStack extends Stack {
  constructor(
    scope: Construct, id: string, props: PulseSchedulerStackProps
  ) {
    super(scope, id, props);

    const telegramSecret = Secret.fromSecretCompleteArn(
      this, "TelegramSecret", props.telegramSecretArn
    );

    const triggerFn = new NodejsFunction(this, "PulseTrigger", {
      runtime: Runtime.NODEJS_22_X,
      entry: path.join(
        __dirname, "../../lambda/pulse-trigger/index.ts"
      ),
      handler: "handler",
      timeout: Duration.minutes(15),
      memorySize: 256,
      environment: {
        HARNESS_ARN: props.harnessArn,
        STABLE_SESSION_ID: props.stableSessionId,
        TELEGRAM_SECRET_ARN: props.telegramSecretArn,
      },
      bundling: {
        externalModules: [],
      },
    });

    triggerFn.addToRolePolicy(
      new iam.PolicyStatement({
        actions: [
          "bedrock-agentcore:InvokeHarness",
          "bedrock-agentcore:InvokeAgentRuntime",
        ],
        resources: [
          props.harnessArn,
          props.agentRuntimeArn,
        ],
      })
    );

    // Read access to the Telegram bot token secret
    telegramSecret.grantRead(triggerFn);

    new scheduler.Schedule(this, "HourlySchedule", {
      schedule: scheduler.ScheduleExpression.cron({
        minute: "0",
        hour: "*",
        timeZone: TimeZone.of("UTC"),
      }),
      target: new targets.LambdaInvoke(triggerFn, {}),
      description: "The Pulse — hourly AI/ML news collection",
    });

    new CfnOutput(this, "TriggerFunctionName", {
      value: triggerFn.functionName,
    });
  }
}

The telegramSecret.grantRead(triggerFn) line gives the Lambda permission to read the bot token from Secrets Manager. The bot token lives there instead of in environment variables so it doesn't show up in CloudFormation outputs or the Lambda console.

Wire it into agentcore/cdk/bin/cdk.ts:

import { PulseSchedulerStack } from "../lib/scheduler-stack";

// ... existing AgentCore stack code ...

new PulseSchedulerStack(app, "ThePulseScheduler", {
  harnessArn: "REPLACE_WITH_YOUR_HARNESS_ARN",
  agentRuntimeArn: "REPLACE_WITH_YOUR_RUNTIME_ARN",
  stableSessionId: "REPLACE_WITH_YOUR_SESSION_ID",
  telegramSecretArn: "REPLACE_WITH_YOUR_SECRET_ARN",
  env: {
    account: targets[0].account,
    region: targets[0].region,
  },
});

I'm showing placeholders here to make it clear what goes where. You can get your harness ARN and runtime ARN with agentcore status --json, and use the same session ID you've been testing with. The Telegram secret ARN comes from Secrets Manager (store your bot token and chat ID as a JSON object with botToken and defaultChatId keys).

That said, you shouldn't hardcode ARNs and secrets into source files you commit to git. The actual repo resolves the harness ARN and runtime ARN automatically from the deployed state file that agentcore deploy creates, and reads the Telegram secret ARN and session ID from environment variables. That way nothing sensitive ends up in version control. Check the cdk.ts in the repo for the full implementation.

Deploy and Test

# Install esbuild in the CDK project (needed for NodejsFunction)
cd agentcore/cdk && npm install esbuild --save-dev && cd ../..

# Deploy the harness
agentcore deploy

# Deploy the scheduler stack
cd agentcore/cdk && npm run build && npx cdk deploy ThePulseScheduler && cd ../..

Test the Lambda directly:

aws lambda invoke \
  --function-name $(aws cloudformation describe-stacks \
    --stack-name ThePulseScheduler \
    --query 'Stacks[0].Outputs[?OutputKey==`TriggerFunctionName`].OutputValue' \
    --output text) \
  --region us-west-2 \
  --cli-read-timeout 900 \
  /tmp/lambda-response.json

cat /tmp/lambda-response.json

The --cli-read-timeout 900 is important. The harness invocation takes a few minutes (the agent is browsing HN, fetching RSS, saving data), and the AWS CLI's default timeout is 60 seconds. Without it, you'll get a Read timeout error even though the Lambda is still running fine. Don't make this mistake like I did.

You should see {"statusCode":200,"hour":...,"type":"collection"}.

Troubleshooting

A few things I hit while building this. Hopefully they save you some time.

npm ci fails during CDK synth. If you use nodeModules in the bundling config instead of externalModules: [], CDK copies your package-lock.json into a temp directory and runs npm ci. If the lock file is even slightly out of sync with package.json, it fails. I went back and forth on this for a while before landing on the externalModules: [] approach that bundles everything with esbuild and skips npm ci entirely.

AccessDeniedException on ConverseStream. This one got me. Bedrock now gives automatic access to all models in your region, so the old "Model Access" page is gone. But if your organization uses IAM (Identity and Access Management) policies or SCPs (Service Control Policies) to restrict which models can be invoked, you'll get this error. Check with your admin to make sure the model isn't blocked by a deny policy. I hit this when I tried to use Haiku for cheaper collection runs in an account that had an SCP limiting models to Sonnet only. The error message doesn't make it obvious that it's a permissions issue.

Lambda times out but the agent is still running. The Lambda timeout (15 min max) and the harness timeout (30 min) are separate. If the agent takes longer than the Lambda allows, the Lambda dies but the harness session keeps running in the background. Check CloudWatch logs for the Lambda, and use agentcore logs --harness thepulse --since 1h for the harness side.

Reddit returns 403 in the browser. Reddit blocks automated browser access. The system prompt tells the agent to use RSS instead, but if you're iterating on the prompt and forget to include that instruction, the agent will waste iterations trying to open Reddit in the browser. Ask me how I know.

Cost Estimate

The main cost here is Bedrock model usage. Each hourly collection run uses around 10-15K tokens (browser interactions are chatty), and summary runs use more since they read all the accumulated data. Lambda and EventBridge are basically free at this scale.

You can cut costs by enabling a cheaper model like Haiku in the Bedrock console and passing a model override for collection runs. Keep Sonnet for the summary runs that need more reasoning. The harness supports per-invocation model overrides so you don't need to redeploy. You can also just reduce the number of times it collects data.

AgentCore Runtime and Browser have no separate charge during preview.

Check the Bedrock pricing page for current model token costs and the AgentCore pricing page for runtime and browser session rates.

Cleanup

Make sure you always clean up your stacks after trying out tutorials!

# Delete the scheduler stack
cd agentcore/cdk && npx cdk destroy ThePulseScheduler && cd ../..

# Delete the harness and all AgentCore resources
agentcore destroy

The agentcore destroy command removes the harness, memory, IAM role, and session storage. The CDK destroy removes the Lambda, EventBridge schedule, and any IAM roles CDK created.

What's Next

This is a starting point. I have thoughts on a few directions I could take my very own Jarvis 😊.

Right now the Telegram integration is outbound only. I want to add two-way chat so I can message the bot and ask questions (without just using the command line). That means an API Gateway webhook and a second Lambda that invokes the harness in interactive mode. The agent reads from /mnt/data to answer with real data.

More sources would be easy to add. The system prompt is just markdown. Add instructions for other news sources that a browser can reach. The nice thing is it would just take a prompt update and a new run of agentcore deploy.

I also want to try switching models per run. Enable Haiku in the Bedrock console and pass --model-id on collection runs for cheaper hourly scrapes. Keep Sonnet for the summary runs that need more reasoning. The harness supports this per-invocation without a redeploy.

And eventually, a dashboard. Have the agent generate an HTML page from the accumulated data and sync it to S3. Use --exec to run aws s3 sync from the microVM.

After building this, I'm convinced the harness approach works really well for simpler use cases like my personal news Jarvis. If your agent needs persistent state, scheduled runs, and a browser, this is way less infrastructure than stitching it together yourself. If you just need a one-shot agent that answers a question, stick with Lambda. And of course if you need maximum flexibility, using AgentCore runtime is your best bet!

Let me know in the comments what you think! Thanks!

Resources

Stop Reaching for Python: Strands Agents TypeScript SDK Just Hit 1.0

Erik Hanchett — Mon, 04 May 2026 20:11:08 +0000

A lot of production codebases are TypeScript. A lot of agent frameworks are Python. If yours is both, you either rewrite your stack or build a bridge between two languages. Strands Agents just shipped 1.0 of the TypeScript SDK, so now you don't have to. It's the full framework, native TypeScript types and all. And it does things Python can't, like running agents in the browser.

The Python SDK has been in production since May 2025. This is the same model-driven approach, now with full TypeScript types and Zod-validated tools.

Full disclosure, I'm a Developer Advocate for AWS. Strands is an open source project from AWS. I've been building with the Python SDK for months, so I was curious how the TypeScript version compares. So far, it's been great.

In this post we'll cover:

Getting a basic agent running
Defining type-safe tools with Zod
Connecting MCP servers
Streaming responses
Running agents in the browser
Multi-agent patterns: agent-as-tool, Graph, and Swarm

Get Started

Install the SDK:

npm install @strands-agents/sdk

Here's how it works.

Two Lines to a Working Agent

The API is small on purpose. Create an agent, then invoke.

import { Agent } from '@strands-agents/sdk'

const agent = new Agent({ systemPrompt: 'You are a helpful assistant.' })
const result = await agent.invoke('What makes TypeScript great for building agents?')

console.log(result.lastMessage)

Bedrock is the default model provider. If you want OpenAI, Anthropic, Google, or anything that works with the Vercel AI SDK, you swap one import:

import { Agent } from '@strands-agents/sdk'
import { OpenAIModel } from '@strands-agents/sdk/models/openai'

const model = new OpenAIModel({ api: 'chat', modelId: 'gpt-5.4' })
const agent = new Agent({ model, systemPrompt: 'You are a helpful assistant.' })

You just swap the model import. The agent, tools, and invocation pattern don't change at all.

Zod Tools

TypeScript is a good fit here because you're defining the contract between your agent and your tools at the type level. You define a tool with a Zod schema and get runtime validation plus full type inference at compile time. The model can't pass garbage to your tool without Zod catching it, and your editor knows the exact shape of every input before you even run anything.

Here's a GitHub lookup tool in about 30 lines:

import { Agent, tool } from '@strands-agents/sdk'
import { z } from 'zod'

const githubRepo = tool({
  name: 'get_github_repo',
  description: 'Get info about a GitHub repository.',
  inputSchema: z.object({
    owner: z.string().describe('Repository owner'),
    repo: z.string().describe('Repository name'),
  }),
  callback: async (input) => {
    const res = await fetch(`https://api.github.com` + `/repos/${input.owner}/${input.repo}`)
    const data = await res.json()
    return `${data.full_name} — ⭐ ${data.stargazers_count} stars`
  },
})

const agent = new Agent({
  tools: [githubRepo],
  systemPrompt: 'You are a developer assistant.',
})

The input parameter in that callback is fully typed. Your editor knows input.owner is a string. No any, no type casting.

The SDK also ships with built-in tools for bash, file editing, HTTP requests, and notebooks. Your agent can read files, hit APIs, and run shell commands without writing any tool code:

import { Agent } from '@strands-agents/sdk'
import { bash } from '@strands-agents/sdk/vended-tools/bash'
import { fileEditor } from '@strands-agents/sdk/vended-tools/file-editor'
import { httpRequest } from '@strands-agents/sdk/vended-tools/http-request'
import { notebook } from '@strands-agents/sdk/vended-tools/notebook'

const agent = new Agent({
  tools: [bash, fileEditor, httpRequest, notebook],
  systemPrompt: 'You are a helpful coding assistant.',
})

MCP

If you're already using MCP servers, they plug right in. I tested this with the filesystem MCP server and it worked well.

import { Agent, McpClient } from '@strands-agents/sdk'
import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js'

const mcp = new McpClient({
  transport: new StdioClientTransport({
    command: 'npx',
    args: ['-y', '@modelcontextprotocol/server-filesystem', process.cwd()],
  }),
})

const agent = new Agent({ tools: [mcp] })

Any MCP-compatible server works the same way. One McpClient import and you're done. I've used this with the filesystem server, a Postgres server, and a few custom ones, and the setup is identical every time.

Streaming

Async iterators let you generate chunks and stream them back to the user.

const agent = new Agent({ systemPrompt: 'You are a creative storyteller.', printer: false })

for await (const event of agent.stream('Tell me a short story about a brave toaster.')) {
  if (
    event.type === 'modelStreamUpdateEvent' &&
    event.event.type === 'modelContentBlockDeltaEvent' &&
    event.event.delta.type === 'textDelta'
  ) {
    process.stdout.write(event.event.delta.text)
  }
}

The event type checking is verbose. You're narrowing through three nested types to get to the actual text delta. That's just how TypeScript streaming works when the event union is this wide. Once you have the pattern, you copy it.

It Runs in the Browser

You can run agents in the browser. Most people don't think about this because the Python SDK can't do it natively.

There's a demo in the strands-agents/sdk-typescript repo where you chat with an agent and it builds a live HTML canvas in real time. The agent runs entirely client-side.

That opens up things that weren't possible before: local-first tools where the agent runs on the user's machine, interactive assistants embedded in your app without a server round-trip, or even running the model locally if you want to skip the round-trip entirely.

I cloned the demo and had it running in a few minutes.

git clone https://github.com/strands-agents/sdk-typescript.git
cd sdk-typescript/strands-ts/examples/browser-agent
npm install && npm run dev

Multi-Agent Patterns

The SDK ships with three ways to combine agents: agent-as-tool, Graph, and Swarm. Each one fits a different problem.

Agent-as-tool

This is the one you'll reach for most. Pass a sub-agent directly into another agent's tools array and it gets wrapped automatically. The outer agent decides when to call it, just like any other tool.

Think of a writer agent that has a researcher agent as a tool. The writer decides when it needs facts, calls the researcher, gets the results back, and uses them to write. The code below is exactly that.

import { Agent } from '@strands-agents/sdk'

const researcher = new Agent({
  id: 'researcher',
  name: 'Researcher',
  description: 'Finds factual information and returns concise bullet-point findings.',
  systemPrompt: 'You are a fact-finder. Return 3-5 concise bullet points. Be brief.',
  printer: false,
})

const writer = new Agent({
  systemPrompt: 'You are a prose writer. Use the Researcher tool to gather facts, then write one short paragraph.',
  tools: [researcher], // sub-agent auto-wrapped via asTool()
  printer: false,
})

const result = await writer.invoke('Write a paragraph about the deepest point in the ocean.')

Graph

Graph is for deterministic pipelines. You define agents as nodes and wire them together with edges. A node runs once all its upstream dependencies complete, so execution order is guaranteed. Nodes with no dependency between them can run in parallel.

This pattern works well when you know the steps upfront and need them to always run in the same order. A research pipeline is a good example. Plan the questions, research each one, then synthesize the results. You wouldn't want the synthesizer running before the researcher finishes, and you don't want the model deciding to skip steps.

import { Agent, Graph } from '@strands-agents/sdk'

const planner = new Agent({
  id: 'planner',
  printer: false,
  systemPrompt: 'Break the request into 2 short research questions.',
})
const researcher = new Agent({
  id: 'researcher',
  printer: false,
  systemPrompt: 'Answer each research question in 1-2 sentences. Be concise.',
})
const synthesiser = new Agent({
  id: 'synthesiser',
  printer: false,
  systemPrompt: 'Write a 2-3 sentence summary of the research.',
})

const graph = new Graph({
  nodes: [planner, researcher, synthesiser],
  edges: [
    ['planner', 'researcher'],
    ['researcher', 'synthesiser'],
  ],
})

// MultiAgentResult.content holds the combined output from terminus nodes
const result = await graph.invoke('What are the main impacts of lithium mining?')
console.log(result.content)

The edges array defines the DAG (directed acyclic graph — basically a dependency map). planner runs first, feeds into researcher, which feeds into synthesiser. The final output comes from the terminus node via result.content.

Swarm

Swarm is for when the path isn't known upfront. You define a set of agents with descriptions, pick a starting agent, and the model decides at runtime which agent handles the next step. Each agent either produces a final answer or hands off to another agent.

I'd reach for this when building something like a customer support bot where you don't know which specialist is needed until you see what the user actually wrote. The routing logic lives in the model, not in your code. You're not writing if request.includes('billing') anywhere.

import { Agent, Swarm } from '@strands-agents/sdk'

const triage = new Agent({
  id: 'triage',
  printer: false,
  description: 'Classifies the user request and routes it to the right specialist.',
  systemPrompt: 'Route to "billing" or "technical". Do not answer yourself.',
})
const billing = new Agent({
  id: 'billing',
  printer: false,
  description: 'Handles billing and payment questions.',
  systemPrompt: 'Resolve billing queries. Do not hand off further.',
})
const technical = new Agent({
  id: 'technical',
  printer: false,
  description: 'Handles technical and product questions.',
  systemPrompt: 'Resolve technical queries. Do not hand off further.',
})

const swarm = new Swarm({
  nodes: [triage, billing, technical],
  start: 'triage',
  maxSteps: 6,
})

const result = await swarm.invoke('My invoice shows the wrong amount.')
console.log(result.content)

Heads up if you're on Bedrock: Swarm uses structured output to drive handoffs. It forces a tool call to get the routing decision, and the current Claude Sonnet model on Bedrock throws a "does not support assistant message prefill" error when that happens. Swarm works fine with the Anthropic direct API or other providers that support forced tool choice. If you're on Bedrock and need dynamic routing, agent-as-tool is the safer option for now.

I haven't tested the plugin system, session persistence, or OpenTelemetry tracing yet. The plugin system looks simple to use and I'll probably dig into it next.

The SDK is open source. If you build something with it, I want to see it. The browser runtime especially. I'm curious where people take it.

What We Covered

The Strands Agents TypeScript SDK gives you a full agent framework without leaving your existing stack. Here's what we went through:

A basic agent runs in two lines. Bedrock is the default, but swapping to OpenAI or Anthropic is one import.
Zod tools give you runtime validation and compile-time type inference. The model can't pass bad input without Zod catching it.
MCP servers connect with a single McpClient import. Any MCP-compatible server works.
Streaming uses async iterators. Verbose event types, but that's TypeScript being TypeScript.
The browser runtime is real and working. Clone the demo and see it for yourself.
For multi-agent work: agent-as-tool for orchestrator/worker setups, Graph for fixed pipelines, Swarm for dynamic routing (just not on Bedrock yet).

If you want to go deeper, the TypeScript quickstart, the GitHub repo, and the API docs are the best next stops.

Watch the Full Video

If you prefer video format, here's a quick walkthrough of the TypeScript SDK and its key features:

I Tried Vite+ and Replaced My Entire Frontend Toolchain

Erik Hanchett — Thu, 19 Mar 2026 17:02:19 +0000

If you're a frontend developer in 2026, you've probably had to deal with a lot of different tooling. Package managers, linters, formatters, pre-commit hooks, test runners. The list goes on. And every team has opinions on which ones to use.

I've worked on apps where hours if not days went into tweaking, upgrading, and swapping out tooling. And the bikeshedding when someone proposes something new in a meeting? Don't get me started. Earlier in my career I remember spending over an hour debating whether we should add Vitest or keep the old test runner. We ended up not changing anything.

That's why I really like Vite+. Vite+ is a unified toolchain that acts as an entrypoint for web development. It comes out of the team from VoidZero, the company founded by Evan You, the creator of Vite and Vue. You can think of it like a ShamWow for your toolchain. One tool that replaces your linter, formatter, test runner, bundler, and package manager all at once.

I also made a full video walkthrough where I set up a Vue project from scratch, run into the Nuxt issues in real time, and show the formatting and testing in action. If you'd rather watch than read, check it out below!

What's inside Vite+
A few caveats
Getting started
Creating your first app
Important commands
- Checking and linting
- Formatting
- Testing
- Caching with vp run
- Managing Node.js with vp env
Conclusion

What's inside Vite+

Instead of having to worry about building, installing, adding every tool you need when building an app, and dealing with configurations in 10 different files, you can now rely on one Vite powered toolchain. In essence, Vite+ combines all of these tools into one.

Vite as your build tool, now even faster with Vite 8
Vitest for testing
Oxlint for linting, replacing ESLint
Oxfmt for formatting, replacing Prettier and Biome
Rolldown for bundling, replacing ESBuild
tsdown for library bundling
Node.js runtime and package manager built in

Since many of these tools are written in Rust, the performance gains are real. According to VoidZero's announcement, Oxlint runs 50 to 100x faster than ESLint, Oxfmt formats up to 30x faster than Prettier, and production builds with Vite 8 and Rolldown are 1.6x to 7.7x faster than Vite 7. I had to test this out in my own projects, and using the vp check command was finishing in under a second on fairly large code bases.

A few caveats

While having everything in one tool helps, it does have some DX papercuts at this point. For example, while they do support most package managers (pnpm, npm, yarn), they are missing bun. There is also some more work to be done with the vite.config.ts on Nuxt and TanStack Start since the tooling for each aren't quite there yet. Nevertheless it's early days in Vite+, and it's still in alpha, so I'm sure the updates are happening soon.

I'd imagine if you are not sold on the Vite ecosystem, or using toolchains in general, this probably isn't the tool for you. I, like many other developers, have opinions, and often when I create apps I have very bespoke patterns I use. In my case, I use npm create vue@latest for every Vue app, and npm create nuxt@latest for Nuxt apps. The Vue scaffolder does let you opt into ESLint, Prettier, and Vitest during setup, which is nice. But each one gets its own config file, you still have to make sure they play well together, and things like pre-commit hooks are on you to wire up with husky or lint-staged. It adds up. I also have a very specific set of skills and markdown files I use with Kiro, to help me code.

With Vite+, all of that comes out of the box. One vp create vue and I have linting, formatting, testing, and pre-commit hooks ready to go in a single vite.config.ts. That's what sold me on it.

Let's take a look at how to set it up.

Getting started

As described in the Vite+ setup guide you can install it on your macOS/Linux with a simple curl command.

curl -fsSL https://vite.plus | bash

That should be it!

During the install you'll be asked a few questions around how Vite+ should manage your global Node.js runtime and package manager. You can opt-out of this, and use nvm or whatever else you'd like. However, I actually think this is really nice feature. With Vite+ you can use the vp env command to switch between environments really easily.

From here you can either start creating apps, or migrate existing Vite apps over. I've only really tested the creating apps options, so we'll look at that. I have seen a few people using the vp migrate command to do migration. It seems to work OK, but still requires manual intervention. One cool thing from the Vite+ announcement is that they provide a migration prompt you can paste directly into your AI coding agent. So if you're using Kiro or kiro-cli, you could have it handle the migration for you and just review the changes after. Here's the prompt:

Migration prompt: Migrate this project to Vite+. Run vp help to understand Vite+'s capabilities. Migrations can be run using vp migrate. Run vp help migrate for options. After the migration, verify the changes and make sure that type checking, linting, formatting, and tests pass. High-five your human when you are done.

Creating your first app

After installation you can then create a new app using the vp create command. This will then ask a few quick questions on what kind of application you'd like and it will then scaffold it all for you.

As of this blog post it defaults to a non JS Framework solution. While this is fine for a demo, I don't really get it, because I don't think many people today create websites without some sort of framework or library. Instead you can use this command.

vp create <template>

Right now it supports, vite, @tanstack/start, svelte, next-app, nuxt, react-router and vue. As I mentioned earlier with Nuxt they have not combined the nuxt.config.ts and the vite.config.ts together, so while you can use it, it's not quite ready yet. I also had issues with the next-app. I wasn't sure if it was trying to use a Vite-based Next app or the standard one. Either way it wasn't quite working.

After adding a template name it will then setup your app. It should look familiar if you're using something like npm create vite.

After install you'll then have a unified vite.config.ts file that you can then enter all your configurations for linting, formatting and testing. This worked surprisingly well and I was happy not having to worry about where to add each file.

Since Vite+ uses the Oxc set of tools, I added in the official Oxc extension for formatting and linting. This made it even easier so that my IDE was aware of these tools.

Important commands

Beyond vp create you have a number of interesting commands you can run with vp. Here are a few I've found useful. Although, if you'd like a full list please check out the official guide.

Checking and linting

vp check

The vp check is the default command for fast static checks in Vite+. It combines both the formatting with Oxfmt and the linting with Oxlint, and the TypeScript type checks via tsgolint. Combined this is an extremely fast static checker.

Under the hood, tsgolint is powered by tsgo, the official Go port of the TypeScript compiler from Microsoft. This means your type checking is running at native speed, not through Node.js. It's a big reason why vp check feels so fast.

If you like you can have it try to fix the issues.

vp check --fix

In my tests, this still takes a lot of manual intervention as expected. What's nice is that a competent AI coding tool, like Kiro, can knock these type errors out in no time.

Vite+ also has built in pre-commit hook support. When you scaffold a project with vp create, it can set up hooks for you automatically. You can also run vp prepare to install them later, and configure what runs on staged files right in your vite.config.ts. No more husky or lint-staged setup.

Formatting

vp fmt

This will run the Oxfmt formatter. It has full Prettier compatibility and is designed as a drop-in replacement for Prettier.

Personally, I love prettier, but it does have its quirks. What's really nice is you can just go into the vite.config.ts file and add any rules you need.

import { defineConfig } from 'vite-plus';

export default defineConfig({
  fmt: {
    singleQuote: true,
  },
});

When I first setup my app using vp create vue it asked me if I'd like to update the .vscode/settings.json. I'd highly recommend this so if you're using the Oxfmt extension it can find your formatting settings. Otherwise you can manually add it.

{
  "oxc.fmt.configPath": "./vite.config.ts"
}

Testing

I love testing, so running tests with Vitest is great.

vp test

This will kickoff the vitest test runner in your project. There is also a watch and a run --coverage command. And like all the other commands you can edit the configuration in the vite.config.ts file.

import { defineConfig } from 'vite-plus';

export default defineConfig({
  test: {
    include: ['src/**/*.test.ts'],
  },
});

One quick annoyance with running the vp commands is that they do override your package.json scripts. So to run anything in your scripts you must run vp run <command>. Otherwise it will run the built in commands. I was watching a live stream with Theo Browne from T3 and he hated this. I'm on the fence, but maybe they'll change it in the future.

Caching with vp run

Another nice feature is caching.

vp run --cache build

This will cache the build and if nothing changes the output is replayed on the next run. I have not used this command personally but anything to speed up builds I'm all for.

Managing Node.js with vp env

Another really neat feature is the vp env command.

vp env <command>

vp env manages Node.js versions globally and per project. By default, Vite+ runs in managed mode, meaning it controls which Node.js version is used. It stores the runtime and related files in ~/.vite-plus (you can override this with VITE_PLUS_HOME).

If you don't want Vite+ managing your Node.js, you can switch to system-first mode:

vp env off

This tells the shims to prefer your system Node.js and only fall back to the Vite+ managed runtime when needed. If you ever want to switch back, just run:

vp env on

You can also pin a certain Node.js version in the current directory with:

vp env pin

Or install an entirely new version.

vp env install

I really liked all this flexibility with the package manager. I personally use nvm but I like the idea of this being handled by Vite+. One less thing to worry about.

While I haven't tried it, I'm curious to see how well this works in a CI environment. It looks like you can easily set this up in your GitHub actions and run all the checks you need.

- uses: voidzero-dev/setup-vp@v1
  with:
    node-version: '22'
    cache: true
- run: vp install
- run: vp check
- run: vp test
- run: vp build

Conclusion

I could definitely see Vite+ saving me time when I create a new application. Having one configuration file to put everything in, and not having to think about which linter, formatter, or test runner to install, is a nice change. The vp commands are straightforward and the whole thing just works.

With that said, this project is still in alpha, and we'll see how much it catches on. With so much of the frontend ecosystem already using Vite, it makes sense for a tool like Vite+ to exist. Let me know if you would use something like this. I think it's very interesting. Thanks!

5 Things To Avoid When Working With AI Coding Tools

Erik Hanchett — Thu, 12 Mar 2026 21:10:42 +0000

As a software developer in 2026 you can't escape AI. It's everywhere, and almost every company is using some sort of AI coding tool. And as a long time full-stack developer whose roots are in the front-end, I wasn't always convinced.

Over the past two years I've seen both sides of AI. The terrible designs, but also the surprisingly decent ones. Demo apps that used to take me hours, done in minutes. But I've also found myself knee-deep in AI slop, wondering if I actually saved any time at all.

So are these coding tools making me faster or not? I had to look into it more.

Want to watch a video on the subject then read about it? Check this out!

Last year, Model Evaluation and Threat Research, or METR, ran a randomized controlled trial and found that when experienced open source developers used AI tools, it took them 19% longer to complete tasks than without. AI was actually a detriment to their productivity.

On the other hand, GitHub conducted their own controlled trial around the same time and found that developers coded up to 55% faster with AI assistance.

So which is it?

After trying these tools out myself for the last two years, I can confidently say I think both are true. And the difference comes down to the approach used. AI tools, just like any other tool, can be misused. If the only tool you have is a hammer, every problem starts to look like a nail. When I first started using AI, I used it for everything. New features, bug fixes, refactors, brainstorming, all of it. And at first it felt amazing. But I kept running into the same problems over and over. The output looked good on the surface, but I'd spend more time fixing what it gave me than if I'd just written it myself.

Here are 5 ways AI can hurt you instead of help you, especially on the frontend.

No Real Feature Definition

I like jumping into a coding agent right away. I start vibe coding as soon as my fingers reach the keyboard, but this actually isn't a great way to start. The AI will absolutely give me what I ask for, and it might even work, but the problem lies in the details.

The design generated is often not great (I'm looking at you GPT) and the features don't always work. Validation, error handling, responsiveness, and accessibility will often be partially implemented or skipped entirely. That's when things fall apart.

The real issue is that you need to define what success looks like. If you don't, the AI just guesses, and though it gets some of it right, it gets a lot wrong. Ambiguity isn't your friend.

The real issue is that you need to define what success looks like.

Don't get me wrong, you don't need a 15 page requirements document with detailed designs for every use case. However, maybe a few bullet points and some basic acceptance criteria will help. Simply defining what the feature should do and not do is the minimum you should ask. Adding this all to a markdown file before you get started will dramatically improve what the AI generates for you.

Too Much Bad Context

So that means I should put everything into the context window? Use as many AGENTS.md and markdown files as I can before I start, right? Well, yes we need more context but there is more to it than that.

The second problem is putting too much into your context window. Whenever you work with a coding tool, I prefer Kiro so I'll use that as an example, it has a defined amount of space it can handle. This is often influenced by the model you select. Some models have larger context windows, others have smaller.

Either way, stuffing everything you can find into lots of markdown files causes the opposite problem from #1. Now the model has to comb through lots of useless information to find what it needs. We've recently seen research that shows that more is not always better.

Recent research across over 60,000 repos found that context files are often too long, too vague, and are actively making agents worse. In one study, accuracy dropped from 87% to 54% just from context overload.

Context overload doesn't just drop accuracy, it can also increase token cost. When every request sends more information than is needed, you uselessly waste tokens, which in turn hits your pocketbook.

At the end of the day, it's more about quality than quantity when you're dealing with context windows. Think about it like giving directions. If someone asks you how to get to the grocery store and you hand them a 200-page atlas, that's technically more information. But it's not more helpful.

When creating an AGENTS.md file (or steering file if you're using Kiro), only include information that is needed for your project. Constrain it to your coding practices, tabs vs spaces, design system, API contracts and rendering. Make sure to remove unneeded fluff, and keep it up to date. When I use Kiro, I create an agent that automatically updates my markdown files when I make changes to my components. That way I always have the latest updates in my context files.

There's probably a Goldilocks zone of context. Not too little, not too much. Just the stuff that actually matters for the task.

Too Much in One Shot

While having too much or too little in your context is important, you still need to know the limitations of what you're asking your coding agent to do. One common problem I see is that developers will try to one-shot a whole application. I'll see prompts to build a frontend, backend, tests, create all the things at once. It feels like you're making a lot of progress, and it outputs something in just a few minutes.

This could actually work for a quick prototype or demo. However, in production this is not what you want. You'll end up with a lot of AI slop that often takes a lot of rework.

I was reading the other day that a whole industry has popped up to help small teams fix their vibe-coded messes. This should really tell you something about the state of the industry.

The reality is that creating everything at once causes the AI to lose architectural consistency. It may solve the same problem different ways in different files. It creates patterns that are contradictory or nonsensical.

To fix this issue, you need to scope down the tasks. Unless you're running some autonomous agent loop that's going to churn through a large detailed requirements document and tasks for hours, you'll need to break things down. Build this component, refactor these tests. Here are the edge cases for this part of the app. The key, as we'll discuss in the next section, is to check the output. It's a lot easier to catch a problem in 50 lines than 2,000.

This problem has actually been mitigated in a lot of ways with spec-driven development. I use Kiro all the time to break down complex features into requirements, design and tasks. That way you can check the plan before the AI writes any code at all.

Too Much Trust

As hinted in the last paragraph, we should not be trusting the output of AI at face value. And of course, it does look convincing at first. When I started using Claude 4.5 Opus, I really thought coding was a solved problem. The code passed my linter, the types looked ok, and it ran well.

But as I started looking at the code in more detail, I saw some issues and edge cases I didn't like. Maybe one day AI will write 100% accurate code, but we still aren't there yet.

There is no question AI makes writing code faster, but you need to spend more time checking the output. In other words, AI compresses generation time, but it often expands verification time.

AI compresses generation time, but it often expands verification time.

I'll be the first to admit, I love writing code, debugging it, finding clever ways to abstract the logic, and seeing it run for the first time. I'm not as big of a fan of code reviews. Something about reviewing other people's code and giving feedback isn't as fun.

However, when AI is doing the writing, reviewing becomes the most important part of your job. For example, on the frontend I've seen things like weak accessibility, brittle logic, weird abstractions, duplicated behavior, and terrible design. Let me emphasize again that AI is not great at design. It's passable if you love purple and you don't mind generic Tailwind-looking apps. You really need to iterate over it several times to get a good outcome.

AI is not great at design!

To help mitigate these problems you can set up tests, and those help, but sometimes the AI games those too. Really though, there is no better way than having a real life breathing human verify everything along the way. You should read the code, understand it, gauge the design, and test the assumptions.

Speed Over Maintainability

As a developer, I love writing code fast. I remember being a young software developer and learning as many hotkeys and keystrokes as I could. I learned Vim so I would never have to touch the mouse, because I knew that every second I touched it, it would slow me down.

With AI writing your code, speed stops being the hard part. I'll never type faster than a large language model can generate. But that's the trap, just because it's fast doesn't mean it's good.
When code gets cheap to generate, bad abstractions get cheaper too.

When code gets cheap to generate, bad abstractions get cheaper too.

AI will over-generate wrappers, components, abstractions and APIs. These AI tools are like eager interns, they want to show off what they can do. But if you don't monitor them closely they'll go off the rails.

And my cognitive load can only handle so much. I remember one of the first codebases I worked on had so many levels of abstraction, it took me 15 minutes of ctrl-clicking into every class and interface to figure out what it was exactly doing. (Yes this was in Java). If you let AI go off, it will do the same thing.

You end up owning code you didn't fully think through or really understand. Your job is to understand what the AI is creating, because six months from now, someone has to maintain it. And that someone is probably you.

Modern Tooling

So where are we at today? Well, we know that models are getting better all the time, and maybe in a few years most of these problems will be solved.

But we are not there yet.

Tools like Kiro have spec-driven development, and other tools have plan mode, checkpoints, and better workflows. But these tools are only as good as the person driving them and there still is no silver bullet. You still need your judgement, your context, and your code review skills to be successful.

Conclusion

If we go back to our two studies at the start, both things can be true at once. Some developers will see productivity gains with AI tools, many others won't. It really comes down to how you use them in your day-to-day life.

You can't vibe code every app, and every app shouldn't be vibe coded. You need the right amount of context, not too little, not too much. You need to scope your asks. You need to become a better code reviewer. And you need to think about whether what the AI created is something you can actually maintain six months from now.

Let me know in the comments if you agree or disagree. Until next time.

The hosting setup nobody talks about anymore

Erik Hanchett — Fri, 20 Feb 2026 00:15:40 +0000

Ever had this problem?

You're building something real, real-time features, background workers, cron jobs, maybe a database or two. You've outgrown the managed platforms, or you're tired of stitching together five different SaaS subscriptions to get what a single server could give you. You want to understand your infrastructure, not just deploy to it. Let me introduce you to the world of Virtual Private Servers (VPS).

A VPS gives you full control over a private server that you yourself manage. Root access, any library or service you want, no execution limits or timeouts. If something breaks, you can SSH in and fix it, no support tickets, no waiting.

That flexibility comes with a tradeoff: you're responsible for the setup, the security, and the maintenance. Managed platforms abstract that away, which is exactly why they're great for simpler use cases. However when your app needs more than what a platform gives you out of the box, or when you just want to learn how the pieces fit together, running your own server is worth the investment.

The purpose of this tutorial is to walk you through that setup end to end. We'll launch a VPS, configure a web server with a CDN, connect it to a domain, and wire up a deployment pipeline. By the end you'll understand every layer of your stack. Let's jump in!

Heads up — this tutorial gets you to a working deployment. If you plan to serve real user traffic, check the Production Hardening section before going live.

Our Setup
Step-by-step
- Launching your EC2 instance
- Installing nginx and Docker
- Configuring AWS Systems Manager
- Setting up the deploy directory and ECR
- Connecting GitHub with OIDC
- Adding the GitHub Action and Dockerfile
- Testing the deployment
- Setting up CloudFront, SSL, and nginx
- Connecting your domain with Route 53
- Adding cache behaviors
Production hardening
Cleanup
Wrapping up

Want a video instead?

Our Setup

Full disclosure, I'm a Developer Advocate for AWS, so I'll be using AWS services in the tutorial as it's what I'm most familiar with. I've been hosting web apps on VPS for years. Feel free to use whatever VPS provider you'd like though.

In this post we are using an Amazon EC2 T3 Micro instance running Ubuntu with an nginx web server. We'll use AWS Systems Manager to help set up a CI/CD pipeline using GitHub Actions. We'll then configure AWS Certificate Manager with Amazon CloudFront and have it connected to our domain with Amazon Route 53! We'll be using a Vue Nuxt 4 application as our web app.

Here is a high level diagram of our final output.

Prerequisites

Don't worry, you won't need to be an EC2 or AWS expert to follow this post. I'll assume you have some basic knowledge of software development, but that's it. To get started make sure you sign up for a free AWS account. I'll also assume you have some sort of application you want to deploy and it's already on GitHub. In this example we'll be using Nuxt with SSR, but you can use whatever you'd like.

Step-by-step

Typically in enterprise applications you might see infrastructure as code (IAC) building and deploying applications on AWS. However, for this tutorial we'll be going directly to the AWS console. I find this the simplest way to get started.

If you're following along with this tutorial, or skimming it through to get ideas, make sure to download a good agentic IDE like Kiro CLI. Kiro CLI can be installed remotely on your server and help you troubleshoot any production issue you have while setting up your service. I used it extensively while researching this blog post, and you should too!

Launching your EC2 instance

To host our application we'll start by creating a new EC2 instance. Log into the AWS Console to begin. Make sure you're on N. Virginia us-east-1 in the top right-hand corner.

Search for EC2 in your AWS Console. It will bring you to a page where you can click Launch instance.

You'll then be brought to a screen with a lot of options. Don't worry, just fill out the name of your server. In this case I chose My-Web-Server and pick an OS image. I really like Ubuntu for beginners so I chose that.

Next you'll need to select an instance type. We want to keep this server cheap (and free-tier eligible), so let's go with the t3.micro instance that has 2 vCPUs and 1 GiB of memory.

What about traffic?
I know what you're thinking, how much traffic can a t3.micro instance handle? While I can't say for sure, we'll be using a Content Delivery Network (CDN) via Amazon CloudFront and caching as much as possible to help absorb traffic spikes. And if you ever outgrow a single instance, AWS can handle it. An Auto Scaling Group (ASG) can spin up additional EC2 instances once a certain traffic threshold is met, an Application Load Balancer (ALB) can distribute incoming traffic across them, and a Web Application Firewall (WAF) can block malicious or "noisy" traffic. We won't be covering those in this post, but I'd recommend reading up on it here if you're interested.

Click the Create new key pair button. This will send you to a popup to add a new key. Add a new key pair name, leave the rest as default and click Create key pair.

It will then ask you to save the key. This is very important. You'll need this key to SSH into your instance later. Save it somewhere safe.

In the network settings you may see a banner that you don't have a default VPC. Click create a new VPC. On the next page leave everything as default and click Create default VPC.

You should now be able to select your VPC, if it's not already selected.

In the Firewall (security groups) make sure to change the Allow SSH traffic from to only allow traffic from your IP. It should be listed in the dropdown.

At the bottom click on Launch instance and you'll see a nice green Success banner. You can click on your instance i-*** to look at it!

In the next window look for the public IP address. Save it!

Now jump into your favorite terminal. Make sure you're in the same directory as the *.pem file you created earlier. You'll need to set some permissions on it. You'll then be able to SSH into your server. Make sure to replace ip-address with the public IP address you saved from the EC2 instance.

chmod 400 your-pem-file.pem
ssh -i your-pem-file.pem ubuntu@ip-address

🎉 Congrats! You've logged in for the first time!

Installing nginx and Docker

Now that we have our EC2 instance up and running, let's do something with it!

First update and then upgrade Ubuntu to the latest. It may ask you to restart some services. You may consider some best practices when working with EC2 as well.

Let's install nginx. This will be our web server that we'll use as a reverse proxy. It listens on port 80 for incoming traffic and forwards it to our Nuxt app running on port 3000.

sudo apt update && sudo apt upgrade
sudo apt install -y nginx

After nginx is installed we'll need to do some configuration. Let's add a new site under the sites-available directory. We'll call it nuxt.

sudo nano /etc/nginx/sites-available/nuxt

Replace it with the code below.

server {
  listen 80;
  server_name _;

  # (we’ll enable this after CloudFront is created)
  # if ($http_x_origin_verify != "REPLACE_WITH_SECRET") { return 403; }

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

This is a basic setup for nginx. Check out the beginners guide for more information on what each option does. The Upgrade and Connection headers are there so WebSocket connections work correctly — handy if your app uses real-time features.

You may have noticed a comment at the top! Don't worry, we'll come back to this later when we set up CloudFront.

To enable the site we have to create a symbolic link from sites-available to sites-enabled. We'll also do a little cleanup and remove the default nginx site and restart it.

sudo ln -sf /etc/nginx/sites-available/nuxt /etc/nginx/sites-enabled/nuxt
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t
sudo systemctl reload nginx

If all goes well we'll get a successful message! If not, double-check the nuxt configuration inside nginx. It's easy to copy something wrong.

At this point we have a few options to handle our Nuxt site. We could just copy the dist folder over, install node, and use something like pm2 to manage the node process. While this works, I find it a little brittle.

Running everything on our EC2 instance requires managing dependencies directly on the system, making it harder to ensure consistent environments between development and production. Docker containers provide a better option. They isolate our dependencies, we can roll back easier, and we'll have more predictable deployments since everything your app needs is packaged together.

To install Docker we'll follow the official Docker docs that recommend using the apt repository.

# Add Docker's official GPG key:
sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

The above code allows us to install Docker under apt. Let's do so.

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Let's verify it's working. Always use sudo to run docker commands.

sudo systemctl status docker
sudo docker run hello-world

Configuring AWS Systems Manager

AWS Systems Manager (SSM) agent should already be installed on the instance; however, in case it isn't, you can use snap to install it. We'll then run a systemctl command to start the service.

SSM is a comprehensive management service that provides a unified user interface for tracking and resolving operational issues across AWS and hybrid cloud environments.

sudo snap install amazon-ssm-agent --classic
sudo systemctl enable snap.amazon-ssm-agent.amazon-ssm-agent.service
sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service

We can verify it's running by checking the status.

sudo systemctl status snap.amazon-ssm-agent.amazon-ssm-agent.service

Back inside the console open up the EC2 instance. Use the Actions menu to modify the attached IAM role.

Make sure to attach the AmazonSSMManagedInstanceCore and AmazonEC2ContainerRegistryReadOnly policies. The AmazonSSMManagedInstanceCore policy allows the EC2 instance to be managed by AWS Systems Manager, enabling remote access and command execution without SSH. The AmazonEC2ContainerRegistryReadOnly policy grants the instance permission to pull Docker images from Amazon Elastic Container Registry (ECR) repositories.

Add the new role and click the Update IAM role button to complete the process.

If you like, you can check Systems Manager in the console to see the EC2 instance connected. Search for Systems Manager -> Fleet Manager and you'll see the instance connected.

Setting up the deploy directory and ECR

For our app deployment, we'll be hosting our images on ECR. We'll need a script that will be triggered by SSM to pull the latest tag and run it.

To do this we'll create a new directory.

sudo mkdir -p /opt/nuxt-app
sudo chown ubuntu:ubuntu /opt/nuxt-app
cd /opt/nuxt-app

Let's create the docker-compose.yml file inside the /opt/nuxt-app folder. Don't worry about the image, we'll replace that later. Also go ahead and create an empty .env file now — Docker Compose will fail if the env_file path doesn't exist.

touch /opt/nuxt-app/.env

services:
  nuxt:
    image: REPLACE_LATER
    ports:
      - "127.0.0.1:3000:3000"
    env_file:
      - /opt/nuxt-app/.env
    restart: unless-stopped

We'll need to install the AWS CLI so we can pull down the deployed image from ECR. Install the latest version from the docs.

sudo apt install unzip
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

As always, make sure it works by running the commands below.

aws --version
aws sts get-caller-identity

This will verify that AWS CLI is working and that the permissions we set earlier in the IAM policy are there.

Let's now configure ECR!

Inside the AWS console head to ECR → Repositories → Create repository.

Add a name and create it. In this case I'll use the postfix ec2/host!

Make sure to write down the full ECR repository name for later.

Connecting GitHub with OIDC

Now let's set up an OIDC provider for GitHub. Later we'll create a GitHub Action that will need access to our AWS account to work. To get more information on how OIDC providers work in GitHub, feel free to check out this guide.

Inside the AWS console head to IAM → Identity Providers → Add provider.

On this page make sure to select OpenID Connect, use the URL https://token.actions.githubusercontent.com and the audience as sts.amazonaws.com. It should look like the screenshot below!

Now let's create a new role for this.

Inside the AWS console head to IAM → Roles → Create role.

Create a new IAM role connecting to this provider. Choose Web identity and make sure to use the new identity provider you just created. Type in the GitHub organization and repository. If you like, you can also select the branch.

Click next a few times and create the role! We aren't done yet though — we need to make sure this role has permissions to ECR so the GitHub Action can trigger our deployment workflow.

Under permissions click the Create inline policy.

Select JSON and copy and paste this in.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ECRAuth",
      "Effect": "Allow",
      "Action": "ecr:GetAuthorizationToken",
      "Resource": "*"
    },
    {
      "Sid": "ECRPush",
      "Effect": "Allow",
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:CompleteLayerUpload",
        "ecr:InitiateLayerUpload",
        "ecr:PutImage",
        "ecr:UploadLayerPart",
        "ecr:BatchGetImage"
      ],
      "Resource": "arn:aws:ecr:YOUR-REGION:YOUR-ACCOUNT-ID:repository/YOUR-REPO-NAME"
    },
    {
      "Sid": "SSMRunCommand",
      "Effect": "Allow",
      "Action": "ssm:SendCommand",
      "Resource": [
        "arn:aws:ssm:*:*:document/AWS-RunShellScript",
        "arn:aws:ec2:YOUR-REGION:YOUR-ACCOUNT-ID:instance/i-xxxxxxxxxxxxxxxxx"
      ]
    }
  ]
}

Make sure to update the instance with your instance ID. You can find that in your EC2 console. It starts with i-. You also need to update YOUR-REGION (e.g. us-east-1) and YOUR-ACCOUNT-ID with your account ID. Also update YOUR-REPO-NAME with your ECR repo name. In my case I called it ec2/host.

⚠️ Setting up for production
We're using AWS-RunShellScript here which lets the CI pipeline run any shell command on your instance. That's great for a tutorial, however a compromised GitHub Actions workflow or malicious PR could achieve remote code execution on your host. In production, create a custom SSM document that only runs your deploy script. That way even if the GitHub role is compromised, it can only trigger the specific deployment, not arbitrary commands on your box. A minimal custom document looks like this:
{
  "schemaVersion": "2.2",
  "description": "Deploy Nuxt app",
  "mainSteps": [{
    "action": "aws:runShellScript",
    "name": "deploy",
    "inputs": {
      "runCommand": ["sudo bash /opt/nuxt-app/deploy.sh"]
    }
  }]
}
Then reference your custom document name in the GitHub Action instead of AWS-RunShellScript.

Click create, name it github-deploy-nuxt, and you are good to go.

Make sure to copy the ARN for later!

Now inside our GitHub repo let's add the GitHub variables.

Open up your GitHub repo and head to Settings → Secrets and Variables → Actions → Variables.

Add five new environment variables. These will be used in our GitHub Action.

Add each variable one by one.

AWS_REGION  us-west-2
AWS_ACCOUNT_ID  your account id
ECR_REPO    ec2/host
INSTANCE_ID i-xxxxxx
AWS_DEPLOY_ROLE_ARN role ARN from above

Adding the GitHub Action and Dockerfile

For the deployment to work successfully we need to set up a GitHub Action that will deploy our app. Let's do that now.

In your repo add a new .github/workflows/deploy.yml file. This will be run whenever a push occurs to main.

name: Deploy Nuxt SSR

on:
  push:
    branches: ["main"]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ vars.AWS_DEPLOY_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}

      - name: Login to ECR
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build and push Docker image
        run: |
          IMAGE_URI=${{ vars.AWS_ACCOUNT_ID }}.dkr.ecr.${{ vars.AWS_REGION }}.amazonaws.com/${{ vars.ECR_REPO }}

          docker build -t $IMAGE_URI:prod .
          docker push $IMAGE_URI:prod

      - name: Deploy via SSM
        run: |
          COMMAND_ID=$(aws ssm send-command \
            --instance-ids "${{ vars.INSTANCE_ID }}" \
            --document-name "AWS-RunShellScript" \
            --parameters '{"commands":["sudo bash /opt/nuxt-app/deploy.sh"]}' \
            --query "Command.CommandId" --output text)

          aws ssm wait command-executed \
            --command-id "$COMMAND_ID" \
            --instance-id "${{ vars.INSTANCE_ID }}"

This action will assume our AWS credentials based on the GitHub role we just created. It will then build a Docker image and push it to ECR. We'll then trigger SSM to run our script that will complete the deployment.

For us to build our Docker image, we'll need a Dockerfile in the root of our repo. Head to the repo and in the root add a new Dockerfile. This will build our Nuxt application.

# --- build stage ---
FROM node:20-bookworm-slim AS build
WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .
RUN npm run build

# --- runtime stage ---
FROM node:20-bookworm-slim AS runtime
WORKDIR /app
ENV NODE_ENV=production

COPY --from=build /app/.output ./.output

EXPOSE 3000
CMD ["node", ".output/server/index.mjs"]

We'll also need a .dockerignore file.

node_modules
.nuxt
.output
.git
.gitignore
.env
.env.*
*.pem
*.md
.vscode
.idea

Before we get too far, let's test it out.

Testing the deployment

We are going to test our deployment, but first let's temporarily open up port 3000 on our EC2 host. We can then connect to the IP address later to see if our deployment works.

Inside the AWS console head to EC2 → Security Groups → Inbound rules.

Click on the security group.

Edit inbound rules and add your IP address on port 3000 on Custom.

Let's head back to the Docker Compose file again. This is important — before you push anything to GitHub, update the docker-compose.yml with your real ECR image URI. If you skip this step the deploy will fail because Docker won't know what image to pull. Add in the ECR image name and set the port to 3000. Make sure to add the :prod tag.

services:
  nuxt:
    image: <account-id>.dkr.ecr.us-east-1.amazonaws.com/ec2/host:prod
    ports:
      - "3000:3000"
    env_file:
      - /opt/nuxt-app/.env
    restart: unless-stopped

For my app I use several secrets; however, as you can see from earlier, our Docker ignore file excludes .env files (for good reason). Create a new .env file with the secrets. This will be injected into our docker image later.

sudo nano /opt/nuxt-app/.env

Next is the deploy script!

nano /opt/nuxt-app/deploy.sh

The GitHub action will run this on every deploy to main.

#!/bin/bash

cd /opt/nuxt-app

aws ecr get-login-password \
--region YOUR_REGION | \
docker login \
--username AWS \
--password-stdin YOUR_ACCOUNT_ID.dkr.ecr.YOUR_REGION.amazonaws.com

docker compose pull
docker compose up -d
docker image prune -f

⚠️ Don't use .env files in production
Plaintext .env files on disk have no rotation, no audit trail, and no access control. For production, use AWS Secrets Manager or Systems Manager Parameter Store (SecureString) to manage application secrets and pull them at runtime. The .env approach shown here is suitable for development and tutorials only. You could also set up a blue/green deployment — spin up the new container, health-check it, then swap traffic only if healthy. For the purpose of this tutorial though, we'll keep it simpler.

Replace the YOUR_ACCOUNT_ID with your account id and YOUR_REGION with your region.

Then make it executable.

chmod +x deploy.sh

We are finally ready to try it all out! Push all your changes from your repo to GitHub and check the Actions tab at the top and see it deploying!

Troubleshooting
If you see errors at this point, you'll need to double-check your GitHub role and that everything is connected. This might be a good time to use Kiro to help troubleshoot the problem!

We can check if everything works by loading up port 3000 with the public IP address of the EC2 instance.

Go to http://<your-ec2-ip-address>:3000

Congrats 🥳! You now have a working deployment pipeline and your container is working!

Setting up CloudFront, SSL, and nginx

Our pipeline is working; however, we need to revert the ports change we made in the docker-compose.yml file.

Change back the /opt/nuxt-app/docker-compose.yml to

services:
  nuxt:
    image: xxxx.dkr.ecr.us-east-1.amazonaws.com/ec2/host:prod
    ports:
      - "127.0.0.1:3000:3000"
    env_file:
      - /opt/nuxt-app/.env
    restart: unless-stopped

Then apply it

cd /opt/nuxt-app
sudo docker compose up -d

⚠️ Remove port 3000 from your security group now. It exposes your raw application server to the internet, bypassing nginx. This was only needed for testing — don't leave it open.

Let's see if it works on the normal port 80.

Open up http://<your-ec2-ip-address>

If all goes well you should be seeing your website! 🎉

But now we need CloudFront to add a Content Delivery Network (CDN) that will cache our static assets globally and improve performance for users worldwide. CloudFront also provides additional security features and helps protect our origin server from direct access.

Let's assume you already have a domain in Route53.

Let's request a public certificate so we can add in SSL.

In the AWS Console head to Certificate Manager → switch region to us-east-1 → Request certificate → Request a public certificate .

Then add your fully qualified domain (e.g. yourdomain.com). And add another for www (e.g. www.yourdomain.com).

Leave everything else defaulted and click Request. Wait a few minutes for the certificate to be issued.

Inside the AWS Console head to CloudFront and create a new distribution.

Click Create Distribution. Choose the free plan. Make sure to enter the distribution name, the domain name, and the Domain to serve (www).

On the next page choose Other. For origin, type in the public DNS of the EC2 instance. You may need to go back to grab it.

Set the origin settings to customize origin settings. Then set an X-Origin-Verify header with a random secret you create.

Why this header matters
The CloudFront Origin Header is extremely important. This ensures that your origin server can only be accessed through CloudFront and not directly from the internet, providing an additional layer of security.

⚠️ Use HTTPS to your origin in production
We're using HTTP for the origin protocol here since CloudFront handles HTTPS for your users. However, the X-Origin-Verify shared secret is transmitted in plaintext over this connection. Even with the security group locked to the CloudFront prefix list, traffic between CloudFront edge nodes and your EC2 instance traverses the public internet and could be intercepted. For production workloads, install a certificate on your instance (a self-signed cert works fine since CloudFront doesn't validate origin certs by default, or use Certbot for a free Let's Encrypt certificate), switch nginx to listen on 443, update CloudFront's origin protocol to HTTPS-only, and move your prefix list security group rule from port 80 to 443. This encrypts the entire path and keeps the shared header as a defense-in-depth measure rather than your primary access control.

For cache settings, choose "CachingDisabled" as we'll configure specific caching behaviors for different content types after creating the distribution.

For the Web Application Firewall (WAF) settings, don't make any additional changes.

On the settings page, select the SSL certificate you created earlier from the dropdown menu. Make sure both your domain and www subdomain are covered.

Review all your configuration settings and click "Create distribution". CloudFront will take several minutes to deploy globally — you'll see the status change from "Deploying" to "Enabled" when it's ready.

After it's enabled, add a new behavior. Click Create behavior. Fill out the Path pattern as /_nuxt/*, set the Origin and origin groups dropdown to the EC2 instance. Make sure to set the Viewer protocol policy to Redirect HTTP to HTTPS and set the Allowed HTTP methods to GET, HEAD.

It should look like this at the end

Now that CloudFront is in place, let's update the nginx configuration with the new secret key we created earlier.

sudo nano /etc/nginx/sites-available/nuxt

server {
  listen 80;
  server_name _;

   if ($http_x_origin_verify != "REPLACE_WITH_SECRET") { return 403; }

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

Replace the REPLACE_WITH_SECRET with the variable you set up in CloudFront.

Then reload nginx.

sudo systemctl reload nginx

Now if you test the origin you should get a 403 forbidden.

Go to http://<your-ec2-ip-address>

Lock down port 80
For an extra layer of security, go to your EC2 security group and delete the existing port 80 inbound rule, then add a new one with the source set to the AWS-managed prefix list com.amazonaws.global.cloudfront.origin-facing. This restricts port 80 so only CloudFront's network can reach your instance. Combined with the origin verify header, you now have two layers of protection on your origin.

🔥 We are getting one step closer!

Connecting your domain with Route 53

Now you need to connect your CloudFront distribution to your domain through Route53.

Go to Route53 in the AWS console and navigate to your hosted zone for your domain. Click "Create record" to add a new A record that will point your domain to the CloudFront distribution.

Make sure you add a record. Choose Alias and then choose Alias to CloudFront distribution from the dropdown. Select your CloudFront distribution from the list. Leave the Record name blank for the root domain.

Add another A record, but this time for the www subdomain.

It might take a few minutes for DNS propagation to complete, but your site should be accessible at your domain shortly after creating the A records.

You can test the CloudFront distribution directly using its domain name while waiting for DNS to propagate. Once everything is working, visit your domain and you should see your site served securely over HTTPS!

Go to https://<your-domain> 🎇

You can even open Chrome DevTools and check the Network tab to see CloudFront cache hits in the response headers.

Adding cache behaviors

If you'd like, we can add additional caching to our CloudFront distribution.

/favicon.ico
/robots.txt
/sitemap.xml
/images/*

Each of these files can have their own caching rules. Static assets can be cached for longer periods, while you might want to disable caching entirely for server-side rendered (SSR) routes in Nuxt to ensure dynamic content is always fresh.

To add these behaviors, go back to your CloudFront distribution and create new behaviors for each path pattern, adjusting the cache settings based on how frequently the content changes.

Once everything is working properly, it's also a good security practice to remove SSH access from your EC2 instance's security group. Since we set up AWS Systems Manager earlier, you can still connect to your instance anytime through the SSM Session Manager in the AWS console — no SSH key needed, no port 22 open to the internet. Just head to your EC2 security group, delete the inbound rule for port 22, and save.

Production hardening

What we've built so far is a solid working deployment — but it's tutorial-grade. Before serving real user traffic, here are the things you'll want to tighten up.

Secrets management. Replace the flat .env file with AWS Secrets Manager or SSM Parameter Store (SecureString). This gives you rotation, audit trails, and fine-grained access control instead of plaintext on disk.

Origin encryption. Install a TLS certificate on your instance (self-signed works since CloudFront doesn't validate origin certs by default, or use Certbot for a free Let's Encrypt certificate), switch nginx to listen on 443, and set CloudFront's origin protocol to HTTPS-only. Then move your prefix list security group rule from port 80 to 443. This encrypts the hop between CloudFront and your origin so the X-Origin-Verify header can't be sniffed in transit.

Lock down SSM. Replace AWS-RunShellScript with a custom SSM document that only runs your deploy script. This limits the blast radius if your GitHub Actions role is ever compromised. See the example earlier in this post.

Security group hygiene. Remove SSH (port 22) access entirely — you have SSM Session Manager for shell access. Restrict port 80/443 ingress to the CloudFront managed prefix list (com.amazonaws.global.cloudfront.origin-facing) so only CloudFront can reach your origin.

Monitoring and detection. Set up CloudWatch alarms for CPU, memory, and disk usage. Enable VPC Flow Logs to capture network traffic metadata. Consider enabling AWS WAF on your CloudFront distribution to filter malicious requests. Without these, a breach or resource issue could go undetected indefinitely.

Zero-downtime deploys. Set up a blue/green deployment — spin up the new container, health-check it, then swap traffic only if healthy. Your deploy script can pull the new image, start it on a different port, verify it responds, then update nginx and stop the old container.

Scaling. If you outgrow a single instance, add an Auto Scaling Group with an Application Load Balancer to distribute traffic across multiple instances.

Cleanup

If you're done experimenting and want to tear everything down, here's the order I'd go in:

Head to Route 53 and delete the A records you created for your domain and www.
Go to CloudFront, disable your distribution, wait about 5 to 10 minutes, then delete it.
Delete the ACM certificate in Certificate Manager.
Head to ECR and delete your repository.
Terminate your EC2 instance and delete the security group and key pair you created.
Clean up the IAM roles and the OIDC identity provider for GitHub.

Going in this order avoids dependency issues, CloudFront needs to be disabled before you can delete the certificate, and Route 53 records need to be removed before disabling the distribution.

Wrapping up

Remember the problem we started with? Too many subscriptions, serverless timeouts, and no real control over your stack. We just solved all of that with a single EC2 instance.

Here's what we built: a t3.micro instance running Ubuntu with nginx as a reverse proxy, Docker for containerization, a CI/CD pipeline with GitHub Actions and ECR, CloudFront as our CDN with SSL via Certificate Manager, and Route 53 pointing our domain to it all.

This gives you a working foundation you can build on. Check the Production Hardening section above to close the gaps before serving real traffic — but the hard part is done. You own your stack, you understand every piece of it, and you can evolve it on your terms.

If this helped you out, drop a comment below and let me know what you're deploying. Until next time!

From Chat to Specs: A Deep Dive into AI-Assisted Development with Kiro

Erik Hanchett — Tue, 15 Jul 2025 16:57:38 +0000

This article was originally published on the Kiro blog from Ryan Yanchuleff.

As developers, we've all been there. You have a brilliant idea for a feature or application, you fire up your favorite AI coding assistant, and then... you spend the next hour going back and forth, refining requirements, clarifying edge cases, and watching your context window fill up with exploratory conversations before you even write a single line of code.

Kiro, a new IDE, fundamentally changes how we approach AI-assisted development through Spec-Driven Development.

Limitations of current AI coding assistants

Limitations of current AI coding assistants tend to follow a predictable and inefficient pattern. When a developer provides a high-level prompt, the AI immediately jumps into code generation, often before fully understanding the requirements. This premature action leads to a cycle where the developer must repeatedly clarify their intentions with "actually, I meant..." statements, as the initial requirements weren't sufficiently clear. As this exploratory dialogue continues, the context window becomes increasingly cluttered with back-and-forth discussions, leaving limited space for the final code generation. This constrained context space ultimately impacts the quality and completeness of the final output, making the entire process less efficient than it could be. This approach treats the LLM as a code generator first, when it should be considered a thinking partner throughout the entire development lifecycle.

Spec-driven development: Bridging design intent and implementation

If you're working on a challenging feature, Kiro serves as your intelligent sounding board to help you understand your codebase, define your problem clearly, and reach a quality solution efficiently. You can collaborate with Kiro on creating concise specifications that include clear requirements, system architecture, tech stack considerations, and implementation approach. Kiro helps make all requirements and constraints explicit, then uses these specifications as context to complete tasks with fewer iterations and higher accuracy. This is the power of spec-driven development. Let's dive deeper into some of the key benefits of Kiro's approach:

1. Understand your existing codebase

Before starting new development, Kiro analyzes your existing code and generates three foundational documents: structure.md (codebase architecture), tech.md (technical stack and patterns), and product.md (business context and requirements). This gives you and your team a clear baseline understanding that informs all subsequent specification work. Existing codebases can now take advantage of this new paradigm.

2. Analyze and plan your project

When you provide a project prompt in spec mode, Kiro's AI doesn't immediately start coding. Instead, it performs deep analysis to understand your requirements, identifies potential challenges, and creates comprehensive planning documents.

3. Generate comprehensive planning documentation

From a simple prompt, Kiro creates detailed specification files including:

Requirements Analysis - Breaking down your prompt into specific, actionable requirements
Technical Design - Architecture decisions, technology choices, and implementation approach
Task Breakdown - Granular development tasks with clear acceptance criteria

4. Collaborate with AI effectively

Kiro saves specification files in your project directory as readable markdown files. You can review, edit, and refine them before any code is written. This creates natural checkpoints for collaboration with team members or stakeholders.

5. Maximize coding context and efficiency

When it's finally time to write code, Kiro references these specification files rather than cluttering your context window with exploratory conversation. This means maximum context space is available for the actual coding task.

The power of spec-driven development

Spec-driven development delivers key advantages that fundamentally improve how teams design, build, and maintain software. Rather than treating planning as overhead, it becomes your competitive advantage. Here's how this approach transforms the development process:

Catch problems before they're expensive

Rather than discovering requirements issues mid-development, Kiro identifies and resolves ambiguities upfront. This prevents costly rewrites and provides alignment before coding begins.

Stay in control of your project's direction

The specification phase creates natural pause points where humans can review, modify, and approve the direction before resources are invested in implementation.

Iterate without losing your progress

If you make a mistake in defining your requirements, no problem. You can modify the specification files and regenerate the implementation plan without losing your entire conversation history.

Keep your AI focused on what matters

By externalizing the planning phase to files, Kiro keeps the active context focused on the immediate coding task, leading to higher quality code generation.

Enable seamless team collaboration

Specification files serve as living documentation that team members can review, comment on, and contribute to using standard development workflows.

Build institutional knowledge

Every decision and requirement is documented, creating a clear audit trail of why certain technical choices were made and preserving context for future team members.

Let’s see Kiro specs in action

The best way to understand spec-driven development is to see it in practice. Whether you're starting fresh or working with an existing codebase, Kiro's systematic approach enables you to build on a solid foundation. Here's how a typical workflow unfolds, from initial concept to implementation-ready specifications.

Step 1: Initiating your project

Before diving into new features, establish context for your project:

User: "Set up steering for this project"

Kiro analyzes your existing codebase and generates three foundational documents:

structure.md - Current architecture, key components, and code organization
tech.md - Technology stack, patterns, and technical constraints
product.md - Business context, existing features, and user workflows

This gives you a clear baseline understanding of what you're building upon.

Step 2: Generating your project specs

Now start laying out the details for the project that you want to build.

User: "I want to build a task management app for small teams with real-time collaboration features"

This is where the magic of spec-driven development becomes apparent. Rather than jumping straight into framework selection or database design, Kiro takes a step back to fully understand what you're trying to accomplish. It considers your prompt in the context of the steering documents, identifying how this new feature fits within your existing architecture and constraints.

Kiro creates a series of documents in sequential order, building from requirements through to actionable tasks:

requirements.md - Detailed feature breakdown including user stories and acceptance criteria
design.md - Architecture and technology decisions including frameworks, architecture diagrams, and structure
tasks.md - Development phases and tasks to be executed in a sequential order

Step 3: Reviewing and refining

You review the specifications, perhaps adding:

## Additional Requirements
- Integration with Slack for notifications
- Mobile-responsive design priority
- GDPR compliance considerations

Step 4: Informed Development

Now when Kiro begins coding, it references these comprehensive specifications rather than trying to infer requirements from conversation history. Every implementation decision is grounded in documented requirements and design choices.

The future of development is here—and it starts in the specs

Spec-driven development represents a shift from reactive coding to proactive specification that isn't just a workflow improvement—it's a fundamental evolution in how we partner with AI to build software. Instead of treating AI as a sophisticated autocomplete tool, spec-driven development positions it as your strategic thinking partner, helping you make better decisions before they become expensive to change. The result? Faster development cycles, higher quality code, fewer surprises, and documentation that actually stays current because it's integral to the process, not an afterthought. The next time you have a feature to build, try leading with specification instead of code. Your future self (and your teammates) will thank you for the clarity, and you might just discover that the best code is the code you plan before you write.

Ready to experience the difference? Kiro is now available and free during preview with generous usage limits. Download it and get started today!

What I Learned from Vibe Coding

Erik Hanchett — Wed, 26 Mar 2025 21:13:50 +0000

You may have heard this term called “vibe coding”. It’s a new way of thinking about creating software using AI. It was coined by Andrej Karpathy, and he describes vibe coding as “Giving into the vibes, embrace exponentials, and forget that code even exists”. Karpathy uses an AI coding assistant and he adopts the philosophy of “accepting all”, assuming the AI coding assistant will write and fix the software he’s creating.

While this way of coding sounds tempting, does it produce accurate enough results given today’s large language model limitations (LLM) and the overall changing landscape? Can you vibe code a complete application without issues? Can you have it create tests, and how does it handle inconsistencies with design? Is this a fad or a real long term strategy developers should learn and adopt?

I had these same questions too, so I decided to create an experiment for myself. Without any prior knowledge I wanted to update my old, and frankly out of date personal blog.

I’d vibe my way into a new, and hopefully better looking and functional website. The guard rails I set for myself was that I could NOT go into the code and make any changes. Everything would have to be done by using a prompt and the coding assistant. Additionally, I would try my best to assume no knowledge of web development. Spoiler, I broke the second rule - we’ll chat more about that later.

If you'd like to follow along, I created a full video of the experience!

Let's jump into how to set up this experiment!

Full disclosure - I'm a Senior Developer Advocate for AWS!

Setup

For this experiment I am using Amazon Q CLI as my coding assistant. This command line interface (CLI) tool will be my agent, and I’ll prompt it to create my new personal website. I am a huge fan of CLI tools, and this will work perfectly for my experiment. If you'd like to follow along, Q CLI is easy to install and supports several different operating systems, including my favorites MacOS, WSL and Linux. You can even set it up over SSH if needed. Also, don’t forget to sign up for Builder ID, it’s a free to sign-up and you’ll need it to sign in with the CLI.

To speed things up a bit, I created a brand new application using Nuxt 3 with Tailwind CSS 4. I followed the procedures on the Nuxt installation guide and then chose the Nuxt UI installation that includes Tailwind CSS 4. I cleared out the starter files and began with a simple index.vue file to start.

Here is my starting point.

It’s worth mentioning that even though I used Nuxt which uses Vue.js, I’m almost certain this experiment would have worked the same way or even better with React, Angular, or even Svelte.

Building My Personal Website

One thing I know about prompting, is that you should try to be specific. So I started with a basic prompt.

This prompt was explicitly written to generate a personal website, with spring colors, and animations. I then listed out that I wanted a blog, contact me, profile picture and bio page. For good measure I added in that I was using Tailwind CSS 4 and it was configured already. Although not necessary I always try to be polite with my prompts, and I was sure to include please and thank you. 😊

After entering the prompt in and hitting enter I noticed that Q CLI read my directory and summarized what it was going to do. This was nice to see that things were going in the right direction.

At this point Q CLI started creating pages and I started blindly accepting ‘y’ for each change.

It’s worth noting you can set Q CLI to accept all changes by using the /acceptall configuration or -a argument when you begin q chat. However, in this example I decided to just manually accept all changes.

Missing image

After a few times of pressing ‘y’ on my keyboard, and accepting all the changes, I noticed a small issue with the bio.vue page that was just created.

No problem! I told Q to fix the file, and it continued on it’s way!

Nuxt config update

As I was continuing on confirming all changes a message came up to confirm a new update to the nuxt.config.ts file.

One of my goals for this experiment was to assume no knowledge of web development and blindly "accept all" to all changes. However, to save time, and to fix an obvious issue, I stopped Q CLI when it tried to make modifications to the nuxt.config.ts file. One of the primary responsibilities of this file is to add modules. Q CLI wanted to remove my nuxt-ui module which would have broken all my Tailwind CSS in the app.

Looking at the output, I believe Q CLI was confused and wanted to add in some PostCSS configuration, which is more often used with Tailwind CSS 3. To be safe here I typed no here and reminded Q CLI that I was using a module and that I didn’t need this configuration. It continued on without issue, and did not update this file.

First iteration of website

After a few more minutes of accepting more changes and fixing the minor mistakes mentioned earlier, my new personal website appeared! 🎉

It included most of the features I was expecting including a featured projects section. One thing that was not working was the blog section. So I went back and asked for it to create it.

Within a few minutes it added an interactive blog. It even added in pagination, tags, and search functionality!

Overall it did a good job with the blog. It created separate dynamic routes for each page, and the tag filtering and search worked as well. The only concerns I had were with a few small design issues with mobile responsiveness.

Adding more updates

I continued on for another few minutes cleaning up the design. I asked Q CLI to update all the place holder images with images from Unsplash. I then had it clean up a few minor visual issues. This definitely made the site look a little cleaner.

I then had it commit the changes into it’s own branch using git. It's important having an easy way to roll back or change between commits. As an added bonus from doing this, Q CLI started committing all my changes without me having to ask after every update.

Testing

Testing is really important for any software you create. It’s a great way to ensure you don’t break anything while making updates to a code base. When working with AI coding assistants this is even more important. By creating tests AI agents can check that their changes didn’t break anything, and if they do fix the issue.

To help test this philosophy I asked Q CLI to make some simple tests for each page in the application. With in seconds it installed vitest, and test-utils and began creating tests for each page.

One thing surprised me is that after creating all these tests, they didn’t pass. Q CLI went back and made changes 3-4 times until every test passed. I was impressed that it was able to self correct itself without additional prompting. Afterwards I quickly checked the tests out and they looked fine for this project.

Conclusion

The goal was to vibe code, and this was a success. I was able to create a profesional, nice looking, personal website that featured a blog, contact page, and bio. I never once had to fix anything in the code myself, and I was able to prompt my way through all the errors and problems that occurred.

That said, if I hadn't known anything about web development, it would have been a different experience. Q CLI got Tailwind CSS 3 and 4 mixed up and it would have caused an issue if I blindly accepted all the change. On the other hand, I’m confident I could have prompted my way to fix it, it would have just taken longer. This issue may be certainly fixed by the time you read this, but just realize when you are working with the latest libraries, your favorite coding assistant may not be up to date.

Is vibe coding a fad? I don’t think so. This is a perfectly valid way of creating software, and as LLMs and AI coding assistants get better the number of corrections or errors will decrease. Vibe coding is certainly not a substitute for a real software developer, and I can imagine as you try to vibe code into a much more complicated app, it won’t work as well. You’ll always need to have a developer to help out where the LLM lacks. As for me, I’ll be looking to update my personal site with this new code soon! After I vibe code a few more updates. 😉

How To Create A Fullstack TypeScript App Using AWS Amplify Gen 2

Erik Hanchett — Fri, 31 May 2024 19:06:37 +0000

AWS Amplify Gen 2 is a brand new way to create fullstack applications on AWS. In this tutorial, we’ll explore how to get started creating a fullstack TypeScript application with Next.js! We’ll add storage and then connect it to our Amplify connected UI component library to upload files.

With Gen 2 we focused our efforts on creating a great developer experience. We wanted to make sure that you could focus on your frontend code instead of worrying about setting up your backend infrastructure. In this new version we created a brand new TypeScript safe DX that supports fast local development, and is backed by AWS Cloud Development Kit (CDK).

We recently released Gen 2 for general availability. Feel free to let us know what you think and leave a comment below.

With that said, before you get started makes sure your familiar with TypeScript, VSCode and Git. You'll also need a GitHub account and make sure Git is installed locally on the command line. We'll be using Next.js, however you don't need to be an expert in React to try out this tutorial.

What Are We Building Today?

We will be creating an app that allows you to create todos with pictures. You’ll be using the Amplify Next Starter template and have it deployed to the AWS Amplify console. We'll create and connect to AWS AppSync, our managed GraphQL service, and use Amazon Cognito, our customer identity and access management service, to authenticate and authorize users. Additionally, we'll use S3 for file storage of our images.

In this tutorial I'll walk you through step-by-step on how to create a new AWS Amplify Gen 2 app using the console, cloning that app, opening it in VSCode and adding in some additional features. We'll then deploy our changes back to the Amplify Gen 2 console to our hosted environment.

Setup

We need to first have an AWS account ready. If you are not signed up, try out the AWS Free Tier! This will give you plenty of free resources to try out AWS and many of it's services. Keep in mind, all the services we'll work with today are on-demand and you'll only get charged when you are using them.

We will be using the Next.js Amplify starter template as described in the Quickstart guide. Clone the repository using the Amplify Next.js Template into your own Github account to get started.

Afterwords, sign into the AWS management console. Search at the top for AWS Amplify, and click it.

In the Amplify Console choose Create new app.

Select GitHub as the Git provider.

In the next page you'll see a popup asking to connect to your Github account. This will give Amplify access to your account so it can connect to the Next.js repo you just created in the previous step from the starter template.

Select your app from the App name field and click next. If you don’t see your app click the Update Github permissions button and re-authorize with Github. On the next page leave all the default settings and click next. On the last page click Save and deploy. Amplify will now begin to deploy your new app!

The deployment may take several minutes. It will host your Next.js frontend and create infrastructure for your Amazon Cognito and AWS AppSync service backend. We’ll discuss this more later, and how we can make updates and changes to it. Until then, let's jump into VSCode and setup the frontend!

Updating the frontend

Let's take a look at our app, and make some updates.

Open up your favorite terminal and clone the Github repo you just created in the previous section.

git clone <The_Copied_Githhub_URL>

Open up VSCode to that cloned project and open a terminal to the project’s root folder. Run the following command.

npm i @aws-amplify/ui-react-storage

This will install the Amplify UI component library. We'll use this later to add a file uploader, called Storage Manager, to our frontend to help with uploading pictures.

If you look at the app folder structure you'll notice an amplify folder. This folder houses all the resources and files that will help us connect to our backend.

By convention, the starter template will create an Amazon Cognito instance, and configure it for email login. The configuration for this will be in the resources file at amplify/auth/resource.ts. For more information on the auth resource please checkout the docs.

It also creates an AWS Appsync instance with a Todo schema in the amplify/data/resource.ts file.

Update the data/resource.ts to match the code below. The only difference is we are adding a new key to the model.

// amplify/data/resource.ts

const schema = a.schema({
  Todo: a
    .model({
      content: a.string(),
      key: a.string(),
    })
    .authorization((allow) => [allow.publicApiKey()]),
});

export type Schema = ClientSchema<typeof schema>;

export const data = defineData({
  schema,
  authorizationModes: {
    defaultAuthorizationMode: "apiKey",
    apiKeyAuthorizationMode: {
      expiresInDays: 30,
    },
  },
});

This schema does a few things.

Adds a new Todo model with all the resolvers needed CRUDL (Create, Read, Update, Delete, List) and connects it to a new DynamoDB instance.
The Todo model will have a content and a key fields - both are strings.
Adds public authorization rules so all users can create, read, update and delete, as long as they have the public api key.
Sets a default authorization mode of apiKey and sets the expiration for 30 days. This is the public key.
Exports a Schema that can be used by the frontend to ensure type safety end-to-end.

This resource data pattern is very powerful by allowing the user to completely configure the backend data schema all in code using TypeScript.

For the sake of this tutorial we will leave the default resource file unchanged for auth in the amplify/auth/resources.ts file.

Adding Storage

We need to be able to upload images and retrieve them. We can do this using the Amplify Storage Category.

Create a new folder at amplify/storage. Inside this folder create a resource.ts file. Copy the following code.

// amplify/storage/resource.ts

import { defineStorage } from "@aws-amplify/backend";

export const storage = defineStorage({
  name: "todosStorage",
  access: (allow) => ({
    "media/*": [
      allow.guest.to(["read", "write", "delete"]), // additional actions such as "write" and "delete" can be specified depending on your use case
    ],
  }),
});

This will create a public bucket for users to upload our images too. Users will be able to upload images to the media folder and they’ll have access to read, write, and delete them.

Next, let’s add this storage resource to our backend.ts file. Open the backend.ts file and add a new storage import. The complete file is below.

//amplify/backend.ts

import { defineBackend } from "@aws-amplify/backend";
import { auth } from "./auth/resource.js";
import { data } from "./data/resource.js";
import { storage } from "./storage/resource.js";

defineBackend({
  auth,
  data,
  storage,
});

All our backend resource should be ready to go!

Starting the Sandbox

To test locally we'll create a new ephemeral environment using Amplify tooling.

If you've never setup AWS on the command line you'll need to run a few commands here to make sure your environment can connect to your account. Please follow the Set up your AWS Account section section in our docs before continuing on.

npx ampx sandbox

This command will create an environment in AWS based on the resources you configured in your amplify folder. In this case it will create a Amazon Cognito, S3 Storage and AWS AppSync service. At any time you can stop this command, and it will delete all the resources it just created.

It will also create an amplify_outputs.json file in the root of your app. We'll need this file in the next section to setup our client aws-amplify library so it can talk to the backend services.

This will take a few minutes to run, after it completes continue onto the next section.

Update page.tsx

The starter template has a built in todos app in it. Let’s modify the page.tsx file so we can upload files and connect them with our todos.

Inside the page.tsx app add an import for StorageManager, StorageImage and to our Amplify UI components library.

// app/page.tsx
...

import { StorageImage, StorageManager } from "@aws-amplify/ui-react-storage";
import { Card, Flex, Text, Button } from "@aws-amplify/ui-react";

The UI components, Card, Flex, Text and Button are used to style our app. The StorageImage and StorageManager will allow us to add images and show them.

We need to be able to delete todos. Add the following function under the listTodos().

// app/page.tsx

...
 function deleteTodo(id: string) {
    client.models.Todo.delete({ id });
 }

We’ll need to update the createTodo function. It will now take in two arguments, key and content.

// app/page.tsx

...
  function createTodo({ key, content }: { key: string; content: string }) {
    client.models.Todo.create({
      content,
      key,
    });
  }

We’ll now do a few updates to the return statement. We’ll add a new StorageImage that will display our images. We’ll also add in the StorageManager. This will display a component so we can upload images.

Update the return so it matches below.

// app/page.tsx

return (
    <main>
      <h1>My todos</h1>
      <ul>
        {todos.map((todo) => (
          <li key={todo.id} onClick={() => deleteTodo(todo.id)}>
            <Flex justifyContent="space-between">
              <Text>{todo.content}</Text>
              {todo.key ? (
                <StorageImage
                  path={todo.key}
                  alt={todo.content || ""}
                  width="100px"
                />
              ) : null}
            </Flex>
          </li>
        ))}
      </ul>
      <StorageManager
        path="media/"
        acceptedFileTypes={["image/*"]}
        maxFileCount={1}
        onUploadStart={({ key }) => {
          const content = window.prompt("Todos content");
          if (!key || !content) return;
          createTodo({ key, content });
        }}
        components={{
          Container({ children }) {
            return <Card variation="elevated">{children}</Card>;
          },
          FilePicker({ onClick }) {
            return (
              <Button variation="primary" onClick={onClick}>
                Add Todo and Choose File For Upload
              </Button>
            );
          },
        }}
      />
    </main>
  );

You may notice some props on the StorageManager. The components prop can be used to completely override the look and feel of the component. In this case we changed the container slightly to add a card around it. We also changed the FilePicker so we can use a different kind of button to upload.

We added an event listener called onUploadStart. This will trigger whenever an upload begins. It will first ask the user for the todos content. It will then call the createTodo which will create the todo in the database.

Here is the complete app/page.tsx file.

"use client";
import { useState, useEffect } from "react";
import type { Schema } from "@/amplify/data/resource";
import { generateClient } from "aws-amplify/data";
import { StorageImage, StorageManager } from "@aws-amplify/ui-react-storage";
import { Card, Flex, Text, Button } from "@aws-amplify/ui-react";
import React from "react";
import { Amplify } from "aws-amplify";
import outputs from "@/amplify_outputs.json";
import "@aws-amplify/ui-react/styles.css";
Amplify.configure(outputs);
const client = generateClient<Schema>();

export default function App() {
  const [todos, setTodos] = useState<Array<Schema["Todo"]["type"]>>([]);

  function listTodos() {
    client.models.Todo.observeQuery().subscribe({
      next: (data) => setTodos([...data.items]),
    });
  }

  function deleteTodo(id: string) {
    client.models.Todo.delete({ id });
  }

  useEffect(() => {
    listTodos();
  }, []);

  function createTodo({ key, content }: { key: string; content: string }) {
    client.models.Todo.create({
      content,
      key,
    });
  }

  return (
    <main>
      <h1>My todos</h1>
      <ul>
        {todos.map((todo) => (
          <li key={todo.id} onClick={() => deleteTodo(todo.id)}>
            <Flex justifyContent={"space-between"}>
              <Text>{todo.content}</Text>
              {todo.key ? (
                <StorageImage
                  path={todo.key}
                  alt={todo.content || ""}
                  width="100px"
                />
              ) : null}
            </Flex>
          </li>
        ))}
      </ul>
      <StorageManager
        path="media/"
        acceptedFileTypes={["image/*"]}
        maxFileCount={1}
        onUploadStart={({ key }) => {
          const content = window.prompt("Todo content");
          if (!key || !content) return;
          createTodo({ key, content });
        }}
        components={{
          Container({ children }) {
            return <Card variation="elevated">{children}</Card>;
          },
          FilePicker({ onClick }) {
            return (
              <Button variation="primary" onClick={onClick}>
                Add Todo and Choose File For Upload
              </Button>
            );
          },
        }}
      />
    </main>
  );
}

Trying it out

Go ahead and start the app.

npm run dev

The front page will load. Go ahead and click the Add Todo and Choose File for Upload button.

Choose a todo name and then choose a file. You’ll see the upload occur and a new todo displayed.

You can go ahead and add a few more. You can also click any todo for them to delete.

Good job! You've created a full stack app!

Deploy to Production

In the first steps we created a new Next.js app using a starter template, we then cloned it down to edit it locally. We can now commit our changes and have it deployed back to our AWS Gen 2 console that will trigger a new branch build .

If you like, you can go ahead and stop the sandbox environment. Just go to the terminal where it's running and hit Ctrl/Cmd C. If for some reason you accidentally closed the terminal, you can always stop any sandbox environments by going back to the Amplify Gen 2 console and choosing the Manage Sandboxes button in the All apps page.

The sandbox environments are for testing only, and can be started or stopped at any time. The production environments are attached to your git branches that you pushed to Github. In this case the main branch is the production environment. If we choose to do so, we can create multiple environments if needed based on any branch we create and connect them to the AWS Gen 2 console.

To deploy our changes with the new frontend updates, all we'll need to do is a git commit and push. Open the terminal in your project and paste the following commands.

git add .
git commit -m "Updated todos App"
git push origin main

This will push all our changes to the Amplify Gen 2 console and trigger another build. After a few minutes click on the domain listed in the Amplify console to see it in action!

Conclusion

In this tutorial we learned how to get started with AWS Amplify Gen 2. We used the Amplify Next.js starter template to create a new Amplify hosted app with our backend. We then made a todo app with photo storage, used the sandbox environment to test, and then pushed it to production to see the changes!

To clean up this environment, make sure to stop the sandbox environment and then go back into the amplify console, click on our app, then go to App settings → General Settings.

Click on the Delete app button.

If you'd like to learn more make sure to check our the official docs!

Five Tutorials To Create Your Fullstack Apps Using AWS Amplify Gen 2

Erik Hanchett — Fri, 01 Mar 2024 18:16:59 +0000

AWS Amplify Gen 2 is the next generation of tooling from Amplify! It’s a new code-first developer experience that helps frontend developers create fullstack applications on AWS. You can now author your frontend and backend definition completely in TypeScript, create ephemeral sandbox environments to test against, and deploy to production using Git branch-based environments.

Since we’ve entered into developer preview at the end of last year a lot of content has been created! Let’s jump in!

Introducing The Next Generation of AWS Amplify’s Fullstack Development Experience

Amplify has unveiled a code-first way to develop fullstack applications. This post deep dives into why we decided to go this direction and how to get started. If you are looking for a overview of Gen 2, here is the place!

The guide to set up NextJS Authentication and data fetching with AWS Amplify Gen2

This post describes how to add auth and data to your application using Amplify Gen 2. This step-by-step tutorial covers creating a new Next.js 14 application, adding in Gen 2, and setting up authentication. It also shows how to use middleware to protect routes and use the generateClient API to add and list data from the backend.

How To Create A Full Stack Typesafe App With No Knowledge! Using AWS Gen2 and Next.js 14!

This video describes how to create a fullstack application using Gen 2 with Next.js 14. In it, Erik creates a protected Next.js 14 application using auth. The application helps you store titles and allows multiple users to leave comments. Viewers will learn how to create, update, list, and delete comments and titles, as well as how to setup dynamic routes. All of this backed by Gen 2, and AWS AppSync.

The future of web development: AWS Amplify’s Code First Approach

This extended article describes what Amplify Gen 2 is, the problems frontend developers face with fullstack applications, and how to resolve them. Christian uses several code examples to illustrate how to use Gen 2, extend its functionality and how to use it in your next project.

How To Add A Social Login To Your Website Using AWS!

This advanced tutorial describes how to extend Amplify Gen 2’s functionality to add a Github social login. It deep dives into OAuth, OIDC, authorization and authentication. It describes how AWS Amplify Cognito, as well as identity providers can work together with Gen 2 to create social logins.

Conclusion

There you have it! Five different tutorials on how to use AWS Amplify Gen 2! Please leave a comment below if you’ve tried Gen 2! Thanks

Secrets of Styling Forms (Using AWS Amplify Studio)

Erik Hanchett — Mon, 17 Jul 2023 21:37:19 +0000

Forms are deceptively difficult. When you create a form for your website you need to make a lot of decisions. You have to worry about validation, structure, and how to send the data to your backend. You need to figure out how to handle errors, and how to style and configure your form. You’ll need to make sure your forms are accessible. With this in mind, AWS Amplify Studio with its form builder can help!

In this post I’ll discuss how to add a new form using Amplify Studio that is connected to an AWS Appsync data source. We’ll look at how to customize that form by adding in a dark/light mode. We’ll look at how we can further customize the validation rules and edit the error messages! We’ll then test our submissions by displaying the results using Amplify’s JavaScript GraphQL API library.

If you'd like to see the completed code. Please check out this repo!

Getting Started

We’ll create a basic Todo form using Amplify studio.

To begin, sign into your AWS Console and search for AWS Amplify and click on it. If this is the first time using Amplify, choose Get Started and click on the Get started again under Amplify Studio. If you’ve already created an Amplify app in this region you can click New app → Build an app. Choose an app name, click Confirm deployment. Afterwords click Launch Studio to begin!

If you are an existing Amplify Studio user, Launch Studio from your existing application. This feature is available to all.

Data

Inside Amplify Studio let’s create a data source that we can use with our form. Click on Data in the menu.

Click Add model and create Todo. Add the completed and the title fields.

After adding these models make sure you click the Save and Deploy button in the top right hand corner. It may take a few minutes to deploy.

After the model is deployed you’ll see a page with some instructions to pull the latest client config into your React application. Make sure to copy the pull command.

Next.js App Setup

Now that we have our data and forms in place we can pull the information into our existing application. I’ll assume that you’ve already created a new Next.js application. If not, and you are starting a new Next.js application, make sure the App router turned off.

Open up your app and install these libraries with your favorite package manager.

$ npm install @aws-amplify/ui-react aws-amplify react-icons

If not already installed, make sure you also install the Amplify CLI globally.

$ npm install @aws-amplify/cli -g

If this is the first time using Amplify in a while, make sure you upgrade to the latest version of the CLI.

$ amplify upgrade

Next, take the command you copied from the last section and paste it into your terminal running it in the root of your Next.js project.

$ amplify pull --appId <replace-this-with-your-id> --envName <replace-with-env-name>

You should now see a few new files and directories in your project.

Since we are dealing with AppSync, you’ll need to generate some GraphQL query files.

$ amplify codegen add

This will generate some helpful GraphQL query/subscription/mutation files that we’ll use later on in this tutorial.

Let’s setup Amplify so we can use our new forms!

Note: If you are using Next.js with the app router or using Vite, you may need some small additional configuration. Please follow the Next.js or Vite usage guide.

Adding Our Form and Customizing it

Let’s begin setting up our Next application so it can talk to our AppSync backend.

Inside your main entry point file in your application, add these lines to configure Amplify with the correct styles.

import { Amplify } from "aws-amplify";
import awsExports from "../aws-exports";
Amplify.configure(awsExports);
import "@aws-amplify/ui-react/styles.css";

Next, we’ll be adding in a special theme file. This file is used to customize global themes throughout your application. In our case we will us to to override the default theme of our forms to support a dark mode. The defaultDarkModeOverride will add this for us.

Create a new file called theme.tsx in your src folder.

import { Theme, defaultDarkModeOverride } from "@aws-amplify/ui-react";

export const theme: Theme = {
  name: "theme",
  overrides: [defaultDarkModeOverride],
};

Next, we’ll add this Theme provider to a new Layout file. In the src/components folder create a new Layout.tsx file. Inside this file we’ll add a new colorMode useState variable that we’ll use to change the color of the theme.

The ThemeProvider surrounds our application and provides theming capabilities with design tokens to our app. These tokens can completely override the look and feel of our application. The official documentation discuss this in more detail.

import { theme } from "@/theme";
import { ColorMode, ThemeProvider } from "@aws-amplify/ui-react";
import React from "react";


export default function Layout({ children }: React.PropsWithChildren) {
  const [colorMode, setColorMode] = React.useState<ColorMode>("light");
  return (
    <ThemeProvider theme={theme} colorMode={colorMode}>
        {children}
    </ThemeProvider>
  )
}

Let’s add in a toggle button so users can select between dark and light mode. We’ll be using the react-icons/md set for these icons.

import { theme } from "@/theme";
import { MdOutlineDarkMode, MdOutlineLightMode } from "react-icons/md";
import { ColorMode, Flex, ThemeProvider, ToggleButton, ToggleButtonGroup } from "@aws-amplify/ui-react";
import React from "react";


export default function Layout({ children }: React.PropsWithChildren) {
  const [colorMode, setColorMode] = React.useState<ColorMode>("light");
  return (
    <ThemeProvider theme={theme} colorMode={colorMode}>
      <Flex direction="column" gap="0" width="100vw" height="100vh" backgroundColor="background.primary">
          <ToggleButtonGroup
            value={colorMode}
            size="small"
            isExclusive
            onChange={(value) => setColorMode(value as ColorMode)}
          >
            <ToggleButton value="light">
              <MdOutlineLightMode />
            </ToggleButton>
            <ToggleButton value="dark">
              <MdOutlineDarkMode />
            </ToggleButton>
          </ToggleButtonGroup>
        {children}
      </Flex>
    </ThemeProvider>
  )
}

The ToggleButtonGroup is from a set of UI primitives offered by the @aws-amplify/ui-react library. It creates a nice looking toggle button. On every click of the toggle button the colorMode is set, and is updated in the ThemeProvider. This will cause the screen to change between dark and light mode.

Finally, we’ll add in an AppHeader component to help sticky this layout to the top left hand corner. We’ll also add a nice icon using the Icon component primitive.

import { theme } from "@/theme";
import { MdOutlineDarkMode, MdOutlineLightMode } from "react-icons/md";
import {
  ColorMode,
  Flex,
  Icon,
  ThemeProvider,
  ToggleButton,
  ToggleButtonGroup,
} from "@aws-amplify/ui-react";
import React from "react";

function AppHeader({ children }: React.PropsWithChildren) {
  return (
    <Flex
      as="header"
      direction="row"
      justifyContent="space-between"
      alignItems="center"
      padding="1rem"
      boxShadow="small"
      position="sticky"
      top="0"
      left="0"
      width="100%"
      backgroundColor="background.primary"
    >
      {children}
    </Flex>
  );
}

export default function Layout({ children }: React.PropsWithChildren) {
  const [colorMode, setColorMode] = React.useState<ColorMode>("light");
  return (
    <ThemeProvider theme={theme} colorMode={colorMode}>
      <Flex
        direction="column"
        gap="0"
        width="100vw"
        height="100vh"
        backgroundColor="background.primary"
      >
        <AppHeader>
          <Icon
            color="brand.primary.60"
            fontSize="xl"
            paths={[
              {
                d: "M10.8484 4.19838C10.7939 4.2926 10.7939 4.40867 10.8484 4.50288L21.3585 22.6711C21.413 22.7653 21.5138 22.8233 21.6228 22.8233H23.9901C24.225 22.8233 24.3718 22.5696 24.2543 22.3666L12.5605 2.15225C12.4431 1.94925 12.1495 1.94925 12.0321 2.15225L10.8484 4.19838Z",
              },
              {
                d: "M15.2084 22.6711C15.2629 22.7653 15.3636 22.8233 15.4726 22.8233H17.8461C18.081 22.8233 18.2278 22.5696 18.1104 22.3666L9.48857 7.46259C9.37113 7.25959 9.07755 7.25959 8.96011 7.46259C6.09213 12.4203 3.21732 17.4003 0.336955 22.3816C0.219574 22.5846 0.366371 22.8383 0.601212 22.8383H11.7185C11.9533 22.8383 12.1001 22.5846 11.9827 22.3816L10.8455 20.4158C10.791 20.3216 10.6903 20.2635 10.5813 20.2635H4.8952C4.77776 20.2635 4.70437 20.1367 4.76308 20.0352L9.0912 12.5534C9.14991 12.4519 9.29671 12.4519 9.35542 12.5534L15.2084 22.6711Z",
              },
            ]}
          />
          <ToggleButtonGroup
            value={colorMode}
            size="small"
            isExclusive
            onChange={(value) => setColorMode(value as ColorMode)}
          >
            <ToggleButton value="light">
              <MdOutlineLightMode />
            </ToggleButton>
            <ToggleButton value="dark">
              <MdOutlineDarkMode />
            </ToggleButton>
          </ToggleButtonGroup>
        </AppHeader>
        {children}
      </Flex>
    </ThemeProvider>
  );
}

We’ll need to update the _app.tsx file so our new layout surrounds the application.

...
export default function App({ Component, pageProps }: AppProps) {
  return (
    <Layout>
      <Component {...pageProps} />
    </Layout>
  );
}

Toggle the dark mode and see it in action.

Before:

After:

Adding our form and customizing them

Let’s now add in our form to the main route index.tsx file in our Next.js application.

Import the form onto the page.

import TodoForm from "@/ui-components/TodoCreateForm";

export default function Home() {

return <TodoForm/>

}

By convention this form is already connected to the AppSync model we created earlier. Under the covers it uses something called DataStore to sync and send data to the backend.

We can customize this form to our liking. Let’s update the validation rule first. Assume that we don’t want users to enter in empty spaces. We’ll add a check for that and display a custom error message.

 <TodoForm
    padding="0"
    onValidate={{
       title: (value, validateResponse) => {
         if (value.trim().length === 0) {
             return {
             hasError: true,
               errorMessage: "Please enter a value!",
             };
          }
          return validateResponse;
       },
     }}
  />

With this validation in place, users won’t be able to submit a blank input in without getting an error. The forms logic will handle the rest and will disable the input as well.

Imagine we want to show a message every time the user successfully submit a todo. The generated forms have event handlers that you can hook into and listen for. In this example, we’ll create a showSuccess variable that we can use to trigger an alert message, that fades after two seconds.

const [showSuccess, setShowSuccess] = useState(false);
  ...
        <TodoForm
          padding="0"
          onValidate={{
            title: (value, validateResponse) => {
              if (value.trim().length === 0) {
                return {
                  hasError: true,
                  errorMessage: "Please enter a value!",
                };
              }
              return validateResponse;
            },
          }}
          onSuccess={() => {
            setShowSuccess(true);
            setTimeout(() => {
              setShowSuccess(false);
            }, 2000);
          }}
        />
        {showSuccess && <Alert variation="success">Todo added!</Alert>}

The onSuccess handler will trigger as soon as the form has submitted successfully. We can then show an alert! This Alert is another @aws-amplify/ui-react UI primitive.

Now that we have a way to add todo’s, we will need a way to show them.

Let’s add a method that grabs all the todos. This will use the Amplify JS library GraphQL API.

import { API, graphqlOperation } from "aws-amplify";
import { GraphQLQuery, GraphQLSubscription } from "@aws-amplify/api";
import { ListTodosQuery, Todo, OnCreateTodoSubscription } from "@/API";
import { listTodos } from "@/graphql/queries";
...
const [todos, setTodo] = useState<Todo[]>([]);


const getTodos = async () => {
    const allTodos = await API.graphql<GraphQLQuery<ListTodosQuery>>({
      query: listTodos,
    });

    const filteredTodos = allTodos.data?.listTodos?.items
      .filter((todo) => !todo?._deleted)
      .sort(
        (a, b) =>
          new Date(a?.createdAt!).getTime() - new Date(b?.createdAt!).getTime()
      );

    setTodo(filteredTodos as Todo[]);
  };

Since we created our application using Studio and form builder, by convention our forms uses DataStore and conflict resolution turned on in the background. Conflict resolution creates a versioned data source that enhances the object data model with metadata. At this time, you cannot turn this off when using Form Builder and studio.

What that means is that our Data model has a few extra meta fields including _deleted and _version . These are automatically added to our data model when the model was created. When you delete a record, it doesn’t get deleted, the way you normally may expect. Instead, the _deleted field gets set to true and the record remains. Keep this in mind when dealing with data with conflict resolution turned on. This is why we must filter out records with _deleted set to true in our code, that way we don’t accidentally show deleted data.

It’s good to know that if you decide to make updates or deletions to any record using the Amplify GraphQL API, you must also include the _version in the GraphQL input since conflict resolution is turned on. The _version field will increment on every change that occurs to the record. You’ll need to keep track of this _version field when you make updates or delete an item.

To guarantee the correct order, we sort by the createdAt time.

Now that we have a way to grab data, we’ll create a GraphQL subscription that will load as soon as the application loads using a useEffect.

import { API, graphqlOperation } from "aws-amplify";
import { GraphQLQuery, GraphQLSubscription } from "@aws-amplify/api";
import { ListTodosQuery, Todo, OnCreateTodoSubscription } from "@/API";
import { onCreateTodo } from "@/graphql/subscriptions";
import { useEffect, useState } from "react";
...

const [todos, setTodo] = useState<Todo[]>([]);

useEffect(() => {
    getTodos();
    const sub = API.graphql<GraphQLSubscription<OnCreateTodoSubscription>>(
      graphqlOperation(onCreateTodo)
    ).subscribe({
      next: ({ provider, value }) => {
        setTodo((prevValue) => [
          ...prevValue,
          value.data?.onCreateTodo as Todo,
        ]);
      },
      error: (error) => console.warn(error),
    });

    return () => sub.unsubscribe();
  }, []);

We first trigger the getTodos and then run our subscription. As soon as a new Todo is created, the subscription is triggered. We can then use our setTodo to save the data into the array. Alternatively, we could call getTodos again on every subscription change, however for the sake of this post we’ll manipulate the todos array and add the new todo to it instead.

Let’s put this all together into one file. I’ve added a few more UI primitives to make things easier including a Collection component that is used with the array to display data in a nice row.

import {
  Alert,
  Card,
  Collection,
  Flex,
  Heading,
  Text,
  useTheme,
} from "@aws-amplify/ui-react";
import TodoForm from "@/ui-components/TodoCreateForm";
import { API, graphqlOperation } from "aws-amplify";
import { GraphQLQuery, GraphQLSubscription } from "@aws-amplify/api";
import { ListTodosQuery, Todo, OnCreateTodoSubscription } from "@/API";
import { listTodos } from "@/graphql/queries";
import { onCreateTodo } from "@/graphql/subscriptions";
import { useEffect, useState } from "react";

export default function Home() {
  const [showSuccess, setShowSuccess] = useState(false);
  const [todos, setTodo] = useState<Todo[]>([]);

  const getTodos = async () => {
    const allTodos = await API.graphql<GraphQLQuery<ListTodosQuery>>({
      query: listTodos,
    });

    const filteredTodos = allTodos.data?.listTodos?.items
      .filter((todo) => !todo?._deleted)
      .sort(
        (a, b) =>
          new Date(a?.createdAt!).getTime() - new Date(b?.createdAt!).getTime()
      );

    setTodo(filteredTodos as Todo[]);
  };

  useEffect(() => {
    getTodos();
    const sub = API.graphql<GraphQLSubscription<OnCreateTodoSubscription>>(
      graphqlOperation(onCreateTodo)
    ).subscribe({
      next: ({ provider, value }) => {
        setTodo((prevValue) => [
          ...prevValue,
          value.data?.onCreateTodo as Todo,
        ]);
      },
      error: (error) => console.warn(error),
    });

    return () => sub.unsubscribe();
  }, []);

  const { tokens } = useTheme();

  return (
    <Flex
      direction="row"
      height="100%"
      width="100%"
      justifyContent="stretch"
      gap="0"
    >
      <Flex
        direction="column"
        gap="medium"
        padding="xxl"
        backgroundColor="background.primary"
      >
        <Text>New ToDo</Text>
        <TodoForm
          padding="0"
          onValidate={{
            title: (value, validateResponse) => {
              if (value.trim().length === 0) {
                return {
                  hasError: true,
                  errorMessage: "Please enter a value!",
                };
              }
              return validateResponse;
            },
          }}
          onSuccess={() => {
            setShowSuccess(true);
            setTimeout(() => {
              setShowSuccess(false);
            }, 2000);
          }}
        />
        {showSuccess && <Alert variation="success">Todo added!</Alert>}
      </Flex>
      <Flex
        direction="column"
        flex="1"
        padding="xxl"
        backgroundColor="background.secondary"
      >
        <Heading level={3}>List of Todos</Heading>

        <Collection gap="small" type="list" items={todos}>
          {(todo) => (
            <Card
              variation="elevated"
              color={tokens.colors.brand.primary[100]}
              marginTop="1rem"
              padding="1rem"
              key={todo.id}
              textDecoration={todo?.completed ? "line-through" : ""}
            >
              {todo?.title}
            </Card>
          )}
        </Collection>
      </Flex>
    </Flex>
  );
}

Let’s take a look at it in action:

And with dark mode, after clicking the dark mode icon!

There is a lot more we could do here. We could add a way to take already existing todos and delete them and mark them complete. I’ll leave that exercise for you!

Deletion

Once you’re done with your application you can delete all your resources by running amplify delete.

Conclusion

In this blog post we’ve learned about Amplify Studio forms, how to customize them and how to add additional validation error messages. If you’d like to learn more about Amplify in general please check out the official docs. You can also check the Amplify Studio tutorial for more information on how to use it.

Please let me know if you have any questions, I’m at ErikCH on Twitter!

Front End Flash from AWS Amplify

Erik Hanchett — Wed, 24 May 2023 15:31:28 +0000

Hello and welcome to the AWS Amplify community roundup post!

Amplify is a set of tools for frontend and mobile developers to build, ship, and host full-stack applications on AWS.

This post is meant to be a place where you can find the latest information on Amplify, AppSync - our fully managed GraphQL service, and all things frontend and mobile! We’ll be showcasing our latest tutorials, guides, conference talks and some future plans we have in place.

Why a Post?

Many internal and external teams at Amplify create great content. From our developer advocate team to marketing, docs, solution architects and our community members. This content has an amazing amount of insight that I'd like to share with all of you!

This post will help highlight that content, and hopefully help educate you on what we offer.

Feedback

If you have a minute please complete this short survey. This will really help us make this post better!

Creating SaaS Applications With AppSync and Amplify!

Have you ever imagined creating a software as a service (Saas) startup? Did you know Amplify has all the tools you need to get started? Check out this tweet from Ryan!

It’s really nice to see real people using AWS Amplify to solve their problems. I really liked how Ryan used Amplify and the AWS Free Tier with AWS Startups to get thousands of free credits!

Michael Liendo talked about this very subject recently during the AWS Developer Innovation Day!

Build a full-stack, fully typed app with GraphQL and AWS AppSync (fast forward to 01:26:50)

Make sure you watch some of the other talks too, you’ll get a good idea of many of the innovations that AWS provides.

He also open source his contributions so you can take a look at his code on Github!

MicroSaas Backend

Building Modern Apps With Amplify

The non-stop innovations in the web space amazes me. Every month there is a new library or framework that I must try out! Here at AWS we want to meet developers where their at. We want you to build on modern tooling and frameworks and not worry about the infrastructure. Here are some tutorials and guides that follow these principles.

Astro, SolidJS and Data With Amplify

Have you tried out Astro or SolidJS? Christian Nwamba recently published two excellent tutorials on how to deploy a SolidJS and Astro Blog to Amplify hosting!

Deploy a SolidJS App With AWS Amplify

and

Deploy an Astro Blog With AWS Amplify

Christian also created an excellent video on how to work with data APIs, and how to get the correct types from the backend to the frontend using AWS AppSync.

Better Developer Experience When Working With Data APIs

Sign In With Google With Amplify Authenticator

A very common use case that we often see in modern web development is logging in with Google. This allows customers with a Google account to login with a few clicks.

Amplify supports this feature, and in the following shorts Erik Hanchett shows how you can add this to your website in minutes!

Add A Sign In With Google To Your Website Part 1

Add A Sign In With Google To Your Website Part 2

Erik has also been busy live streaming building a full-stack app! He’s been using a modern stack including, Amplify services, Next.js, AppSync, lambdas and more! You can find him live streaming weekly on his YouTube channel on Fridays, or you can watch his last two videos on demand!

Building a full-stack app with Authenticator Live streamed April 6

Building a full-stack app with Authenticator Live streamed April 14

Flutter and Cross Platform Development

Did you know we have a Flutter library that works directly with Amplify services? And we just recently updated our docs site with instructions on how to create a budget tracking app?

In this video Muhammed Salih Güler talks about cross platform development, how how the Amplify Flutter library works!

CB Community Flutter

Salih has also been busy live streaming! Check out his last live stream on using the Flame Engine with Flutter!

Flame Engine Live Stream Livestream April 6

Storage Manager and Liveness

In April we launched our new Storage Manger UI and Face Liveness components!

The Liveness component helps deter fraud by using our Amazon Rekognition service. You may want to use a service like this for an ID verification system or for fraud detection. This is built into our React, Flutter, Android and Swift libraries.

The Amplify UI StorageManger has been released for general availability! This file uploader makes it straight forward to upload files directly to S3, with only a few lines of boilerplate code!

Where in the World is Amplify ✈️ ?

The developer advocate team has been busy traveling!

Muhammed Salih Güler will be giving a talk on June 2 at Flutter Connection in Paris! Stop on by and find Salih so you can learn about Amplify and Flutter! He'll also be at the AWS Summit in Amsterdam on June 1st and Flutter Berlin on June 7th.

From May 31 - June 2, Michael Liendo and Erik Hanchett are giving talks at RenderATL in Atlanta! Amplify will be sponsoring the conference so please look for our AWS booth and say hi if you’re at the conference

Erik will also be giving a talk on May 24 - 26 - at VueConf US 2023 in New Orleans! Erik will have some stickers on him, so feel free to stop him and grab some.

If you’re a part of the community builders program with AWS, you can also here Michael Liendo give a talk on MicroSaaS architecture on May 24th! We are always looking for more community developers so feel free to signup and you might be chosen!

Thanks

As you can see we’ve had a busy few months! What content would you like to see? Leave a comment or tweet me at @ErikCH! Thanks