DEV Community: Kohei Aoki

How a Custom Docker Image Made My AWS Amplify Builds 10–20% Faster (and Killed Flaky Build Failures)

Kohei Aoki — Tue, 14 Apr 2026 07:54:35 +0000

Intro

If you keep running an app on AWS Amplify for long enough, you'll hit this problem: your amplify.yml quietly gets more complex and your builds quietly get slower. Every new feature or tool swap adds one more line to preBuild, and before you know it, no one on the team has the whole build graph in their head. Builds creep up, external downloads pile up, and flaky failures start showing up at 3 a.m.

This is the kind of thing you have to revisit periodically, and this post is about one of those revisits.

Concretely: I swapped our AWS Amplify Gen2 build environment for a custom Docker image, and our staging build time dropped from a median of 9m43s to 8m45s — about 10% per build, roughly 1 minute. Depending on your framework, the realistic range is 10–20%, and Next.js apps can hit 50–70%. On top of the raw speed, download-caused build failures dropped to zero.

This post walks through the design, implementation, real-world measurements, and operational tips from running this in production. If you operate a monorepo on AWS Amplify Gen2 and you're thinking "our builds are slower than they should be" or "I want to kill these flaky download-caused failures," this is for you.

Why I built a custom build image

Our app is a pnpm workspace monorepo: apps/web-app (Vite + React) plus packages/gen2-shared-backend (Amplify Gen2 backend, Hono Lambda, CDK custom resources). With the default Amplify build image, every single build was paying these costs:

nvm install 22 to reinstall Node.js: ~15s
corepack enable && corepack prepare pnpm@10.28.1 --activate: ~10s
curl'ing a 64 MB Chromium Lambda Layer ZIP from GitHub Releases: ~20–40s
pnpm install --frozen-lockfile from an empty store: 60–90s

That's 2–3 minutes of pure setup every build. And as I'll show, the raw time wasn't even the biggest problem — stability was.

The trigger: a midnight build failure

The real push came on 2026-03-22 when our staging backend build broke. Digging in, I found the curl'd Chromium Layer ZIP was corrupt — Could not unzip uploaded file. GitHub Releases was apparently having a bad minute, and our curl didn't even have --fail, so the HTTP error body had been dutifully written to disk as a "ZIP file."

We filed it in our build-fix logs as "P4: silent failure on external asset download." It's a pattern we've hit multiple times.

At that point I had two choices:

Patch the amplify.yml: add --fail --retry 3 --retry-delay 5, add file size validation, make curl careful.
Bake the Chromium Layer into the build image itself and remove the download entirely.

Option 1 still leaves 20–40 seconds of downloading every build, and the network-failure risk never really goes to zero. Option 2 burns the file in once, at image build time, and also lets us delete the nvm and pnpm setup steps. I picked option 2.

The multi-stage Dockerfile design

I split docker/Dockerfile into multi-stage, producing two images from one base:

Stage	Tag	Purpose	Size
`build`	`latest`	Amplify custom build + GitHub Actions lint/build	~800 MB
`e2e`	`e2e`	GitHub Actions Playwright E2E	~1.4 GB

The base image mistake I made

I started with node:22-bookworm-slim. Debian-based, lightweight, official Node image — seemed like the obvious safe pick.

Except builds got flaky once Amplify ran it. The root cause: Amplify's default build image is Amazon Linux 2 (now 2023). Different glibc versions mean ampx and aws-cdk pull different native binaries, and the difference can bite you in non-obvious ways.

So I rewrote it to amazonlinux:2023. Match Amplify's default OS — it's the simplest, safest choice.

FROM amazonlinux:2023 AS build

ENV PNPM_HOME="/root/.local/share/pnpm" \
    PNPM_STORE_DIR="/root/.local/share/pnpm/store" \
    BUN_INSTALL="/root/.bun" \
    NVM_DIR="/root/.nvm" \
    CHROMIUM_LAYER_DIR="/opt/chromium-layer" \
    CHROMIUM_LAYER_VERSION="v127.0.0"

ENV PATH="$PNPM_HOME:$BUN_INSTALL/bin:$PATH"

RUN dnf update -y && dnf install -y \
    git openssh-clients bash jq tar wget zip unzip gzip \
    which findutils procps-ng ca-certificates \
    && dnf clean all && rm -rf /var/cache/dnf

What's in the image

Node.js 22 LTS (via nvm)
pnpm 10.28.1 (via corepack — still pnpm for workspace management)
bun — we can't fully migrate (no --filter, CDK/ampx compatibility is unclear), but we use bun for hono Lambda's isolated install and tsx script execution
AWS CLI v2 — required for ampx, appsync, ssm
aws-cdk (global)
Chromium Lambda Layer v127.0.0 — pre-baked to /opt/chromium-layer/. We validate the file size at image build time and hard-fail if it's under 1 MB:

RUN mkdir -p "$CHROMIUM_LAYER_DIR" \
    && curl -fSL --retry 3 --retry-delay 5 \
       -o "$CHROMIUM_LAYER_DIR/chromium-${CHROMIUM_LAYER_VERSION}-layer.zip" \
       "https://github.com/Sparticuz/chromium/releases/download/${CHROMIUM_LAYER_VERSION}/chromium-${CHROMIUM_LAYER_VERSION}-layer.zip" \
    && LAYER_SIZE=$(stat -c%s "$CHROMIUM_LAYER_DIR/chromium-${CHROMIUM_LAYER_VERSION}-layer.zip") \
    && if [ "$LAYER_SIZE" -lt 1000000 ]; then \
         echo "ERROR: Chromium layer is only ${LAYER_SIZE} bytes"; exit 1; \
       fi

The trick is running curl -fSL --retry 3 + size validation at image build time, not production build time. If something fails here, that image version just never makes it to ECR — our production Amplify builds never see the failure. We cut off the "3 a.m. build break" path at the root.

Lock down the pnpm store path across every context

This is the single biggest speedup. pnpm install speed is determined by whether the tarball is already in the content-addressable store:

Empty store → 60–90 seconds (full download every time)
Store populated → 5–15 seconds (hardlinks only)

You need the same PNPM_STORE_DIR in Dockerfile, Amplify build, and GitHub Actions, and you need to list that path in Amplify's cache.paths. If they don't agree, your second build still pays the full download cost.

RUN . "$NVM_DIR/nvm.sh" \
    && corepack enable \
    && corepack prepare pnpm@10.28.1 --activate \
    && pnpm config set store-dir "$PNPM_STORE_DIR" \
    && pnpm --version

Simplifying amplify.yml

The clearest before/after is in the amplify.yml itself.

Before

version: 1
backend:
  phases:
    preBuild:
      commands:
        - nvm install 22 && nvm use 22
        - corepack enable && corepack prepare pnpm@10.28.1 --activate
        - |
          curl -L \
            -o packages/gen2-shared-backend/layer/chromium-v127.0.0-layer.zip \
            https://github.com/Sparticuz/chromium/releases/download/v127.0.0/chromium-v127.0.0-layer.zip
        - pnpm install --frozen-lockfile

Every build: reinstall Node, set up pnpm, download a 64 MB ZIP from GitHub Releases, then finally run the real install. No --fail, no retries, no size check on that curl.

After

version: 1
backend:
  phases:
    preBuild:
      commands:
        # Custom image already has pnpm. Fallback just in case.
        - command -v pnpm >/dev/null 2>&1 || { nvm install && nvm use && corepack enable && corepack prepare pnpm@10.28.1 --activate; }
        # Chromium Layer is baked in — just copy it
        - |
          LAYER_DIR=/opt/chromium-layer
          if [ -f "$LAYER_DIR/chromium-v127.0.0-layer.zip" ]; then
            cp "$LAYER_DIR/chromium-v127.0.0-layer.zip" packages/gen2-shared-backend/layer/
          fi
        - pnpm install --frozen-lockfile
cache:
  paths:
    - /root/.local/share/pnpm/store
    - node_modules/.pnpm
    - apps/web-app/.build-cache
    - packages/gen2-shared-backend/.build-cache

I kept the command -v pnpm fallback intentionally: the amplify.yml should still work even if the custom image isn't in effect. I learned this the hard way — one PR removed the fallback, Amplify quietly fell back to the standard image for a branch, and every build died with pnpm: command not found. Design the amplify.yml so custom image = fast, no custom image = still works.

The numbers

I pulled staging build times via aws amplify list-jobs, filtered to successful jobs, and compared the windows before and after the image switch:

Window	Count	Median	Trimmed mean (trim top/bottom 10%)
Before (38 jobs)	38	9m43s	9m48s
After (57 jobs)	57	8m45s	8m53s

~58 seconds faster on median, 10.0%. A minute per build doesn't sound like much, but at ~50 builds a week that's 50 minutes of saved lead time per week, every week.

Your framework caps your ceiling

The most important thing to understand: the upper bound of this speedup is set by your framework, not by how clever your Dockerfile is. Here's the table I put together when designing the migration, with expected speedup per framework:

Framework	First build	Subsequent builds	Speedup
Next.js (SSR)	90–150s	30–60s	50–70%
React Router v7 / Remix	30–60s	25–50s	10–20%
Vite (our current setup)	60–90s	50–80s	10–15%

Our measured 10.0% landed right in the middle of the Vite band. Figuring out which band you're in tells you, up front, whether this project is worth the effort.

Vite doesn't benefit much because Vite has no persistent production build cache (see vitejs/vite#15092). node_modules/.vite/ is just the dev-server dependency pre-bundle — it does nothing for pnpm build. So the only win for Vite projects is the pnpm store cache.

Next.js is a different story entirely. .next/cache/webpack persists compiled Webpack/SWC chunks — that's a real production build cache, and the second-build speedup is an order of magnitude bigger. If you're on Next.js, this is unambiguously worth doing.

Three wins bigger than the minute of speedup

Honestly, the one-minute median speedup wasn't even the main win. The three side effects were:

1. Build failures dropped to zero

This is the biggest one. Before the image, we were losing builds a few times a month to curl failures on the Chromium Layer or GitHub Releases rate limits. You know the drill: stop the release at midnight, retry it before standup.

Since the switch, zero failures from external downloads. The ZIP is baked into the image, and the image build itself validates the size, so by the time production Amplify runs, "the file exists and is the right size" is mathematically guaranteed.

That peace of mind is worth more than the minute to me.

2. The "which Node version are we on?" question went away

Amplify's standard image updates on its own schedule. One day Node's minor version jumps, a preinstalled tool changes, and suddenly something that passed locally fails in CI. We've been bitten by this multiple times.

With the custom image, amazonlinux:2023 + Node.js 22 LTS + pnpm 10.28.1 are pinned everywhere — local dev, CI, and all four Amplify environments (prod / staging + two regional variants) all run the same runtime derived from the same Dockerfile. Quietly huge for reproducibility.

3. The next project gets the payoff

Our next project is going to be Next.js. Same image, and we hit the 50–70% speedup by design. The 10% on the Vite app is really the down payment — the real ROI compounds as we add more projects.

If you run multiple monorepos, the horizontal expansion cost is ~zero after the first one. That matters.

Bonus: it works in GitHub Actions too

The image isn't Amplify-specific. You can drop it straight into GitHub Actions via container:, which removes setup-node and setup-pnpm from your workflow entirely. That's another 30–60 seconds shaved off CI.

jobs:
  e2e:
    runs-on: ubuntu-latest
    container:
      image: public.ecr.aws/j9g5b1t3/amplify-build:e2e
    steps:
      - uses: actions/checkout@v6
      - uses: actions/cache@v5
        with:
          path: /root/.local/share/pnpm/store
          key: pnpm-store-${{ hashFiles('pnpm-lock.yaml') }}
          restore-keys: pnpm-store-
      - run: pnpm install --frozen-lockfile
      - run: pnpm test:e2e

The e2e stage also has Playwright + Chromium pre-baked, so npx playwright install is gone too. The really nice structural property here is that "Amplify and CI ran with slightly different runtimes" is now impossible — they're literally the same image. Use the same actions/cache key as Amplify's cache paths and your entire caching layer is unified.

If you've been putting off writing a Dockerfile "just for Amplify," the honest framing is: you're writing it for CI too, and that makes the investment much easier to justify.

Operational tips

A few things I learned the hard way.

The NODE_OPTIONS trap

I initially baked ENV NODE_OPTIONS="--max-old-space-size=6144" into the Dockerfile. Even on Amplify's STANDARD_8GB compute, the OOM killer still came for us. Turns out that when pnpm, Vite, and tsx spike simultaneously, peak memory can exceed 6 GB — and NODE_OPTIONS inherits into every Node process.

I dropped it to 4096, then eventually removed NODE_OPTIONS from the Dockerfile entirely. Amplify's runtime controls this when it needs to; pinning it in the image just overrode that logic. When in doubt, leave the image "plain" and let Amplify manage runtime constraints.

Assume `rsync` doesn't exist

I had a postBuild step doing rsync --exclude='*.map' dist/ out/ to strip source maps. It failed in Amplify's default environment because rsync isn't preinstalled.

# Before
rsync -a --exclude='*.map' dist/ out/

# After (find + cp alternative)
mkdir -p out && (cd dist && find . -type f ! -name '*.map' -exec cp --parents {} ../out/ \;)

I could have just added rsync to the custom image, but the principle here matters: the amplify.yml should work even when the custom image isn't active. If you lean too hard on "but my custom image has X," you make your deployment fragile. Keep the amplify.yml executable on vanilla Amplify.

Try the public image yourself

The actual image from this article is on ECR Public — no auth needed, pull it directly:

# build stage (for Amplify custom build / CI lint / build)
docker pull public.ecr.aws/j9g5b1t3/amplify-build:latest

# e2e stage (includes Playwright + Chromium)
docker pull public.ecr.aws/j9g5b1t3/amplify-build:e2e

Gallery: https://gallery.ecr.aws/j9g5b1t3/amplify-build
Contains: Amazon Linux 2023 / Node.js 22 / pnpm 10.28.1 / bun / AWS CLI v2 / CDK / Chromium Lambda Layer v127.0.0
Caveat: This registry is published for the article. For long-term production use, fork the image into your own ECR so you control tags and lifecycle.

Takeaways

Custom Docker image for AWS Amplify Gen2 monorepo (Vite): ~1 minute (10%) faster on median. Realistic range by framework: 10–20% for most, 50–70% for Next.js.
Framework characteristics set the ceiling. Vite: 10–15%. React Router v7 / Remix: 10–20%. Next.js: 50–70%. Decide whether to invest based on which band you're in, before you start.
The speedup isn't the main prize. Zero download-caused build failures, unified runtime across all environments, and near-zero cost to roll this out to the next project — those are what actually matter day to day.
Keep the amplify.yml backward-compatible. command -v pnpm fallback + existence check for /opt/chromium-layer/ = your production doesn't die if the custom image ever isn't in effect.

Build-time improvements tend to get framed as "make it faster," but in practice, "make it not fail" is just as important — maybe more. A custom Docker image gets you both for one piece of work. That's a good trade.

References

Sparticuz/chromium — the Chromium Lambda Layer
How pnpm's store works
Vite issue tracking persistent production build cache (vitejs/vite#15092)

How I Use 4 Terminal Setups with Claude Code Agent Teams

Kohei Aoki — Tue, 31 Mar 2026 13:58:16 +0000

Introduction

I stopped opening my IDE. Claude Code is my development environment now — VSCode is only for the occasional visual check.

One feature I use daily is Agent Teams: multiple Claude Code instances working as a coordinated team, with one leader assigning tasks and members working independently in their own context windows. It's especially effective for parallel investigation, code review, and debugging.

Agent Teams support two display modes: in-process mode (any terminal) and split-pane mode (each member gets its own pane). Split-pane mode requires tmux or iTerm2, which sent me on a search for the best terminal setup on Mac.

I tested four environments, found that each has trade-offs, and ended up building an fzf session picker that lets me choose the right one every time I open a window.

What I Need from a Terminal

When Claude Code is your primary development tool, terminal requirements expand:

Clickable URLs and file paths — Claude outputs links constantly (PR URLs, docs, deploy URLs)
Agent Teams split-pane mode — run multiple agents in parallel with full visibility
Session persistence — stop work today, resume tomorrow
Japanese input — I write prompts in Japanese daily (relevant for CJK users)

Comparing 4 Setups

Legend: ◎ = built-in　○ = requires config/plugin　△ = limited　× = not supported

Feature	Ghostty	iTerm2	Ghostty + tmux	Ghostty + zellij
Rendering speed	◎	△ slow	◎	◎
Open URLs / files	◎ Cmd+Click	◎	◎ Cmd+Shift+Click	◎ Cmd+Shift+Click
CJK input	◎	◎	○ Ghostty config	◎
Shift+Enter newline	◎	◎	○ Ghostty config	◎
Session persistence	×	×	○ plugin	◎ built-in
Status line display	×	×	○ tmux config	×
Agent Teams split pane	×	○ it2 CLI + Python API	◎	×
Ease of use	◎	◎	△ many keybindings	◎ UI guides

Ghostty — Fastest, Zero Config

Ghostty (v1.3.1) is a GPU-accelerated cross-platform terminal emulator. On macOS it uses Metal, and startup feels under 0.1 seconds.

The killer feature for Claude Code is clickable URLs. With link-url, Cmd+Click opens any URL in your browser. Since Claude Code constantly outputs PR links, doc URLs, and deploy URLs, this is a significant productivity boost.

Weakness: No session management. Agent Teams only work in in-process mode — no split panes.

iTerm2 — Feature-Rich, No Setup Required

iTerm2 is the classic macOS terminal. It's stable, feature-rich, and supports Agent Teams split-pane mode (requires it2 CLI installation and enabling the Python API).

Weakness: Noticeably slower rendering compared to Ghostty. When Claude Code outputs long responses, iTerm2 shows visible lag that Ghostty doesn't.

Ghostty + tmux — Extensible with Config and Plugins

Combining tmux with Ghostty unlocks Agent Teams split-pane mode, plus:

Session persistence: tmux-resurrect + tmux-continuum save and restore window layouts, pane arrangements, and working directories
Status line display: Show Claude Code's project name, model, and context usage in tmux's status bar

Note: Some Ghostty features are restricted through tmux. URL clicking works with Cmd+Shift+Click, and Shift+Enter requires a Ghostty config tweak. See the configuration section below.

Ghostty + zellij — Built-in Features

zellij (v0.43.1) is a Rust-based terminal workspace. It displays UI guides, so you don't need to memorize keybindings like tmux. Session persistence is built in.

Overall, zellij is more intuitive than tmux and easier to pick up if you're new to terminal multiplexers.

Weakness: Agent Teams split-pane mode is not supported. URL clicking works with Cmd+Shift+Click, same as tmux.

Recommendations by Use Case

Use case	Recommendation
Daily Claude Code usage	Ghostty (fast, clickable URLs)
Agent Teams with split panes	Ghostty + tmux (Shift+Enter fix via config)
Session persistence + intuitive UX	Ghostty + zellij
Stability, minimal parallel work	iTerm2

Configuration for Ghostty + tmux/zellij

tmux: Shift+Enter Fix

Through tmux, Shift+Enter doesn't work in Claude Code. Add this to your Ghostty config:

# ~/.config/ghostty/config
keybind = shift+enter=text:\x1b[13;2u

tmux: Session Persistence

# tmux.conf
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @resurrect-capture-pane-contents 'on'
set -g @continuum-restore 'on'
set -g @continuum-save-interval '15'

tmux: Claude Code Status Line

# tmux.conf
# Left: project name
set -g status-left "#[fg=#89b4fa,bold] #(cat ~/.claude/tmux-status-left.txt 2>/dev/null || echo '#S') "
# Right: model, context usage, rate limit, cost
set -g status-right "#[fg=#a6e3a1]#(cat ~/.claude/tmux-status-right.txt 2>/dev/null)#[default]"

zellij: Session Persistence

// zellij config.kdl
session_serialization true
serialize_pane_viewport true

Ghostty: Keybinding Adjustments (Shared)

When using tmux or zellij, Ghostty keybindings can conflict:

# ~/.config/ghostty/config
keybind = super+t=unbind
keybind = super+n=unbind
keybind = super+w=unbind
keybind = super+c=copy_to_clipboard
keybind = super+v=paste_from_clipboard
keybind = super+q=quit

fzf Session Picker

Since the best setup depends on what I'm doing, I built a script that lets me choose every time I open a new Ghostty window.

┌──────────────────────────────────────┐
│ session >                            │
│ Select a session or create new       │
│──────────────────────────────────────│
│ [zellij] my-project                  │
│ [tmux] claude-team                   │
│ [tmux] dev-server                    │
│ [new] Ghostty (plain shell)          │
│ [new] tmux                           │
│ [new] zellij                         │
└──────────────────────────────────────┘

How It Works

Ghostty's command config launches the script on window open
The script lists existing zellij and tmux sessions
fzf lets you pick — attach to an existing session or create a new one
Esc/Ctrl+C cancels and drops you into a plain shell

Installation

The script is on GitHub: ghostty-session-picker

curl -fsSL https://raw.githubusercontent.com/coa00/ghostty-session-picker/main/ghostty-session-picker \
  -o ~/.local/bin/ghostty-session-picker
chmod +x ~/.local/bin/ghostty-session-picker

Add one line to your Ghostty config:

# ~/.config/ghostty/config
command = /Users/you/.local/bin/zellij-sessionizer

To enable working directory restore, add this to ~/.zshrc:

chpwd() {
  echo "$PWD" > ~/.last_working_dir
}

Wrap Up

There's no single "best terminal for Claude Code." The right choice depends on what you're doing — so rather than picking one, I built a system to choose every time.

Personally, after investing time in tmux configuration, I now primarily use Ghostty + tmux. Beyond Agent Teams split panes, tmux handles session persistence and status line display — consolidating everything into one setup. That said, this comes down to how much you invest in configuration and what you prioritize. The comparison should help you find the right fit for your workflow.

References

ghostty-session-picker — fzf session selector
Ghostty — GPU-accelerated terminal
iTerm2 — macOS terminal
tmux — terminal multiplexer
zellij — Rust-based terminal workspace
fzf — command-line fuzzy finder
Claude Code — Anthropic's official CLI
Agent Teams — Claude Code's parallel agent feature
Status Line — Claude Code status display
tmux-resurrect — session save/restore plugin
tmux-continuum — automatic session saving
it2 CLI — iTerm2 split-pane CLI tool

I Enabled Aurora Data API and My AI Agent Started Querying the Database Directly

Kohei Aoki — Mon, 02 Mar 2026 11:23:07 +0000

I see Data API less as an infrastructure improvement and more as a tool that changes how the team works. Whether your AI tools can directly access the database makes an order-of-magnitude difference in debugging and data verification speed.

We enabled one AWS feature — Aurora Data API — and our AI coding tools could suddenly query the database. No bastion host, no port forwarding, no copy-pasting query results. Here's what that actually looks like in practice, and what you need to enable it.

TL;DR

Data API is an HTTPS-based SQL execution API built into Aurora. Enabling it costs virtually nothing
It complements SSM bastion hosts — use both
Once enabled, Claude Code / Cursor can query your DB directly via shell commands or MCP
Reduces team learning curve, simplifies bastion operations, and accelerates automation
If you're running Aurora, there's no reason not to enable it

AI Coding Tool Integration: How Data API Changes Team Development

Let me start with the payoff — this is where Data API had the biggest impact for us.

Shell-Based Tool Use: Claude Code Runs AWS CLI Directly

With the traditional bastion host setup — a dedicated EC2 instance you SSH into (or tunnel through) to reach your private database — AI tools accessing the database was effectively impossible. SSH port forwarding + MySQL client connection is a workflow designed for humans operating manually.

With Data API, a single shell command — aws rds-data execute-statement — executes SQL over HTTPS. That means Claude Code can run this command through its built-in Bash tool (which lets it execute shell commands on your behalf) to query and modify your database directly.

# Example: what Claude Code actually runs
aws rds-data execute-statement \
  --resource-arn "arn:aws:rds:ap-northeast-1:xxx:cluster:dev-cluster" \
  --secret-arn "arn:aws:secretsmanager:ap-northeast-1:xxx:secret:dbsecret" \
  --database "my_database" \
  --sql "SHOW TABLES" \
  --profile dev

This is the AI agent using a shell tool — it constructs and executes CLI commands, then parses the text output. It works, and it unlocks workflows like:

Debugging — a multi-step agentic loop:

"Check the staging users table for records where status is null"
Claude Code queries via Data API → finds 12 orphaned records
It reasons about the cause, issues a follow-up query on the user_sessions table
Identifies a race condition in the cleanup job → suggests a fix with a migration SQL

Migration authoring:
"Look at the current schema in dev and write a migration SQL for this spec" → auto-fetches current table definitions → generates diff SQL.

Data checks:
"How many records are in the production offices table, and when was the last update?" → instant answer.

Previously, a developer had to manually query through the bastion, copy-paste the results back to the AI, wait for analysis... Data API eliminates the human as the bottleneck in this loop.

MCP-Based Structured Tool Use: Natural Language DB Access

The second integration pattern is more powerful. MCP (Model Context Protocol) lets AI tools like Cursor and Claude Code connect to external data sources through typed, schema-defined interfaces. Instead of parsing free-form CLI output, the agent receives structured data with column names and types — making its actions more reliable and predictable.

The official MySQL MCP Server from AWS Labs uses Data API internally. Here's how to wire it up:

{
  "mcpServers": {
    "awslabs.mysql-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.mysql-mcp-server@latest",
        "--resource_arn", "<cluster-arn>",
        "--secret_arn", "<secret-arn>",
        "--database", "<db-name>",
        "--region", "ap-northeast-1",
        "--readonly", "True"
      ],
      "env": {
        "AWS_PROFILE": "dev",
        "AWS_REGION": "ap-northeast-1"
      }
    }
  }
}

Change ap-northeast-1 to your AWS region.

Once configured, you can query from Cursor or Claude Code using natural language:

"How many support tickets came in this month?"
"Show me all active users created in the last 30 days"
"Which records were updated in the last 7 days?"

Guardrails for Production Use

With AI tools querying your database, safety matters. Here's our approach:

--readonly True in MCP config: Restricts the MCP server to SELECT-only queries. This is enforced at the MCP server level, but should not be your only line of defense.
Read-only DB user: Create a dedicated database user with SELECT-only privileges and store those credentials in a separate Secrets Manager secret. Use this secret for AI tool access — not the application's read-write credentials.
IAM policy scoping: Restrict the IAM role to rds-data:ExecuteStatement and secretsmanager:GetSecretValue on the specific read-only secret ARN.
CloudTrail audit trail: Every Data API call is logged in CloudTrail, including the SQL statement. This gives you post-hoc observability of everything the agent executed.
Human-in-the-loop for writes: Removing the human from read queries is a productivity win. For write operations, the human-as-bottleneck is actually the safety mechanism. Keep approval workflows for any non-read access.

Note on prompt injection: If your database contains user-generated content, be aware that query results could include text designed to manipulate the agent's next action. Use parameterized queries through the Data API to mitigate injection risks.

Team Learning Curve Drops Dramatically

This one matters if you're leading a team.

What team members previously had to learn for DB access:

AWS SSO login workflow
AWS Systems Manager (SSM) Session Manager installation and configuration
Port forwarding concepts and execution
MySQL client installation and connection setup
Retrieving passwords from Secrets Manager

With Data API + AI tools:

AWS CLI profile setup (most engineers already know this)
"Show me the data for X" → ask the AI

Five steps become effectively one. For onboarding, it's now "Log in with AWS SSO, then just ask Claude" — and that's it.

The barrier for non-infrastructure engineers and frontend developers who just want to "quickly check some data" drops dramatically.

Reduced Operational Burden

For small teams, the potential to eliminate bastion host maintenance is a significant win.

Complete bastion elimination depends on your team's needs — bulk data exports and complex investigations still benefit from SSM. But the majority of day-to-day "let me quickly check this data" or "update a few records" use cases can be handled by Data API.

As bastion usage drops, you can justify switching from always-on to on-demand — further reducing costs and maintenance.

What Is RDS Data API?

RDS Data API lets you execute SQL against Aurora via HTTPS REST calls.

Traditional database connections rely on the MySQL wire protocol over TCP/IP. Data API replaces that with standard HTTP requests through the AWS SDK or CLI. No VPC required — which also means faster Lambda cold starts, simpler networking, and no ENI provisioning delays.

Supported Engines and Limitations

Data API is Aurora-only. Standard RDS is not supported.

Engine	Data API Support
Aurora MySQL (v3.07+)	Supported
Aurora PostgreSQL (v13.12+, 14.9+, 15.4+)	Supported
Standard RDS MySQL / PostgreSQL	Not supported

Key limitations:

Constraint	Value
Response size	1 MB max per request
Row size	64 KB max per row
Timeout	45 seconds max per request
Multi-statement	Not supported on MySQL
Target	Writer instance only

The 1 MB response limit means Data API isn't suited for bulk SELECTs or data exports. That's where the SSM bastion still earns its keep.

Note on multi-statement: If your CI/CD migration tool (Flyway, Liquibase, etc.) uses multi-statement SQL files, you'll need to split statements or use a wrapper for MySQL.

Pricing

Enabling is free. Usage costs $0.35 per million requests.

1,000 SQL executions per month = $0.00035. Not exactly a budget consideration.

Data API vs SSM Session Manager

This was the decision point I wrestled with most. The answer: it's not either/or — it's both.

Use Case Breakdown

Use Case	Data API	SSM Bastion
Lambda → DB operations	Ideal (no VPC needed)	Not possible
CI/CD migrations	Good fit	Possible but complex
Scheduled batch scripts	Good fit (IAM auth)	Requires session management
Application integration	Ideal (pure HTTP)	Poor fit
Manual data investigation	Limited	Ideal (GUI tools)
Bulk data export	Poor fit (1 MB limit)	Ideal
Emergency manual UPDATEs	Possible but clunky	Ideal

Operational Cost Comparison

Factor	Data API	SSM Bastion
Initial setup	Near-zero (one console click)	EC2 + SSM + security group config
Monthly cost	~$0	$3-8/mo (t4g.nano always-on)
Maintenance	None (fully managed)	OS patches, SSM Agent updates
Audit logging	CloudTrail auto-records all queries	Dual management: CloudTrail + DB audit logs
Connection management	None (no persistent connections)	max_connections tuning required

The annual cost of a bastion host ($36-96) looks small on paper, but factor in the human cost of OS patching, SSM Agent updates, and recovery when the instance goes down — it adds up fast, especially for small teams.

Security Comparison

Factor	Data API	SSM Bastion
Attack surface	HTTPS (IAM-protected)	SSM only (no inbound ports)
Credential management	Secrets Manager (auto-rotation)	DB password stored locally
Access control	IAM policies control API calls	Dual management: SSM permissions + DB user permissions

Data API delegates credentials entirely to Secrets Manager, meaning developers never need to know the DB password. That's a significant security win.

How to Enable It

Prerequisites

Requirement	Details
DB engine	Aurora MySQL v3.07+ or Aurora PostgreSQL v13.12+
Instance class	Any class except T instances (for provisioned; Serverless v2 is unaffected)
Secrets Manager	DB credentials must be stored

If you're on standard RDS, Data API isn't available. Whether to migrate to Aurora for Data API alone depends on the other benefits (Serverless v2 autoscaling, etc.).

CLI

# For Serverless v2 / Provisioned clusters
aws rds enable-http-endpoint \
  --resource-arn <cluster-arn> \
  --profile <profile>

Important: For Serverless v2 / Provisioned clusters, use enable-http-endpoint. The modify-db-cluster --enable-http-endpoint command is for Serverless v1 only (now end-of-life). The docs are confusing on this — watch out.

Verification

aws rds-data execute-statement \
  --resource-arn "<cluster-arn>" \
  --secret-arn "<secret-arn>" \
  --database "<db-name>" \
  --sql "SELECT 1 AS test" \
  --profile <profile>

# → {"records": [[{"longValue": 1}]], "numberOfRecordsUpdated": 0}

Preventing CDK Drift

If you enable via CLI without updating your CDK code, the next deploy might reset it to false.

const cluster = new rds.DatabaseCluster(this, 'Cluster', {
  engine: rds.DatabaseClusterEngine.auroraMysql({
    version: rds.AuroraMysqlEngineVersion.VER_3_08_0,
  }),
  // ... existing config ...
  enableDataApi: true,  // ← Add this
});

Always update your CDK code alongside the CLI enablement. If CDK drift reverts the setting, any MCP servers or automation scripts that depend on Data API will break simultaneously.

Risk Assessment

Enabling Data API carries virtually zero risk.

No impact on existing applications or database connections
Even when enabled, access requires IAM permissions
Can be disabled instantly with a single command
Cost is effectively zero

The only caveat: prevent CDK drift. If you forget to add enableDataApi: true to your code, the next deploy reverts the setting.

Should You Enable It?

If you're running Aurora, enabling Data API is one of those "no reason not to" improvements.

Near-zero risk and cost to enable
Complements SSM bastion for full use-case coverage
AI coding tool integration accelerates the entire team
Directly reduces learning curve and operational overhead

"You don't need to know the DB password. You don't need to set up port forwarding. You just ask Claude." — That's the new onboarding experience.

If you have Aurora clusters that haven't enabled it yet, start with your dev environment. One command, five seconds.

Are you already using Data API with AI tools? Or still running bastion hosts for everything? I'd love to hear what your team's setup looks like — drop a comment below.

References

How I Solved DynamoDB + Amplify Search Problem with OpenSearch for $27/Month Instead of Migrating to Aurora

Kohei Aoki — Sat, 28 Feb 2026 09:05:22 +0000

TL;DR: One OpenSearch instance. $27/month. DynamoDB search and multi-tenancy — solved.

We Were About to Migrate to Aurora

I had the Aurora estimate ready. I was planning to rewrite our Amplify Data models into SQL schemas.

We had two problems. The first was search — once filter conditions exceeded 5 fields, DynamoDB's Query/Scan couldn't keep up. Full-text search was simply impossible. The second was multi-tenancy — we needed to safely isolate data across multiple products and multiple environments (staging / prod / sandbox). With Amplify Gen2's sandbox spinning up per-developer environments, naively adding a search engine would multiply instances and blow up costs.

In the end, we didn't migrate to Aurora. We added OpenSearch as a "search layer" alongside DynamoDB, and used index naming conventions to consolidate multiple products and environments into a single instance. The additional cost: $27/month — a 94% reduction from the $432/month we would have spent on per-environment instances. Both search and multi-tenancy, solved.

This article shares how we implemented this in a real-world real estate tech product running on Amplify Gen2.

The Pain Points of DynamoDB-Only

We're running a real estate tech product built on Amplify Gen2. Property and lot data lives in DynamoDB, with search and listing features for users. Multiple products share the same AWS account, each with staging, prod, and per-developer sandbox environments.

Early on, DynamoDB Query with GSIs (Global Secondary Indexes) was fine. But as the product grew, we hit walls on both search and multi-tenancy.

Search Problems

1. Complex Filter Conditions Don't Scale

Real estate search means combining "area + price range + floor size + walking distance to station + building age" — easily 5+ conditions. DynamoDB Query only filters on partition key and sort key.

You can add FilterExpression for extra conditions, but filters apply after the Query runs. So you might fetch 1,000 records just to filter down to 10. That's wasteful.

2. No Full-Text Search

Searching for "Shibuya office pet-friendly" is impossible in DynamoDB. The contains operator exists but requires a full Scan — not practical at scale.

3. Inflexible Sorting and Pagination

DynamoDB sorting depends on the sort key. Switching between "sort by price," "sort by size," and "sort by newest" each requires a separate GSI. The GSI limit is 20, but once you factor in filter combinations, it's nowhere near enough.

Pagination is cursor-based only (ExclusiveStartKey) — you can't jump directly to page 3.

Multi-Tenancy Problems

4. Data Isolation Across Products and Environments

Our products share Amplify backend patterns. DynamoDB naturally isolates data by table, so cross-product contamination isn't an issue there.

The problem emerges when you add a search engine. If you create a separate search instance per product and environment, instances multiply fast: 2 products x 3 environments (staging / prod / sandbox) = 6 instances. With 5 developers, sandbox alone means 10 instances. At $27 each: $432/month — just for adding search.

5. Amplify Sandbox Proliferation

Amplify Gen2's npx ampx sandbox creates isolated environments per developer. This works perfectly for DynamoDB, but it's devastating for always-on services like OpenSearch. Each sandbox creates an instance, takes minutes to boot, and if someone forgets to shut it down, costs pile up.

Keep DynamoDB, Add a Search Layer

"If search is the problem, just migrate to an RDB" — we considered it seriously. Aurora Serverless v2 is the strongest managed RDB option on AWS. But even with Aurora, multi-tenancy still needs separate design work, and we didn't see enough upside to justify abandoning DynamoDB + Amplify's developer experience.

Cost Comparison

	DynamoDB + OpenSearch	Aurora Serverless v2
Monthly cost (min config)	DynamoDB: pay-per-use (~$5) + OpenSearch t3.small: ~$27	Min 0.5 ACU: ~$60–70 (Tokyo region)
Total	~$30–50/month	~$60–100/month
Storage	DynamoDB: $0.25/GB + OpenSearch: $0.122/GB (gp3)	$0.12/GB (Aurora storage)
Scaling	DynamoDB: auto-scale, OpenSearch: fixed instance	ACU-based auto-scaling

Aurora Serverless v2 charges even at minimum 0.5 ACU. In Tokyo region, that's ~$0.20/hour × 0.5 ACU × 730 hours = ~$73/month — even when idle.

DynamoDB is pay-per-use (nearly zero when idle), and OpenSearch t3.small.search runs at ~$27/month. Combined, it's less than half of Aurora.

Amplify Compatibility

Amplify Gen2 uses DynamoDB as its default data store. Define your schema with defineData() and GraphQL APIs + DynamoDB tables are auto-generated. This developer experience is excellent.

Migrating to Aurora means giving that up: self-managed SQL schemas, migrations, ORM configuration. Keeping DynamoDB as the primary data store and adding OpenSearch as a search layer minimizes architectural changes.

Search Performance

OpenSearch is purpose-built for search: full-text search, faceted search, geo search, scoring — all things Aurora's LIKE clause or full-text indexes can't match. For complex real estate search with many filter combinations, OpenSearch is the clear winner.

Architecture: DynamoDB Streams + Lambda + OpenSearch

The architecture is straightforward:

[DynamoDB] → DynamoDB Streams → [Lambda] → [OpenSearch]
                                                ↑
                                        Search API reads from here

Data Flow

Write: App writes to DynamoDB as before (Amplify Data models unchanged)
Sync: DynamoDB Streams detects changes and triggers a Lambda function
Index: Lambda upserts/deletes documents in OpenSearch
Search: Search API queries OpenSearch and returns results

The key benefit: zero changes to the existing write path. DynamoDB CRUD goes through Amplify's GraphQL API as always — only search reads from OpenSearch.

Sync Lambda (Conceptual)

// DynamoDB Streams → Lambda → OpenSearch
export const handler = async (event: DynamoDBStreamEvent) => {
  for (const record of event.Records) {
    const tableName = extractTableName(record.eventSourceARN);
    const indexName = tableToIndex(tableName); // Table name → index name mapping

    switch (record.eventName) {
      case 'INSERT':
      case 'MODIFY':
        await opensearchClient.index({
          index: indexName,
          id: record.dynamodb.Keys.id.S,
          body: unmarshall(record.dynamodb.NewImage),
        });
        break;
      case 'REMOVE':
        await opensearchClient.delete({
          index: indexName,
          id: record.dynamodb.Keys.id.S,
        });
        break;
    }
  }
};

Search Query: Before / After

Before: DynamoDB (multi-condition filtering)

// DynamoDB: Partition key + FilterExpression workaround
const result = await dynamoClient.query({
  TableName: 'Properties',
  KeyConditionExpression: '#area = :area',
  FilterExpression: '#price BETWEEN :minPrice AND :maxPrice AND #size >= :minSize',
  ExpressionAttributeValues: { ':area': 'Shibuya', ':minPrice': 5000000, ':maxPrice': 10000000, ':minSize': 50 },
  // → Fetches 1,000 records, filters down to 10. Inefficient.
});

After: OpenSearch (same conditions + full-text search + sort)

// OpenSearch: Combine any conditions + full-text + sort in one query
const result = await opensearchClient.search({
  index: 'projectA-prod-properties',
  body: {
    query: {
      bool: {
        must: [
          { match: { description: 'pet-friendly office' } },  // Full-text search
          { term: { area: 'Shibuya' } },
          { range: { price: { gte: 5000000, lte: 10000000 } } },
          { range: { size: { gte: 50 } } },
        ],
      },
    },
    sort: [{ price: 'asc' }],  // Sort by any field
    from: 0, size: 20,         // Pagination
  },
});
// → Returns exactly 20 matching records. 100–200ms response time.

Full-text search + multi-condition filtering + sorting + pagination — all in one query. This was impossible with DynamoDB alone.

The Gotcha: Japanese Full-Text Search Doesn't Work by Default

The first thing that bit us after adding OpenSearch: Japanese full-text search returned zero results.

Searching for "Shibuya office" returned nothing. The root cause: OpenSearch's default analyzer (standard analyzer) doesn't support Japanese morphological analysis. "渋谷オフィス" (Shibuya Office) was treated as a single token, so partial matches failed.

The fix: configure ICU analyzer + kuromoji tokenizer when creating the index.

{
  "settings": {
    "analysis": {
      "analyzer": {
        "japanese_analyzer": {
          "type": "custom",
          "tokenizer": "kuromoji_tokenizer",
          "filter": ["kuromoji_baseform", "lowercase"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "description": { "type": "text", "analyzer": "japanese_analyzer" }
    }
  }
}

The moment we added this config, Japanese keyword search started working correctly. OpenSearch's Japanese search doesn't work out of the box — not knowing this was our biggest time waste.

Note for English-language deployments: If your data is English-only, the default standard analyzer works fine. The kuromoji tokenizer is specifically needed for CJK (Chinese/Japanese/Korean) text segmentation.

Operational Considerations

DynamoDB Streams + Lambda sync comes with a few operational caveats:

Sync latency: Streams → Lambda → OpenSearch propagation typically takes a few hundred ms to a few seconds. For screens requiring real-time data, add a fallback that reads directly from DynamoDB immediately after writes
Lambda error retries: If the Streams-triggered Lambda fails repeatedly, records can expire and be lost. Set up a DLQ (Dead Letter Queue) to catch failures. Note: DynamoDB Streams has a 24-hour retention window — if your Lambda is down for longer than that, events are permanently lost
Index rebuilds: When you change OpenSearch mappings, existing data needs re-indexing. Keep a script ready that does a full DynamoDB Scan → OpenSearch Bulk Insert

Multi-Tenancy Design: 1 Instance × Index Isolation

Search was solved. Next: multi-tenancy — how to safely isolate multiple products × multiple environments while keeping costs down.

Solution: Share One Instance, Isolate by Index

Instead of creating an OpenSearch instance per environment, we share a single instance across all environments and isolate by index name.

OpenSearch Domain (1 instance)
├── projectA-stg-properties     ← Product A staging properties
├── projectA-stg-sections       ← Product A staging lots
├── projectA-prod-properties    ← Product A prod properties
├── projectA-prod-sections      ← Product A prod lots
├── projectB-stg-properties     ← Product B staging properties
├── projectB-prod-properties    ← Product B prod properties
└── sandbox-{user}-properties   ← Sandbox (only when needed)

Key decisions:

No OpenSearch resources for sandbox — In CDK/Amplify backend definitions, skip OpenSearch resource creation for sandbox environments
Sandbox Lambda points to shared dev OpenSearch — Inject the OpenSearch endpoint and index name via environment variables. Sandbox either uses the stg instance or falls back to direct DynamoDB reads
Index names include project and environment — {project}-{env}-{entity} naming convention prevents collisions

This approach keeps OpenSearch instances at the absolute minimum (1 shared) while safely isolating data across multiple products and environments. What would have been $432/month with 16 instances is now $27/month with one.

What We Gained

Search

	Before (DynamoDB only)	After (DynamoDB + OpenSearch)
Filtering	GSI + FilterExpression (2–3 conditions max)	Combine any number of conditions
Full-text search	Not possible	Japanese morphological analysis supported
Sorting	Sort key dependent (needs GSI)	Sort by any field
Pagination	Cursor-based only	from/size for direct page jumps
Response time	Scan could take seconds	Complex queries in 100–200ms

Multi-Tenancy

	Before (separate instances)	After (1 instance × index isolation)
Instances	1 per product × environment	1 total
Monthly cost	Up to $432/month (16 instances)	$27/month (1 instance)
Sandbox startup	Wait for OpenSearch boot (minutes)	Skip (uses shared stg instance)
Data isolation	Instance-level	Index naming convention (logical)

Getting Started: 5 Steps

Create an OpenSearch domain — t3.small.search, single instance. ~$27/month
Create indexes with Japanese analyzer — Configure kuromoji tokenizer. Skip this and Japanese search won't work
Enable DynamoDB Streams — Set NEW_AND_OLD_IMAGES on target tables
Deploy sync Lambda — Streams-triggered Lambda that upserts/deletes to OpenSearch. Don't forget the DLQ
Add a search API — Query OpenSearch from a new endpoint. Keep existing DynamoDB CRUD APIs untouched

When your GSI count exceeds 5, or your FilterExpression hit rate drops below 10% — that's when to consider adding OpenSearch.

Wrapping Up

We were ready to migrate to Aurora. We had the estimate. But in the end, we didn't need to abandon DynamoDB.

One OpenSearch instance solved both search and multi-tenancy. Writes go to DynamoDB, search reads from OpenSearch. DynamoDB Streams + Lambda keeps them in sync. Index naming ({project}-{env}-{entity}) consolidates multiple products and environments into a single instance. Amplify Gen2's DynamoDB-centric developer experience stays intact, and search capabilities scale independently.

The beauty of this "patch the weakness" approach: you don't have to rewrite your architecture all at once. Start with DynamoDB. When search requirements grow, add OpenSearch. When products multiply, add indexes. At $27/month, there was no reason to migrate to Aurora.

When NOT to Use This Approach

This pattern isn't universal. Consider a full RDB migration if you need complex relational queries across entities, ACID transactions spanning multiple tables, or your search requirements involve heavy aggregations that OpenSearch alone can't serve back to the write path. If your product is SQL-first from the start, don't force DynamoDB into the picture just to save a few dollars.

But if you're already running DynamoDB and your pain is search — try patching the weakness with OpenSearch before rewriting everything. The best architecture isn't always the newest one. Sometimes it's the cheapest complement to what you already have.

References

How I Built a Mobile Approval System for Claude Code So I Can Finally Leave My Desk

Kohei Aoki — Sat, 28 Feb 2026 06:01:30 +0000

TL;DR: Claude Code hooks + ntfy.sh = approve/deny permissions from your phone. 60 lines of bash, 3-minute setup, open source.

The Problem Every AI Coding Agent User Faces

I came back with my coffee and found Claude Code had been frozen for 15 minutes.

As AI coding agents gain autonomy — writing code, running builds, modifying files — the question of human oversight becomes critical. You want the agent to keep working, but you also want to know what it's doing. The permission prompt is the checkpoint, but it's also the bottleneck.

Sure, you can add commands to the allowlist to reduce prompts, but blanket-approving unknown commands and file writes is risky. On the other hand, staying glued to your terminal isn't realistic either.

So I built claude-push — an async human-in-the-loop approval layer for Claude Code. It uses PermissionRequest hooks and ntfy.sh to send Allow/Deny push notifications straight to your phone. Open source, 3-minute setup.

The Dilemma: Stay at Your Desk or Allow Everything

When you delegate code generation and refactoring to Claude Code, you'll inevitably see prompts like this:

Claude wants to run: rm -rf dist && npm run build
Allow? (y/n)

Every time this pops up, you have to go back to the terminal and hit y. If you're deep in focus (or just grabbing coffee), you miss it and Claude Code sits there doing nothing.

Approach	Pros	Cons
Manual approval in terminal	Safe	Can't leave your desk
Allowlist everything	Convenient	Unknown commands get through
Mobile push notifications	Away from desk + safe	Requires setup

claude-push makes option 3 a reality.

Prior Art

konsti-web/claude_push tackled this same problem, but it's Windows + PowerShell + keystroke injection — doesn't work on macOS or Linux. I had the same pain point, so I rebuilt the concept from scratch using bash + PermissionRequest hooks.

How It Works: PermissionRequest Hook + ntfy.sh

Claude Code has a Hooks system that lets you run external scripts on specific events. By registering a hook on the PermissionRequest event, you can intercept the permission prompt and return your own decision.

Here's the full flow:

Claude Code requests permission
  → Hook script fires
    → Sends notification with Allow/Deny buttons to ntfy.sh
      → Phone receives the push notification
        → You tap Allow or Deny
          → Response received via ntfy.sh SSE
            → Hook returns allow/deny JSON
              → Claude Code continues or stops

ntfy.sh is a free, HTTP-based push notification service. No account required — if you know the topic name, you can send and receive notifications. Unlike Pushover or LINE Notify, you can send a notification with a single curl command, which makes it a perfect fit for hook scripts.

Implementation Details

The hook script is about 60 lines of bash. Here are the three key design decisions.

1. Using ntfy.sh HTTP Actions for Buttons

ntfy.sh supports Action Buttons on notifications. I'm using http actions so that tapping a button POSTs to a separate response topic.

curl -s -H "Content-Type: application/json" \
  -d "$(jq -n \
    --arg topic "$TOPIC" \
    --arg title "[$PROJECT] $TOOL_NAME" \
    --arg message "$TOOL_INPUT" \
    --arg allow_url "https://ntfy.sh/${RESPONSE_TOPIC}" \
    --arg allow_body "allow|$REQ_ID" \
    --arg deny_url "https://ntfy.sh/${RESPONSE_TOPIC}" \
    --arg deny_body "deny|$REQ_ID" \
    '{
      topic: $topic, title: $title, message: $message,
      priority: 4, tags: ["lock"],
      actions: [
        {action:"http",label:"Allow",url:$allow_url,method:"POST",body:$allow_body},
        {action:"http",label:"Deny",url:$deny_url,method:"POST",body:$deny_body}
      ]
    }')" "https://ntfy.sh/"

The key detail: the notification topic and the response topic are separate channels. This prevents the SSE stream from being polluted by your own outgoing notifications.

2. SSE + Request ID for Response Matching

After sending the notification, the hook waits for a response on the ntfy.sh SSE endpoint.

REQ_ID="$(date +%s)-$$"

while IFS= read -r line; do
  if [[ "$line" == data:* ]]; then
    DATA="${line#data: }"
    MSG=$(echo "$DATA" | jq -r '.message // empty' 2>/dev/null)
    if [[ "$MSG" == *"|$REQ_ID" ]]; then
      DECISION="${MSG%%|*}"
      break
    fi
  fi
done < <(curl -s -N --max-time "$WAIT_TIMEOUT" \
  -H "Accept: text/event-stream" \
  "https://ntfy.sh/${RESPONSE_TOPIC}/sse")

The REQ_ID (timestamp + PID) is embedded in the notification body and matched against the response. This ensures that even when multiple permission requests fire simultaneously, each response is matched to the correct request. Without this, you could accidentally apply a previous notification's response to a new one.

3. Timeout Fallback to Terminal

If no response comes within the timeout window, the script outputs nothing and exits with code 0.

if [ "$DECISION" = "allow" ]; then
  jq -n '{hookSpecificOutput:{...decision:{behavior:"allow"}}}'
elif [ "$DECISION" = "deny" ]; then
  jq -n '{hookSpecificOutput:{...decision:{behavior:"deny"}}}'
fi
# Timeout: no output → falls back to interactive prompt

In Claude Code's hook specification, no output + exit 0 means "the hook didn't make a decision," which falls back to the standard terminal prompt. So even if you're not looking at your phone, you can still handle it from the terminal after the timeout. No permissions are silently granted.

Setup

Prerequisites

macOS or Linux
bash, jq, curl installed
ntfy app installed on your phone

Installation

git clone https://github.com/coa00/claude-push.git
cd claude-push
bash install.sh

The installer walks you through:

Dependency check — verifies jq and curl are available
Topic name input — generates a random one if left blank (claude-push-a1b2c3d4)
Config file creation — writes to ~/.config/claude-push/config
Hook deployment — places script at ~/.local/share/claude-push/hooks/claude-push.sh
Claude settings registration — safely merges the hook into ~/.claude/settings.json using jq
Test notification — sends a test push to verify everything works

After installation, subscribe to your topic in the ntfy app and you're good to go.

Configuration

Edit ~/.config/claude-push/config. No reinstallation needed.

# Topic name (acts as a shared secret for your ntfy.sh channel)
CLAUDE_PUSH_TOPIC="my-unique-topic"

# Timeout in seconds (falls back to terminal prompt after this)
CLAUDE_PUSH_TIMEOUT=90

Verification

# Send a test notification with Allow/Deny buttons
bash scripts/test.sh test-notify

# Check installation status
bash scripts/test.sh status

The status command checks Config / Hook / Settings / Dependencies:

=== claude-push status ===
[OK] Config: ~/.config/claude-push/config
     Topic: my-unique-topic
     Timeout: 90s
[OK] Hook: ~/.local/share/claude-push/hooks/claude-push.sh
[OK] Settings: hook registered in ~/.claude/settings.json
[OK] Dependency: jq
[OK] Dependency: curl

Uninstall

bash uninstall.sh

Removes the hook from Claude settings and cleans up all installed files.

What It Looks Like in Practice

After setup, my daily workflow looks like this:

Tell Claude Code to refactor something, then leave my desk
A few minutes later, my phone buzzes: [myproject] Bash: npm run build
I check the command and tap Allow
When I get back to my desk, the build is already done

I can handle permission requests during meetings, walks, or coffee runs — as long as I have my phone.

Before / After

	Before	After
Approval method	`y`/`n` in terminal	Allow/Deny on phone
While away	Claude Code stops and waits	Handle via push notification
Timeout	None (waits forever)	Falls back to terminal after 90s
Security	Allowlist or manual check	Case-by-case approval per notification
Setup cost	—	`bash install.sh` in 3 minutes

Security Considerations

The ntfy.sh topic name acts as a shared secret. Anyone who knows the topic name can send notifications or forge responses.

Use a random, hard-to-guess string for your topic name (the installer generates one by default)
For stricter control, configure ntfy.sh access control
For dangerous commands (rm -rf, etc.), keep them explicitly blocked in your allowlist as an extra safety layer

Wrapping Up

Claude Code's permission system used to be a binary choice: either babysit your terminal or allowlist everything. claude-push adds a third option — mobile approval.

The implementation is deliberately boring: bash + ntfy.sh HTTP Actions + SSE. The hook itself is about 60 lines. What made this possible is Claude Code's well-designed Hooks API — you just return a JSON object with allow or deny and you're done.

The broader pattern here applies to any AI coding agent, not just Claude Code: as agents get more capable, we need lightweight, async approval mechanisms that don't require us to sit and watch. Mobile push notifications hit the sweet spot — fast enough to keep the agent moving, visible enough to maintain oversight.

The best developer tool is the one that lets you stop staring at a screen for 5 minutes. claude-push is that tool.

How do you handle AI agent permissions? Whether you're an allowlist person or a manual-check person, I'd love for you to give this a try.

https://github.com/coa00/claude-push

References

Claude Code Hooks Documentation
ntfy.sh — HTTP-based push notification service
ntfy.sh Action Buttons
konsti-web/claude_push — Original inspiration (Windows/PowerShell version)

DEV Community: Kohei Aoki

How a Custom Docker Image Made My AWS Amplify Builds 10–20% Faster (and Killed Flaky Build Failures)

Intro

Why I built a custom build image

The trigger: a midnight build failure

The multi-stage Dockerfile design

The base image mistake I made

What's in the image

Lock down the pnpm store path across every context

Simplifying amplify.yml

Before

After

The numbers

Your framework caps your ceiling

Three wins bigger than the minute of speedup

1. Build failures dropped to zero

2. The "which Node version are we on?" question went away

3. The next project gets the payoff

Bonus: it works in GitHub Actions too

Operational tips

The NODE_OPTIONS trap

Assume rsync doesn't exist

Try the public image yourself

Takeaways

References

How I Use 4 Terminal Setups with Claude Code Agent Teams

Introduction

What I Need from a Terminal

Comparing 4 Setups

Ghostty — Fastest, Zero Config

iTerm2 — Feature-Rich, No Setup Required

Ghostty + tmux — Extensible with Config and Plugins

Ghostty + zellij — Built-in Features

Recommendations by Use Case

Configuration for Ghostty + tmux/zellij

tmux: Shift+Enter Fix

tmux: Session Persistence

tmux: Claude Code Status Line

zellij: Session Persistence

Ghostty: Keybinding Adjustments (Shared)

fzf Session Picker

How It Works

Installation

Wrap Up

References

I Enabled Aurora Data API and My AI Agent Started Querying the Database Directly

TL;DR

AI Coding Tool Integration: How Data API Changes Team Development

Shell-Based Tool Use: Claude Code Runs AWS CLI Directly

MCP-Based Structured Tool Use: Natural Language DB Access

Guardrails for Production Use

Team Learning Curve Drops Dramatically

Reduced Operational Burden

What Is RDS Data API?

Supported Engines and Limitations

Pricing

Data API vs SSM Session Manager

Use Case Breakdown

Operational Cost Comparison

Security Comparison

How to Enable It

Prerequisites

CLI

Verification

Preventing CDK Drift

Risk Assessment

Should You Enable It?

References

How I Solved DynamoDB + Amplify Search Problem with OpenSearch for $27/Month Instead of Migrating to Aurora

We Were About to Migrate to Aurora

The Pain Points of DynamoDB-Only

Search Problems

1. Complex Filter Conditions Don't Scale

2. No Full-Text Search

3. Inflexible Sorting and Pagination

Multi-Tenancy Problems

4. Data Isolation Across Products and Environments

5. Amplify Sandbox Proliferation

Keep DynamoDB, Add a Search Layer

Cost Comparison

Assume `rsync` doesn't exist