DEV Community: Luqman Hakim

SonicJS Auth Gotchas on Cloudflare: Signup, Credentials, and RBAC - Part 3

Luqman Hakim — Sun, 26 Jul 2026 11:33:04 +0000

Someone tries to log in and you get one of:

Credential account not found
Login works, but You do not have permission to access this area
Random people registering themselves as editors

This post is the production auth/ops guide for SonicJS on Workers — the stuff that isn’t in the “hello deploy” tutorial.

1. Turn off public self-registration

For an internal CMS, open signup is a footgun. Disable Better Auth sign-up in app config:

import { createSonicJSApp, registerCollections } from '@sonicjs-cms/core'
import type { SonicJSConfig } from '@sonicjs-cms/core'
import blogPostsCollection from './collections/blog-posts.collection'

registerCollections([blogPostsCollection])

const config: SonicJSConfig = {
  plugins: { register: [] },
  auth: {
    extendBetterAuth: (opts) => ({
      ...opts,
      emailAndPassword: {
        ...opts.emailAndPassword,
        disableSignUp: true,
      },
    }),
  },
}

export default createSonicJSApp(config)

Admins create accounts in Admin → Users → Create New User (/admin/users/new). That path should create both:

the profile row (auth_user)
the Better Auth credential row (auth_account)

…so the new user can log in immediately.

2. Two password stores (this is the big one)

SonicJS login (Better Auth) reads credentials from auth_account.

Some UI/profile flows only update auth_user.password_hash.

If those diverge, you get:

Credential account not found

even though the user “exists” in the admin list.

Fix: reset password with a script that updates both

Prefer a CLI over the admin password form when login is broken:

ADMIN_EMAIL=you@example.com ADMIN_PASSWORD='your-new-password' npm run set-password:prod

That script should upsert the Better Auth credential row and keep the profile hash in sync.

For brand-new environments, seed once with env vars — never commit passwords:

ADMIN_EMAIL=you@example.com ADMIN_PASSWORD='your-secure-password' npm run seed:prod

A solid seed uses Wrangler’s platform proxy against production D1:

import { getPlatformProxy } from 'wrangler'

const useProduction = process.argv.includes('--remote')
const { env, dispose } = await getPlatformProxy({
  environment: useProduction ? 'production' : undefined,
  remoteBindings: useProduction,
})

// env.DB is your D1 binding — insert auth_user + auth_account, assign RBAC, etc.

Requirements for credentials:

Pass ADMIN_EMAIL / ADMIN_PASSWORD via env
Enforce min password length
Exit early if the admin already exists (idempotent seed)

3. RBAC ≠ `auth_user.role`

Even after login succeeds, /admin may show:

You do not have permission to access this area

Classic cause: the user has a string role on auth_user (e.g. editor), but no RBAC role assignment that grants portal:access.

Older admin UI flows sometimes wrote only auth_user.role. Portal access is enforced via RBAC.

Fix: promote the user

# default: editor with portal access
ADMIN_EMAIL=user@example.com npm run promote-user:prod

# full admin
ADMIN_EMAIL=user@example.com ROLE=admin npm run promote-user:prod

After you patch/upgrade core so “Create New User” assigns RBAC automatically, new users are fine — but existing accounts may still need a one-time promote.

4. Ops cheat sheet

Symptom	Likely cause	Fix
Anyone can register	Sign-up still enabled	`disableSignUp: true` in `extendBetterAuth`
“Credential account not found”	Missing/outdated `auth_account` row	`set-password:prod` for that email
Login OK, no portal access	Missing RBAC / `portal:access`	`promote-user:prod`
Seed failed: no DB binding	Wrong env / migrations	Check `wrangler.toml` production D1 + `remote = true`; run migrations
Auth weird after redeploy	Secrets missing/rotated badly	Re-put `BETTER_AUTH_SECRET` / `JWT_SECRET`

5. Beta packages and patches (optional honesty)

SonicJS moves fast (@sonicjs-cms/core betas). If you hit a framework bug in user-create or login UI, patch-package can unblock production while you wait for upstream:

{
  "scripts": {
    "postinstall": "patch-package"
  }
}

Keep patches small and documented. Prefer upstream upgrades when the fix lands — patches are a bridge, not a lifestyle.

6. Hardening checklist for a private CMS

[ ] Public signup disabled
[ ] First admin seeded via env (not hardcoded)
[ ] Create-user flow writes auth_user and auth_account
[ ] Editors/admins have RBAC with portal:access
[ ] Password resets go through a script that updates both stores
[ ] Production secrets set via wrangler secret put
[ ] Collections that should be public API opt in with access.public: ['read'] (from Part 1) — everything else stays private

Series wrap-up

Architecture — Workers + D1 + R2, schema-as-code collections
Deploy + CI/CD — secrets, migrate-then-deploy, GitHub Actions + /health
This post — signup lock, credential rows, RBAC

That’s a complete path from “edge CMS idea” to “team can log into /admin without Slack-debugging auth.”

If you ship something similar, start with SonicJS’s docs, then treat auth as a first-class production concern — not a day-two chore.

Further reading: SonicJS · Better Auth · Workers CI with GitHub Actions

Deploy a SonicJS CMS to Cloudflare Workers with GitHub Actions - Part 2

Luqman Hakim — Sun, 26 Jul 2026 11:30:25 +0000

This post covers production bindings, secrets, migrate-before-deploy, and a GitHub Actions workflow that typechecks, migrates D1, deploys the Worker, and smoke-checks /health.

Prerequisites

A SonicJS project that already runs locally with wrangler dev
Cloudflare account + Wrangler logged in once (npx wrangler login)
D1 database and R2 bucket created (or create them now)

npx wrangler d1 create my-cms-db
npx wrangler r2 bucket create my-cms-media

Paste the returned database_id into wrangler.toml.

Production env in wrangler.toml

Keep a default (local) section and a dedicated [env.production] block. Same bindings, production vars:

name = "my-cms"
main = "src/index.ts"
compatibility_date = "2024-09-23"
compatibility_flags = ["nodejs_compat"]

[[d1_databases]]
binding = "DB"
database_name = "my-cms-db"
database_id = "YOUR_DATABASE_ID"
migrations_dir = "./node_modules/@sonicjs-cms/core/migrations"

[[r2_buckets]]
binding = "MEDIA_BUCKET"
bucket_name = "my-cms-media"

[vars]
ENVIRONMENT = "development"
CORS_ORIGINS = "http://localhost:8787"
BUCKET_NAME = "my-cms-media"

[env.production]
name = "my-cms"
vars = { ENVIRONMENT = "production", CORS_ORIGINS = "https://my-cms.YOUR_SUBDOMAIN.workers.dev", BUCKET_NAME = "my-cms-media" }

[[env.production.d1_databases]]
binding = "DB"
database_name = "my-cms-db"
database_id = "YOUR_DATABASE_ID"
migrations_dir = "./node_modules/@sonicjs-cms/core/migrations"
remote = true

[[env.production.r2_buckets]]
binding = "MEDIA_BUCKET"
bucket_name = "my-cms-media"

Notes:

remote = true on the production D1 binding helps local scripts (seed:prod, password reset) talk to real D1 via getPlatformProxy. Deploy itself ignores that flag.
Put CORS origins in vars so your frontend can call the public API.
Never put secrets in [vars] — those end up in the Worker bundle metadata.

Secrets (auth won’t work without them)

SonicJS / Better Auth need secrets at runtime:

openssl rand -hex 32 | npx wrangler secret put BETTER_AUTH_SECRET --env production
openssl rand -hex 32 | npx wrangler secret put JWT_SECRET --env production

Rotate the same way later. Treat these like production passwords.

Manual deploy: migrate, then ship

npm scripts that match the mental model:

{
  "scripts": {
    "dev": "wrangler dev",
    "deploy": "wrangler deploy --env production",
    "db:migrate": "wrangler d1 migrations apply DB --remote --env production",
    "db:migrate:local": "wrangler d1 migrations apply DB --local"
  }
}

Always migrate before deploying code that expects new tables/columns:

npm run db:migrate
npm run deploy

Order matters. Ship Worker code that queries a column D1 doesn’t have yet, and you’ll debug “works locally, 500 in prod” for an afternoon.

Bootstrap the first admin (once)

Seeding should never store a password in git. Pass credentials via env:

ADMIN_EMAIL=you@example.com ADMIN_PASSWORD='your-secure-password' npm run seed:prod

(Implementation detail in Part 3 — the script uses Wrangler’s platform proxy against production D1.)

GitHub Actions: migrate + deploy + smoke

Goal on every push to main:

Install + typecheck
Apply remote D1 migrations
Deploy Worker (--env production)
curl /health until it succeeds

1. Cloudflare API token

Dashboard → My Profile → API Tokens → customize Edit Cloudflare Workers with at least:

Account → Workers Scripts → Edit
Account → Workers R2 Storage → Edit
Account → D1 → Edit
Account → Account Settings → Read

2. GitHub Environment `production`

Repo → Settings → Environments → create production:

Type	Name	Value
Secret	`CLOUDFLARE_API_TOKEN`	token from step 1
Secret	`CLOUDFLARE_ACCOUNT_ID`	your account id
Variable	`WORKER_URL`	`https://my-cms.YOUR_SUBDOMAIN.workers.dev`

Using a GitHub Environment keeps prod credentials scoped and lets you add required reviewers later.

3. Workflow

name: Deploy Worker

on:
  push:
    branches: [main]
  workflow_dispatch:

concurrency:
  group: deploy-production
  cancel-in-progress: false

jobs:
  deploy:
    name: Migrate & deploy
    runs-on: ubuntu-latest
    timeout-minutes: 15
    environment: production
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      # Prefer npm install if npm ci fails on optional platform binaries
      # (some lockfiles list every @esbuild/* optional package).
      - name: Install dependencies
        run: npm install --no-audit --no-fund

      - name: Typecheck
        run: npm run type-check

      - name: Apply D1 migrations
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          wranglerVersion: "4.107.1"
          command: d1 migrations apply DB --remote --env production

      - name: Deploy Worker
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          wranglerVersion: "4.107.1"
          command: deploy --env production

      - name: Smoke check
        env:
          WORKER_URL: ${{ vars.WORKER_URL }}
        run: |
          URL="${WORKER_URL:?Set WORKER_URL in the production environment}"
          curl -fsS --retry 5 --retry-delay 3 "$URL/health"
          echo
          echo "Health check OK ($URL)"

Pin wranglerVersion to what you use locally so CI and laptops don’t diverge.

concurrency.cancel-in-progress: false matters for deploys: you don’t want a second push to cancel a migration mid-flight.

Separate CI for PRs

Keep PRs cheap — typecheck only, no production migrate/deploy:

name: CI

on:
  pull_request:
  push:
    branches: [main]

jobs:
  typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm install --no-audit --no-fund
      - run: npm run type-check

Checklist after first green deploy

[ ] GET $WORKER_URL/health returns OK
[ ] Secrets set (BETTER_AUTH_SECRET, JWT_SECRET)
[ ] Admin seeded
[ ] Can open /auth/login and /admin
[ ] Frontend CORS origin is in production CORS_ORIGINS
[ ] Media upload hits R2 (create a post with a featured image)

What’s next

Deploy is the easy win. The painful bugs show up in auth: disabled signup, Better Auth credential rows vs profile password hashes, and RBAC so editors can actually open the portal.

Build an Edge-Native Headless CMS on Cloudflare Workers (SonicJS + D1 + R2) - Part 1

Luqman Hakim — Sun, 26 Jul 2026 11:28:21 +0000

Most headless CMS setups still look like 2018: a Node server, a Postgres box in one region, and S3 for uploads. That works — until you want global latency, zero cold starts, and an ops surface you can explain in one diagram.

This series is about running a real headless CMS on Cloudflare Workers, with D1 for data and R2 for media, using SonicJS — an edge-first CMS built for that stack. Part 1 covers the architecture and content model. Part 2 covers deploy + CI/CD. Part 3 covers the auth and admin gotchas you’ll hit in production.

Why put a CMS on the edge?

A traditional CMS request path often looks like this:

User hits your API in us-east-1
App talks to Postgres in the same region
Media comes from S3 (egress fees optional, but common)
Every region outside that AZ pays the latency tax

An edge-native CMS flips that:

Request hits a Worker near the user
D1 (SQLite at the edge) serves content/auth data
R2 stores media with no egress fees
The same Worker serves admin UI + REST API

SonicJS is designed around that model: TypeScript collections define your schema; the framework generates the admin UI and API; Wrangler binds D1 and R2 so you never invent connection strings for a CMS database.

The shape of the system

┌─────────────────────────────────────┐
│         Cloudflare Worker           │
│     (SonicJS + Hono + admin UI)     │
└──────────────┬──────────────────────┘
               │
       ┌───────┴────────┐
       ▼                ▼
┌─────────────┐   ┌─────────────┐
│  D1 (SQLite)│   │ R2 (media)  │
│ content/auth│   │ images/files│
└─────────────┘   └─────────────┘

Bindings live in wrangler.toml — the Worker receives env.DB and env.MEDIA_BUCKET at runtime. No ORM connection URL. No S3 access keys in .env for the happy path.

name = "my-cms"
main = "src/index.ts"
compatibility_date = "2024-09-23"
compatibility_flags = ["nodejs_compat"]

[[d1_databases]]
binding = "DB"
database_name = "my-cms-db"
database_id = "YOUR_DATABASE_ID"
migrations_dir = "./node_modules/@sonicjs-cms/core/migrations"

[[r2_buckets]]
binding = "MEDIA_BUCKET"
bucket_name = "my-cms-media"

[vars]
ENVIRONMENT = "development"
BUCKET_NAME = "my-cms-media"

Bootstrap: one file to start the app

The app entrypoint is small. You register collections, optionally tweak auth/plugins, and export the SonicJS app:

import { createSonicJSApp, registerCollections } from '@sonicjs-cms/core'
import type { SonicJSConfig } from '@sonicjs-cms/core'
import blogPostsCollection from './collections/blog-posts.collection'

registerCollections([blogPostsCollection])

const config: SonicJSConfig = {
  plugins: {
    register: [],
  },
  auth: {
    // We'll dig into this in Part 3
    extendBetterAuth: (opts) => ({
      ...opts,
      emailAndPassword: {
        ...opts.emailAndPassword,
        disableSignUp: true,
      },
    }),
  },
}

export default createSonicJSApp(config)

That’s the whole Worker surface: collections + config → admin at /admin, auth at /auth/login, health at /health, and a generated content API.

Schema-as-code: define a blog collection

Instead of clicking schema fields in a UI and hoping they sync to prod, you define collections in TypeScript. SonicJS treats them as managed (config-driven) collections.

Here’s a practical blog post model: title, slug, Lexical rich text, featured image + gallery on R2, author, publish date — with public read for your frontend and a short cache TTL:

import type { CollectionConfig } from '@sonicjs-cms/core'

export default {
  name: 'blog_post',
  displayName: 'Blog Post',
  slug: 'blog-posts',
  description: 'Manage your blog posts',

  schema: {
    type: 'object',
    properties: {
      title: {
        type: 'string',
        title: 'Title',
        required: true,
        maxLength: 200,
      },
      slug: {
        type: 'slug',
        title: 'URL Slug',
        required: true,
        maxLength: 200,
      },
      excerpt: {
        type: 'textarea',
        title: 'Excerpt',
        maxLength: 300,
        helpText: 'Short summary used in listings and SEO meta tags',
      },
      content: {
        type: 'lexical',
        title: 'Content',
        required: true,
      },
      featuredImage: {
        type: 'media',
        title: 'Featured Image',
      },
      gallery: {
        type: 'array',
        title: 'Gallery',
        items: { type: 'media' },
      },
      author: {
        type: 'user',
        title: 'Author',
        required: true,
      },
      publishedAt: {
        type: 'datetime',
        title: 'Published Date',
      },
    },
    required: ['title', 'slug', 'content', 'author'],
  },

  listFields: ['title', 'author', 'status', 'publishedAt'],
  searchFields: ['title', 'excerpt', 'content', 'author'],
  defaultSort: 'createdAt',
  defaultSortOrder: 'desc',

  managed: true,
  isActive: true,

  // Without this, only authenticated admins/editors can read via the API
  access: {
    public: ['read'],
  },

  cache: {
    enabled: true,
    ttl: 5, // seconds — tune for your freshness vs speed tradeoff
  },
} satisfies CollectionConfig

A few details worth copying into your own project:

type: 'media' maps uploads to the R2 MEDIA_BUCKET binding.
access.public: ['read'] is opt-in. Private-by-default is the right CMS default; public APIs should be explicit.
cache.ttl lets you override per collection when some content can be hotter than others.

Local development loop

With Wrangler, local feels like production: same bindings, Miniflare-backed D1/R2 under .wrangler/.

npm install
npm run db:migrate:local   # apply SonicJS migrations to local D1
# seed an admin (credentials via env — never commit them)
ADMIN_EMAIL=you@example.com ADMIN_PASSWORD='your-secure-password' npm run seed
npm run dev                # wrangler dev — usually http://localhost:8787

Then open:

Login: http://localhost:8787/auth/login
Admin: http://localhost:8787/admin
Health: http://localhost:8787/health

You’re not “running a CMS in Docker and pretending it’s Cloudflare.” You’re running the Worker runtime locally with the same APIs you’ll use in prod.

When this stack shines

Marketing / content sites that need a real admin, not a markdown-only repo
Frontends (Astro, Next, Remix, plain fetch) that want a fast public JSON API
Teams that prefer schema in git over schema-only-in-UI
Projects that want Cloudflare’s free/paid tiers instead of a always-on Node + Postgres bill

What’s next

In Part 2, we’ll ship this to production: production wrangler.toml envs, secrets, D1 migrations, and a GitHub Actions pipeline that migrates, deploys, and smoke-checks /health.

Docs: SonicJS · Cloudflare Workers · D1 · R2

CloudFront support mTLS

Luqman Hakim — Fri, 24 Jul 2026 04:47:49 +0000

Here’s the same article with an HA angle woven in — especially contrasting ALB/VPCE toil with CloudFront as a global managed edge.

From Private VPC Endpoints to the Edge: mTLS for Mobile APIs on AWS

TL;DR — You used to terminate mobile mTLS at API Gateway or ALB, and the ALB path forced Private API Gateway + VPC Endpoints + IP target groups. CloudFront now speaks mTLS at the edge — so you can keep API Gateway Regional, add WAF/Shield/custom headers, and stop plumbing private IPs into load balancers. Bonus: you also stop designing HA for the front door — CloudFront is already a global service.

The problem nobody enjoys explaining in a design review

Mobile apps talking to backends often need more than “Bearer token in a header.”

You want cryptographic client identity before the request even looks like an HTTP call:

Only devices with a valid client certificate connect
Stolen tokens alone are not enough
Certificate lifecycle becomes part of your trust model

That’s mutual TLS (mTLS): the server proves who it is and the client proves who it is.

On AWS, the question has always been: where do you terminate that handshake?

Option 1 — mTLS at API Gateway (simple, but limited)

Mobile ──mTLS──▶ API Gateway ──▶ Backend

What works well

Direct path
Fewer moving parts
Certificate validation close to your API surface

What starts to hurt

Less natural fit for edge controls (global PoPs, Shield Advanced patterns, rich WAF at the CDN layer)
Harder to centralize “edge policy” (headers, geo, bot signals, caching rules) in one place
You still need a clean story for public exposure, rate limits, and DDoS
Availability is mostly “API Gateway is managed,” but you still think regionally about the entry point

This is a solid baseline. Many teams start here.

Option 2 — ALB in front (secure… and operationally spicy)

Some teams put an Application Load Balancer in front so mTLS (or TLS policy) lives on the ALB:

Mobile ──mTLS──▶ ALB ──▶ API Gateway ──▶ Backend

On paper: great. In practice: the network plumbing gets loud.

Because ALB needs a private path into API Gateway, you often end up here:

Piece	Why it exists	Pain point
Private API Gateway	Not publicly reachable	Can’t use a simple public Regional endpoint
VPC Endpoint (VPCE)	ALB reaches private API	Extra networking + IAM/interface endpoint design
IP target group	ALB targets VPCE ENI IPs	IPs can change; registration/health checks get awkward
Private DNS / routing	Glue it together	More failure modes in prod
HA design	ALB is regional	Multi-AZ is table stakes; multi-region means another design

Why this feels like a tax

You’re not just “adding a load balancer.” You’re adopting a private connectivity mini-platform:

Make API Gateway private
Stand up Interface VPC Endpoints
Discover / track VPCE private IPs
Register those IPs as ALB targets
Keep health checks and IP churn under control
Decide AZ placement, failover, and (if you’re serious) multi-region entry
Debug “is it certs, ALB, VPCE, or API GW?” at 2 a.m.

It works. It’s also a lot of undifferentiated heavy lifting for what you really wanted: authenticate the device, then call the API.

HA tax: With ALB you’re still thinking in regions and AZs. Multi-AZ is expected. Cross-region active/active or failover is a project. Your mobile clients need a resilient DNS/routing story on top of mTLS.

Option 3 — CloudFront viewer mTLS (the plot twist)

CloudFront can now perform the viewer mTLS handshake at the edge.

That flips the architecture:

Mobile ──mTLS──▶ CloudFront ──▶ Regional API Gateway ──▶ Backend
                      │
                      ├── AWS WAF
                      ├── AWS Shield
                      └── Custom headers / edge policy

Why this is a big deal

Because CloudFront is public by design, you no longer need the Private API Gateway + VPCE + IP target group dance just to put a smart front door in front of your API.

You can:

Expose Regional API Gateway
Point CloudFront origin at the API Gateway domain name
Terminate / validate client certificates at CloudFront
Layer WAF and Shield on the same distribution
Inject custom headers from CloudFront → origin

Mental model: CloudFront becomes your global mTLS gate. API Gateway goes back to being an API — not a networking science project.

The HA win you stop overthinking

Here’s the underrated part of the CloudFront path:

You don’t design HA for the front door the way you do for ALB.

Concern	ALB + Private API	CloudFront viewer mTLS
Scope	Regional construct	Global edge network
Multi-AZ	You plan it	Inherited from the service
Multi-region entry	Extra architecture	Clients hit nearest PoP by default
Failover story	DNS, dual stacks, runbooks	Largely AWS-operated edge capacity
What you still own	Everything behind the ALB	Origin health + Regional API / backend HA

CloudFront is a global managed service. Mobile clients resolve to the edge; certificate handshake and request acceptance happen at PoPs worldwide. You’re not standing up “an HA pair of mTLS terminators” in each region.

That doesn’t mean your origin is magically multi-region — Regional API Gateway and backends still need their own resilience story. But the client-facing mTLS plane stops being an HA design exercise.

Punchline: With ALB you buy availability with architecture diagrams. With CloudFront you inherit a global front door — and spend your HA budget where it still matters: the origin and the data plane.

Side-by-side: pick your pain

	API Gateway only	ALB → Private API GW	CloudFront viewer mTLS → Regional API GW
mTLS termination	API Gateway	ALB	CloudFront edge
API Gateway type	Regional / as designed	Often Private	Regional
Extra networking	Low	VPCE + IP targets	Origin config
Front-door HA	Managed, regional entry	You design AZ / region strategy	Global service — largely out of scope
Edge WAF / Shield	Separate story	Possible but awkward	Native with distribution
Custom edge headers	Limited	App/ALB rules	CloudFront native
Ops complexity	Low–medium	High	Medium (edge-focused)
Best for	Simple APIs	Existing ALB-centric estates	Mobile fleets + edge security

What “good” looks like with CloudFront

A practical pattern for mobile backends:

Provision device certificates from your private CA (or managed PKI)
Build a CloudFront trust store with the CA(s) you trust
Enable viewer mTLS on the distribution
- Required — every client must present a valid cert (typical for private mobile APIs)
- Optional — mixed traffic during migration
- Passthrough — edge doesn’t fully validate; origin does (migration/legacy)
Origin = Regional API Gateway custom domain / execute-api hostname
Lock down the origin so it only accepts traffic from CloudFront (custom secret header, Resource Policy, or both)
Attach WAF for L7 rules; lean on Shield for DDoS posture at the edge
Invest HA behind the origin (API / compute / data) — not in reinventing a global TLS edge

The hidden win: security and availability move to the edge

With ALB + Private API Gateway, a lot of your energy goes into reachability and keeping the front door up.

With CloudFront mTLS, more of that energy goes into policy:

Who is allowed to connect? → certificates / trust store
What traffic shapes are abusive? → WAF
Who absorbs volumetric attacks? → Shield + edge capacity
How does the origin trust CloudFront? → origin access controls + headers
Do we need multi-AZ mTLS terminators? → No — CloudFront is already global

That’s a healthier split for mobile APIs: authenticate early, authorize narrowly, keep the origin boring, and don’t DIY global HA for TLS.

When you might still choose ALB

CloudFront isn’t magic for every estate.

Keep ALB (or ALB + Private API) if you need:

Sticky ALB-centric features as the primary entry
Patterns that already assume VPC-native targets end-to-end
Strict internal-only topologies where a CDN edge is the wrong trust boundary

For public mobile clients + API Gateway, CloudFront viewer mTLS is usually the cleaner story — on security and on how little HA you have to invent at the perimeter.

Closing thought

mTLS for mobile isn’t hard because TLS is hard.

It’s hard because teams accidentally buy a networking + HA architecture when they only needed a client authentication control point.

API Gateway alone: simple
ALB + Private API + VPCE IPs: powerful, expensive in toil (and you still own regional HA)
CloudFront viewer mTLS + Regional API Gateway: authenticate at the edge, keep the API public-but-protected, bring WAF/Shield/custom headers along — and skip front-door HA design because CloudFront is already a global service

If you’re writing the next version of your mobile API edge: start with certificates and trust stores — not private ENI IP target groups or multi-region ALB runbooks.

Suggested subtitle / social blurb

Stop wiring ALB target groups to VPC Endpoint IPs just to do mTLS. Terminate client certificates at CloudFront, keep API Gateway Regional, get WAF + Shield for free — and stop designing HA for the front door. CloudFront is already global.

One nuance worth keeping in the article (so reviewers don’t nitpick): CloudFront removes most front-door HA work; you still design HA for Regional API Gateway + backends. The win is that mTLS entry is no longer part of that problem.

Why we decided to go with Kubernetes

Luqman Hakim — Sun, 01 Sep 2024 10:55:52 +0000

Hi folks, today I'm gonna share why I am so invested in learning Kubernetes and applying it in my production environment that I'm working for right now.

We have a lot of problems as our application running in a monolith structure rather than microservices (literally only one server). As time goes by, our application increase in usage and functionalities thus making this is a backstab to our current server specs. RAM usage going high all the time. Application crashes quite frequent because the server specs cannot handle the current workloads.

I suggest to the team to make our application high available, meaning we can share the workload across multiple servers. If one of the applications crashes, we have time to recover it while maintaining the availability of the application.

Our application mainly running in three separate services.

Main service - handling transactions, calculation etc.
Batch service - sending emails, reminder, generate incremental numbers etc.
Report service - generate reports for our client for their usage, audit etc.

Initially, all these process running in one application. We know to make our application run in multiple servers, we need to separate out the batch service so that we will not sent our emails on notifications multiple times. So we separate out batch service so it will be running only on one server.

Now our application can run in high availability mode. Multiple main services will handle the transaction and incoming request from users but our report service still embedded in the main service, that is okay but as the time goes by, many users generating the report thus sometimes our main service crashes.

The next thing is we separate out our report service so that if a lot of users generating the report, the main service that handle transactions can still work as usual and maintaining our uptime.

Now, all of our service running independently. Great! What if the servers crashes? Who's gonna recover it if the team is on holiday or still sleeping? (obviously every human being need to rest right?)

This when the Kubernetes infrastructure comes in. Autoscale, autorecover, all in one place. Like a one-stop-center for a production grade application right? To be honest, learning all these Kubernetes things are time consuming, pain, sleepless night but who cares? It will benefit us along the time. Cost? Err we might need to discuss it in a separate discussion. Cheers!

Kubernetes, when to use ?

Luqman Hakim — Sun, 01 Sep 2024 10:55:16 +0000

Our application mainly running in three separate services.

Main service - handling transactions, calculation etc.
Batch service - sending emails, reminder, generate incremental numbers etc.
Report service - generate reports for our client for their usage, audit etc.

The next thing is we separate out our report service so that if a lot of users generating the report, the main service that handle transactions can still work as usual and maintaining our uptime.

Now, all of our service running independently. Great! What if the servers crashes? Who's gonna recover it if the team is on holiday on still sleeping? (obviously every human being need to rest right?)

So we decided to move to Kubernetes. Autoscale, autorecover, all in one place. Like a one-stop-center for a production grade application right?

DEV Community: Luqman Hakim

SonicJS Auth Gotchas on Cloudflare: Signup, Credentials, and RBAC - Part 3

1. Turn off public self-registration

2. Two password stores (this is the big one)

Fix: reset password with a script that updates both

3. RBAC ≠ auth_user.role

Fix: promote the user

4. Ops cheat sheet

5. Beta packages and patches (optional honesty)

6. Hardening checklist for a private CMS

Series wrap-up

Deploy a SonicJS CMS to Cloudflare Workers with GitHub Actions - Part 2

Prerequisites

Production env in wrangler.toml

Secrets (auth won’t work without them)

Manual deploy: migrate, then ship

Bootstrap the first admin (once)

GitHub Actions: migrate + deploy + smoke

1. Cloudflare API token

2. GitHub Environment production

3. Workflow

Separate CI for PRs

Checklist after first green deploy

What’s next

Build an Edge-Native Headless CMS on Cloudflare Workers (SonicJS + D1 + R2) - Part 1

Why put a CMS on the edge?

The shape of the system

Bootstrap: one file to start the app

Schema-as-code: define a blog collection

Local development loop

When this stack shines

What’s next

CloudFront support mTLS

From Private VPC Endpoints to the Edge: mTLS for Mobile APIs on AWS

The problem nobody enjoys explaining in a design review

Option 1 — mTLS at API Gateway (simple, but limited)

Option 2 — ALB in front (secure… and operationally spicy)

Why this feels like a tax

Option 3 — CloudFront viewer mTLS (the plot twist)

Why this is a big deal

The HA win you stop overthinking

Side-by-side: pick your pain

What “good” looks like with CloudFront

The hidden win: security and availability move to the edge

When you might still choose ALB

Closing thought

Suggested subtitle / social blurb

Why we decided to go with Kubernetes

Kubernetes, when to use ?

3. RBAC ≠ `auth_user.role`

2. GitHub Environment `production`