When WidelAI needed a modern blog to complement their AI platform, the team at Lushbinary chose EmDash — Cloudflare's open-source CMS built on Astro — and deployed it on AWS. This post walks through the architecture decisions, the infrastructure we built with Terraform, the CI/CD pipeline, and the lessons learned running EmDash in production on EC2 instead of Cloudflare Workers.

EmDash launched on April 1, 2026 as a spiritual successor to WordPress. It's written entirely in TypeScript, uses Astro 6 as its rendering engine, stores content in SQLite, and ships with sandboxed plugins, a built-in admin UI, and native MCP server support for AI agents. While Cloudflare designed it to run on Workers with D1, EmDash also runs on any standard Node.js environment — which is exactly what we leveraged for WidelAI.

1Why EmDash Over WordPress or a Headless CMS

WidelAI already had a Next.js frontend at widelai.com and a Node.js backend on EC2. Adding WordPress would have meant managing PHP, MySQL, and an entirely separate stack. A headless CMS like Contentful or Sanity would have added a third-party dependency and recurring SaaS costs.

EmDash fit the bill because:

2Architecture Overview

The WidelAI infrastructure runs entirely in us-east-1 on AWS. The backend API and EmDash CMS share the same EC2 instance inside an Auto Scaling Group, each running as a separate Docker container.

3Terraform Infrastructure

All infrastructure is managed with Terraform using workspace-based environment isolation. The dev and prod workspaces share the same module but differ in configuration:

When enable_emdash is true, Terraform provisions the ECR repository reference and passes the EmDash configuration into the EC2 user data script. The instance bootstraps both the backend API container and the EmDash container on startup.

Environment Isolation

4The EmDash Bootstrap Script

The heart of the deployment is a shell script that runs during EC2 instance initialization. It's stored in S3 and downloaded by the instance's user data on boot. Here's what it does:

1. Stops any existing EmDash container — Handles redeployments and ASG instance replacements cleanly
2. Restores SQLite from S3 — If a backup exists, it syncs the database from S3 to the local volume before starting EmDash. A fresh instance picks up right where the previous one left off
3. Pulls the Docker image from ECR — Authenticates with ECR and pulls the latest EmDash image with retry logic (up to 5 attempts)
4. Starts the container — Runs EmDash with --restart=always, host networking, and the SQLite data directory mounted as a volume
5. Configures S3 backup cron — Sets up a cron job that syncs the SQLite database to S3 every 5 minutes

Key decisions in this setup:

• Host networking — Avoids Docker bridge overhead and simplifies port management since the instance runs behind an Elastic IP anyway
• Volume mount for data — The /home/ec2-user/emdash-data directory persists across container restarts. SQLite writes go to EBS, not the container's ephemeral filesystem
• ARM64 platform — Graviton instances (t4g) offer better price-performance. The Docker image is built for linux/arm64 using QEMU and Buildx in CI

5CI/CD Pipeline with GitHub Actions

The deployment pipeline is triggered on pushes to dev or main branches. It builds a multi-architecture Docker image, pushes it to ECR, and deploys to the running EC2 instance via AWS Systems Manager (SSM) — no SSH required.

Pipeline Steps

1. Checkout code and determine environment (dev or prod) based on branch
2. Configure AWS credentials using GitHub Secrets
3. Set up QEMU + Docker Buildx for ARM64 cross-compilation
4. Build and push the Docker image to ECR with both a commit SHA tag and latest
5. Deploy via SSM — Sends a shell command to the EC2 instance that pulls the new image, stops the old container, and starts the new one
6. Poll for completion — Waits up to 5 minutes for the SSM command to succeed, with detailed error output on failure

6SQLite Backup Strategy

EmDash uses SQLite as its database, which is a single file on disk. This simplifies operations enormously but requires a solid backup strategy since there's no managed database service handling it for you.

Our approach:

• Cron-based S3 sync every 5 minutes — A simple aws s3 sync with --size-only flag to avoid unnecessary uploads
• Restore on boot — When a new instance launches (ASG replacement, scaling event, or manual restart), the bootstrap script checks S3 for an existing backup and restores it before starting EmDash
• EBS snapshots via DLM — Daily and weekly disk snapshots provide an additional safety net beyond S3

7Self-Healing with Auto Scaling Groups

The EC2 instance runs inside an ASG with a desired capacity of 1. This isn't for scaling — it's for resilience. If the instance fails a health check, the ASG terminates it and launches a replacement automatically. The new instance:

1. Claims the Elastic IP on boot
2. Restores the EmDash SQLite database from S3
3. Pulls the latest Docker images from ECR
4. Starts both the backend API and EmDash containers

This self-healing behavior means we don't need to monitor the instance manually. AWS handles recovery, and the bootstrap script handles state restoration.

8Cost Breakdown

One of the biggest advantages of this architecture is cost. EmDash runs as a sidecar on an existing EC2 instance, so the incremental cost of adding the blog is minimal:

9EmDash on AWS vs. Cloudflare Workers

EmDash was designed for Cloudflare Workers with D1 (SQLite at the edge). So why did we deploy on AWS instead?

For WidelAI, keeping everything on AWS simplified operations. One Terraform codebase, one CI/CD pipeline pattern, one set of IAM policies, one monitoring stack. The blog didn't justify introducing a second cloud provider.

10Seed File and Content Schema

EmDash uses a seed.json file to define the content schema — collections, fields, taxonomies, menus, and widgets. For the WidelAI blog, we defined a posts collection with fields for title, slug, body (Portable Text), featured image, excerpt, author, and publish date. Taxonomies include categories and tags.

The seed file is validated with npx emdash seed seed/seed.json --validate and applied when the dev server starts. In production, the schema is baked into the Docker image, and content is managed through the admin UI.

11Lessons Learned

12Monitoring and Alerts

The existing WidelAI monitoring stack covers EmDash automatically:

Wrapping Up

Deploying EmDash on AWS for WidelAI turned out to be a clean, cost-effective solution. By running it as a Docker container alongside the existing backend, we added a full CMS with admin UI, Astro-powered theming, and automated backups — all for about $1/month in incremental infrastructure cost.

The combination of Terraform for infrastructure, GitHub Actions for CI/CD, and SSM for deployment gives us a repeatable, auditable pipeline. The self-healing ASG with S3-based SQLite backup means the blog recovers automatically from instance failures with minimal data loss.

If you're considering EmDash for your own project and already have AWS infrastructure, this pattern works well. The CMS is lightweight enough to share an instance with other services, and the SQLite-based storage eliminates the need for a separate managed database.

Need help deploying EmDash or building your cloud infrastructure? Get in touch with Lushbinary — we specialize in AWS architecture, AI integration, and modern web development.