DEV Community: David Bartalos

Static Site, Live Inventory: Two Sources of Truth That Don't Fight Each Other

David Bartalos — Thu, 04 Jun 2026 12:24:00 +0000

The shop sells two things: original watercolour paintings (one of each, ever) and open-edition prints. Originals sell out permanently. Prints don't. The question the architecture has to answer is: how does the site know which originals are still available, and how quickly does it reflect a sale?

The naive answer is to fetch from Medusa at build time and bake the sold status into the static HTML. That works until a painting sells between deploys — the site shows it as available, someone clicks "Add to cart," Medusa rejects the request, and the experience is broken. Rebuilding on every sale is an option, but it couples the storefront's uptime to Medusa's webhook reliability.

The naive answer in the other direction is to fetch from Medusa client-side on every page load and render nothing until the data arrives. That's a spinner on a content site. The paintings are the product. Making visitors wait to see them is the wrong trade.

The actual solution has two layers with clearly defined responsibilities.

Layer 1: build-time hint

Every painting in the content collection has an optional sold field in its frontmatter:

---
title: "Autumn Morning"
sold: true
---

When sold: true, the build-time effects are:

Catalog feed: the original variant is excluded from the Google/Meta product catalog TSV. No point advertising something that can't be bought.
JSON-LD: the product structured data uses OutOfStock for availability. Google doesn't index it as a purchasable product.
OG tags: product:availability is set to "oos".

None of these affect the shop UI. A sold-out painting still has a page, still shows in the gallery, still shows the print options. The sold flag is a build-time signal to external systems, not a UI gate.

The flag is kept in sync automatically. bun run sync reads stocked_quantity from Medusa for every product and patches the frontmatter:

↕ autumn-morning → sold: true
↕ winter-estuary → removed sold flag (back in stock)

↕ in the output means a patch was written. Running sync before deploying keeps the catalog and structured data accurate without manual frontmatter edits.

Layer 2: runtime hydration

The shop grid is static Astro HTML. Every card renders with data-status="available" by default — the optimistic assumption. The original price, the "Add to cart" button, the availability badge: all rendered at build time, all assuming the painting is available.

After the page loads, a plain <script> block calls the Medusa store API and patches each card:

async function hydrateAvailability() {
  const products = await fetchProducts() // cached promise, fires once per page

  cards.forEach((card) => {
    const handle = card.dataset.handle
    const availability = products.get(handle)
    const originalAvailable = availability?.originalAvailable ?? true // optimistic fallback

    card.dataset.status = originalAvailable ? 'available' : 'sold'

    if (!originalAvailable) {
      card.querySelector('.variant-original')?.setAttribute('data-sold', '')
    }
  })
}

hydrateAvailability()

data-sold on the original variant row triggers CSS: the price gets a strikethrough, the row fades slightly, the "Add to cart" button disappears. The card stays in the grid — sold originals are visible as FOMO and context, not hidden. Prints on the same painting remain fully purchasable.

No framework. No Svelte island. No loading state. The grid is visible and interactive immediately; the sold indicators arrive silently a few hundred milliseconds later without shifting anything.

What happens when Medusa is down

The optimistic fallback on line 6 above is intentional. If fetchProducts() fails — Medusa is restarting, the VPS is briefly unreachable — every card stays data-status="available". Visitors can browse. The cart still works. If someone tries to add a sold original, Medusa rejects the cart request and the UI shows the error then.

The worst case is a few extra "sorry, sold out" cart errors during a brief backend outage. The alternative — blocking the grid on a Medusa response — would mean a broken shop during any downtime. For a low-traffic art shop, optimistic-with-graceful-degradation is the right default.

The filter system

The shop grid has filters: show all / available originals only / prints only / by theme. The filters use data-hidden (not display:none) driven by data-status and data-tags:

function applyFilters() {
  cards.forEach((card) => {
    const hidden = shouldHide(card, activeFilter, activeTags)
    card.dataset.hidden = String(hidden)
  })
}

CSS transitions on data-hidden give the appearance/disappearance a fade rather than a jump. The "available originals" filter count updates after hydrateAvailability() completes — it reads the live data-status values, not the build-time assumptions.

Why two layers instead of one

Build-time data is fast and free — it's just frontmatter. Runtime data is live and accurate. The split is about matching the right data source to the right consumer:

External systems (Google, Meta) see the build-time state. They cache it. A slightly-stale catalog entry means a sold original might briefly appear in Google Shopping — a bad click, but not a broken purchase (Medusa rejects the cart). Running bun run sync before each deploy keeps the gap small.
The shop UI sees the runtime state. A "available" badge on an actually-sold painting is a much worse experience — someone browses, adds to cart, gets rejected. That one must be live.

bun run sync closes the gap before each deploy, so the build-time state is never more than one deploy behind. In practice, originals sell slowly enough that the gap is rarely more than a few hours.

If you're applying this on a different stack, the principle generalises: optimistic static HTML + silent runtime patch + accept that the worst case is a cart error. The trick is being honest about which data source serves which consumer, and not making the visitor wait for the slow one.

When this pattern doesn't fit

Optimistic-with-graceful-degradation is the right default for a low-traffic shop where originals sell on the order of days. It's the wrong default for a flash sale, a sneaker drop, or anything where stock depletes in seconds and a misleading "available" badge would mean hundreds of cart errors a minute. At that point the spinner stops being a UX failure and starts being an honest signal — "we're checking, because the answer changes faster than we can ship HTML."

That's the full series. The stack behind nadiapoe.co.uk: Astro 6 + Svelte on Cloudflare Pages, Medusa v2 on a €3.29/mo Hetzner VPS, and a handful of patterns that took longer to figure out than they should have.

Transactional Email in Medusa v2 Without the Notification Module

David Bartalos — Tue, 02 Jun 2026 12:18:00 +0000

Medusa v2 has a notification module. It's designed exactly for transactional email — you register a provider, configure templates, and the module fires on order events. There's one problem: there's no official Resend provider.

The community providers that exist are hit-and-miss on maintenance. The official SendGrid provider exists, but its setup felt heavier than the problem warranted. Resend, on the other hand, seemed easy enough to implement directly — clean API, good TypeScript types, and 3,000 emails a month free and a dollar per thousand beyond that.

This is what I did instead: skip the notification module entirely.

The approach

Medusa's event system still works without the notification module. Any subscriber can listen to order.placed and do whatever it wants. So the setup is:

An order.placed subscriber that calls the Resend SDK directly.
The email template inlined in the subscriber file.
A dev-redirect pattern so order emails in staging don't land in real inboxes.

No notification module configuration. No provider abstraction. Just a function that runs when an order is placed and sends an email.

The ESM trap: why the template lives inline

The natural instinct is to put the HTML template in a separate file and import it:

// ❌ This fails at runtime
import { orderConfirmationTemplate } from '../templates/order-confirmation'

Medusa's API uses "module": "Node16". Cross-file imports for subscriber dependencies work in dev and fail in production with ERR_MODULE_NOT_FOUND. I didn't fully diagnose which resolver did what — inlining everything sidesteps the question entirely.

The fix is to keep subscriber files completely self-contained. Everything the subscriber needs — template, helpers, types — lives in the same file.

The same rule applies to import type. With "module": "Node16", plain import { SomeType } for TypeScript types isn't guaranteed to be erased from the compiled output. Always use import type { ... } for type-only imports in subscriber files.

The subscriber

// api/src/subscribers/order-placed.ts
import type { SubscriberArgs, SubscriberConfig } from '@medusajs/framework'
import { Modules } from '@medusajs/framework/utils'
import { Resend } from 'resend'

export default async function orderPlaced({ event, container }: SubscriberArgs<{ id: string }>) {
  const orderModule = container.resolve(Modules.ORDER)
  const order = await orderModule.retrieveOrder(event.data.id)

  const isDev = process.env.PUBLIC_ENV === 'development'
  const toAddress = isDev
    ? process.env.EMAIL_DEV_REDIRECT!
    : order.email

  const resend = new Resend(process.env.RESEND_API_KEY)

  await resend.emails.send({
    from: 'Nadia Poe <hello@nadiapoe.co.uk>',
    to: toAddress,
    subject: `Order confirmed — ${order.display_id}`,
    html: buildOrderEmail(order),
  })
}

export const config: SubscriberConfig = {
  event: 'order.placed',
}

function buildOrderEmail(order: any): string {
  // template inlined here — plain HTML string, no JSX, no template engine
  return `<!DOCTYPE html>...`
}

The EMAIL_DEV_REDIRECT pattern is worth keeping. In development, every order confirmation — regardless of who placed the order — goes to a +dev alias on your own email address. You see the real email, the real order data, without polluting a customer inbox. In production, toAddress is the customer's email. The guard is a single ternary.

The contact form: no SDK needed

The storefront has a contact form that also sends via Resend. For a one-off form POST, installing the Resend SDK client-side isn't worth it — the API is just an HTTP endpoint:

// client/src/pages/api/contact.ts
import { env } from 'cloudflare:workers'

export const POST: APIRoute = async ({ request }) => {
  const { name, email, message } = await request.json()

  await fetch('https://api.resend.com/emails', {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${env.RESEND_CONTACT_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      from: 'nadiapoe.co.uk <hello@nadiapoe.co.uk>',
      to: env.EMAIL_CONTACT_TO,
      reply_to: email,
      subject: `Message from ${name}`,
      text: message,
    }),
  })

  return new Response(null, { status: 204 })
}

env comes from cloudflare:workers — the live runtime binding, not import.meta.env. The reply_to is set to the sender's address so replying in Gmail works naturally.

Four API keys, not one

One API key for everything is convenient until you need to rotate it, audit usage, or debug which part of the system sent a bad email. The setup uses four keys:

Key	Used by	Environment
`medusa-notifications-prod`	order subscriber	production
`medusa-notifications-dev`	order subscriber	staging
`storefront-contact-prod`	contact form	production
`storefront-contact-dev`	contact form	staging

Resend shows per-key send history. When something goes wrong you can see exactly which key sent what, without digging through logs.

DNS: the boring bit that breaks everything if you skip it

Resend's Cloudflare integration auto-configures DKIM and SPF. The setup that works:

SPF: v=spf1 include:_spf.resend.com ~all on the root domain
DKIM: Resend generates the records; Cloudflare auto-applies them via the integration
DMARC: v=DMARC1; p=reject; rua=mailto:hello@nadiapoe.co.uk — p=reject means unauthenticated mail claiming to be from nadiapoe.co.uk gets dropped, not delivered
MX + inbound: Cloudflare Email Routing with a catch-all rule forwarding to Gmail. hello@nadiapoe.co.uk works as a real inbox without running a mail server.

The Resend SMTP credentials (smtp.resend.com:587, username resend, password = the API key) let Gmail send as hello@nadiapoe.co.uk via "Send mail as" — so replies from the shop's inbox come from the right address.

What you give up

The notification module's abstraction is useful if you ever want to swap providers or add multiple notification channels (email + SMS + push). Bypassing it means that flexibility lives in your subscriber code instead. For a shop that will always send via Resend, that's a fine trade. If the requirements change, the migration is straightforward: add the official provider when it ships, move the template, delete the subscriber.

Live shop: nadiapoe.co.uk.

Three Cloudflare Patterns Earned the Hard Way

David Bartalos — Thu, 28 May 2026 12:13:00 +0000

Every Cloudflare product is well-documented in isolation. The interesting bugs are always at the seams between two products — the edge injecting scripts into HTML that already has a CSP, the WAF inspecting requests for media served from R2, Vite substituting variables at build time that don't exist yet on Pages. These three patterns are from running nadiapoe.co.uk on Astro 6 + Pages, with R2 hosting the artwork media.

1. CSP nonces via middleware, not build-time hashes

The textbook way to do a strict CSP on a static site is build-time hashing: scan every inline <script>, hash it, list the hashes in the CSP header. Cloudflare even has a build hook to do it for you.

For an art site, Bot Fight Mode is non-negotiable — automated scrapers harvesting painting images are a real concern, and Cloudflare's challenge platform is the cheapest layer of protection available. But it breaks the moment you enable it. Cloudflare's edge injects the challenge widget at request time with a rotating token. The hash changes per request. Your CSP rejects it. Half your visitors get a broken challenge widget because the static hash you baked in this morning no longer matches.

The fix is a per-request nonce. Astro 6's middleware runs as a Worker; Workers have HTMLRewriter. From client/src/middleware.ts:

export const onRequest = defineMiddleware(async (context, next) => {
  const response = await next()
  if (typeof HTMLRewriter === 'undefined') return response
  if (!response.headers.get('content-type')?.includes('text/html')) return response

  const nonceBytes = crypto.getRandomValues(new Uint8Array(16))
  const nonce = btoa(String.fromCharCode(...nonceBytes))

  const rewritten = new HTMLRewriter()
    .on('script', { element(el) { el.setAttribute('nonce', nonce) } })
    .transform(response)

  const headers = new Headers(rewritten.headers)
  headers.set('Content-Security-Policy', buildCsp(nonce))
  // private cache — never share a nonce between users
  headers.set('Cache-Control', 'private, max-age=1500, stale-while-revalidate=7200')

  return new Response(rewritten.body, { status: rewritten.status, headers })
})

Two non-obvious bits:

Cloudflare reads the nonce from your CSP header and stamps its own injected scripts with it. Undocumented but stable. This is the only reason the pattern works at all — without it, the challenge widget would still get blocked.
Cache-Control: private is load-bearing. A shared cache that served one user's nonced HTML to another would only break the cached client (their nonce doesn't match the newly injected scripts), but it's still a bug. private keeps Cloudflare's edge from doing this.

2. Server secrets via `cloudflare:workers`, not `import.meta.env`

Astro has two environments: build-time and runtime. Vite resolves import.meta.env.SOMETHING at build time by string substitution. If the value isn't in .env at build time — and Cloudflare Pages doesn't expose dashboard-configured secrets during the build — Vite bakes in the literal undefined.

Worse: it does this silently. No warning, no error. The contact form deploys, the Resend SDK call fails with "API key undefined," and you spend an hour checking the Cloudflare dashboard before realising the value never made it into the bundle.

Astro 6 has two ways to read server-side env at runtime. They are not equivalent:

// ❌ Broken in Astro 6 — Astro.locals.runtime.env was removed
const apiKey = Astro.locals.runtime.env.RESEND_API_KEY

// ✅ Works
import { env } from 'cloudflare:workers'
const apiKey = env.RESEND_API_KEY

The cloudflare:workers module is provided by the Workers runtime. env is the live binding object — the same one your wrangler.toml and Cloudflare dashboard configure. No build-time substitution; nothing is baked in.

Client-side code (anything in a Svelte component or a non-SSR Astro page) keeps using import.meta.env.PUBLIC_*. Those are baked at build time on purpose — they're public.

One gotcha: bindings may be absent in local dev without a full Pages emulation setup. Wrap access in try/catch when the value is optional:

function getDb() {
  try { return (env as any)?.DB ?? null } catch { return null }
}

3. R2 hotlink protection with an inverted WAF rule

Print fulfillment runs through Prodigi — a print-on-demand provider that produces and ships prints worldwide. When an order comes in, Medusa generates a time-gated presigned R2 URL pointing to the high-resolution print master and hands it to Prodigi. Prodigi fetches the file, prints it, ships it. The URL expires. Nobody else ever needs access to that file.

The high-res masters live in R2. Keeping them protected means ensuring those presigned URLs can only be opened by the intended recipient in the intended window — not scraped, not re-shared, not embedded on another site. The WAF rule is the layer that enforces origin intent on the media domain.

The naive WAF rule is "block if the Referer header doesn't match nadiapoe.co.uk."

It works until you try to:

Open an image URL directly in a browser tab — no Referer, blocked.
Load a <video preload="metadata"> tag — some browsers send no Referer on media requests, blocked.
Test on a *.pages.dev preview deployment — Referer is <branch>.nadiapoe-co-uk.pages.dev, blocked.

The fix is to invert the logic: block only when a Referer exists and isn't in the allowlist.

(http.host eq "media.nadiapoe.co.uk")
and (len(http.referer) > 0)
and not (http.referer contains "nadiapoe.co.uk")
and not (http.referer contains "localhost")
and not (http.referer contains ".pages.dev")

Empty Referers pass — direct nav, preload requests, RSS readers. Preview deployments pass via the .pages.dev wildcard. Real hotlinks from other sites get a 403.

If you script your WAF rules via the Cloudflare API (which you should, for reproducibility), two quirks not mentioned in the error messages: a PUT to the rulesets endpoint must not include kind or phase (they're implicit from the URL), and rate-limit characteristics on the free plan must include cf.colo.id because counts are per-colo, not global.

Closing

The seams are where you learn things. Check the network tab when behaviour is wrong — Cloudflare adds its own response headers that tell you which rule fired, which challenge ran, which WAF block triggered. The answers are usually there; they're just not in the docs.

nadiapoe.co.uk runs on all three patterns in production.

Medusa v2 in Production: Three Bugs That Each Ate a Weekend

David Bartalos — Tue, 26 May 2026 12:13:00 +0000

Production bugs don't care that your infrastructure costs €3.29/mo.

Medusa v2 is genuinely good — the headless model, the workflow engine, the v2 admin API are all a step up from v1. But the docs surface 80% of what you'll hit, and the remaining 20% is where weekends go. These are three bugs I hit running nadiapoe.co.uk's shop on Medusa v2. All three had simple fixes. None of the fixes were obvious.

Bug 1: The `Date.parse` shipping rule trap

The shop has two delivery options — a small incentive to encourage slightly larger print orders:

Standard delivery — £4.50, always available.
Free delivery — £0, available when cart_subtotal >= 60.

A £100 cart. Free Delivery disappears. Standard gets auto-selected. Refresh, clear cart, retry — same result. Stranger: a £10 test cart shows Free Delivery correctly. The rule is set up right. The data in the database looks right. Something in the middle is broken.

That something is buried in @medusajs/fulfillment/dist/utils/index.js. The comparator for gte / lt rules does this:

const left = Date.parse(a)
const right = Date.parse(b)
if (!isNaN(left) && !isNaN(right)) {
  return new Date(left) < new Date(right)   // date branch
}
return Number(a) < Number(b)                // numeric branch

That looks fine until you remember what Date.parse does to bare integer strings:

Date.parse("60")    // → -315619200000     (year 1960 — 2-digit year expansion)
Date.parse("100")   // → -59011459125000  (year 100 AD)
Date.parse("60.00") // → NaN

A £100 cart with cart_subtotal = "100" and a rule value of "60" evaluates as Date(100 AD) < Date(1960) → true. The "show this option when subtotal is below £60" condition fires on a cart worth nearly twice the threshold. Free Delivery gets stripped.

The fix is one toFixed(2). From api/src/workflows/shipping-options-context.ts:

import {
  listShippingOptionsForCartWorkflow,
  listShippingOptionsForCartWithPricingWorkflow,
} from "@medusajs/medusa/core-flows"
import { StepResponse } from "@medusajs/framework/workflows-sdk"

const injectCartSubtotal = async ({ cart }: { cart: any }) =>
  new StepResponse({ cart_subtotal: (cart.item_total ?? 0).toFixed(2) })

listShippingOptionsForCartWorkflow.hooks.setShippingOptionsContext(injectCartSubtotal)
listShippingOptionsForCartWithPricingWorkflow.hooks.setShippingOptionsContext(injectCartSubtotal)

The rule values stored in the database have to match the same shape — "60.00", not "60". Once both sides are decimals, Date.parse returns NaN and the evaluator falls through to the numeric branch.

Bug 2: There are two shipping workflows, and you have to hook both

Look at the snippet above again. There are two workflow hooks, not one. That's not an accident.

By default Medusa v2's shipping rule evaluator only sees is_return and enabled_in_store. Anything cart-financial — cart_subtotal, item_count, currency, region — has to be injected via the setShippingOptionsContext hook. That part is documented.

What isn't documented: there are two workflows that evaluate shipping options.

listShippingOptionsForCartWorkflow runs when the storefront fetches options to display.
listShippingOptionsForCartWithPricingWorkflow runs inside addShippingMethodToCartWorkflow when a customer actually selects an option.

Hook only the first and the storefront shows Free Delivery correctly. The customer selects it, gets a 400 back — because the second workflow has no cart_subtotal in its context, the rule fails, and Medusa rejects the assignment as "option not available for this cart." The response body is generic. The server logs are silent.

Cost: one Friday evening.

Bug 3: The workaround that aged badly

Some workarounds need an expiry date. This one didn't have one.

Early Medusa v2 had two related bugs — #11766 and #13301. Stripe charged the card, webhooks fired, but order.paid_total stayed at 0 and the payment status never advanced past pending. Every order had to be manually marked paid in the admin — which also meant no order confirmation email fired, since the email subscriber was gated on a completed order. Customers paid, heard nothing, and had to be chased manually.

I patched it with a subscriber on order.placed that called capturePaymentWorkflow directly:

// api/src/subscribers/order-capture-payment.ts  (DELETED in 2026-05)
export default async function orderCapturePayment({ event, container }) {
  // ...fetch payment collection, mark fully captured, refresh order
}

It worked. Shipped.

Then Medusa v2.11.1 landed and fixed both upstream bugs. The subscriber kept running — double-firing the capture (harmless, since the payment was already captured) but also re-emitting order.placed. That re-emission triggered the email subscriber a second time. Every customer started getting two identical confirmation emails.

I didn't notice until v2.14.2, months later, when an unrelated change made the second order.placed event log a warning. The fix was a one-line deletion. The lesson cost more than the bug did.

Every workaround for a third-party bug needs three things:

The upstream issue URL in a comment — so future-you knows why it exists.
A version check or feature flag to disable it — so it can be switched off without deleting it immediately.
A note to revisit on the next major upgrade of that dependency.

I had #1. I didn't have #2 or #3. The duplicate emails probably did 30 minutes of brand damage before I caught it. The fix was free. The discipline to set expiry dates on workarounds isn't instinctive, but it's cheap.

One note if you're starting a Medusa v2 project: the v1 docs URL still resolves and Google ranks both. Make sure the URL doesn't have /v1/ in it before you copy a snippet — the APIs changed significantly between versions.

Live shop: nadiapoe.co.uk.

The Hosting Rejection Tour: Render, AWS EC2, Oracle, and How I Ended Up on a €3.29/mo VPS

David Bartalos — Tue, 19 May 2026 12:17:00 +0000

Before the stack worked, three hosting options failed. Each one looked perfect on paper. Each one had a specific, concrete reason it couldn't work. This is the rejection tour.

The constraint: Medusa v2 is stateful. It needs PostgreSQL, Redis for BullMQ, and enough RAM to run the event bus and workflow engine without getting killed. That rules out serverless. (Medusa can technically start without Redis — it falls back to an in-process event bus — but that means losing job queuing, workflow retries, and reliable event delivery. Fine for a quick local demo; not something you want processing real orders.) It needs persistent storage, a real process manager, and a consistent IP for outbound webhook validation. Every "just deploy it for free" option assumes your workload is stateless. This one isn't.

Attempt 1: Render

Render's free tier looked fine for a low-traffic shop. 512MB RAM, easy deploys from GitHub — cold starts on the free tier, always-on on the paid plan. The plan was to pair it with Neon for PostgreSQL (generous free tier, serverless scaling) and Upstash for Redis (free tier covers BullMQ at low volume). Three managed services, total cost: $0.

I got Medusa running, ran the setup scripts, and then installed the Prodigi print fulfillment plugin — which loads product mappings and prefetches shipping zones at startup.

OOM kill on boot. 512MB wasn't enough.

The obvious fix is to upgrade the Render service. Their starter plan is $7/mo. That's just the API — Neon and Upstash stay free at low volume, but now I'm at $7/mo for a single service with no room to grow, and I still hadn't solved staging. Render's starter plan is $7/mo per service. Two environments means two API instances: $14/mo before touching the databases.

I could have stripped the fulfillment plugin to fit inside 512MB. But without it there are no print orders — Prodigi integration is how open-edition prints get produced and shipped. Dropping it to hit a RAM limit means the shop sells originals only, which wasn't the brief.

Attempt 2: AWS EC2

After Render, AWS EC2 looked like the right move. A t4g.micro in eu-west-2 (London): 1 GiB RAM, 2 vCPU ARM64 Graviton2, always-on, full SSH access, swap configurable — all within the AWS free tier for the first 12 months. Double the memory of Render's paid plan, at no cost. I built out the full setup: CloudFormation stack, Nginx reverse proxy, Let's Encrypt TLS, systemd service, GitHub Actions CD, health check cron.

It ran. There were a couple of ARM64 quirks — a ts-node source-map crash under Bun that needed TS_NODE_SKIP_SOURCE_MAP_SUPPORT=1, and Node.js auto-limiting the V8 heap to ~512MB on a 1 GiB instance, fixed with NODE_OPTIONS=--max-old-space-size=1024. But Medusa came up, Prodigi loaded, the health check passed.

Then I ran a checkout flow under load. OOM kill.

The 1 GiB ceiling wasn't enough headroom when Prodigi, Medusa, and an active checkout were all competing for memory at once. And the infrastructure complexity — CloudFormation, Nginx config, cert renewal timers, CloudWatch, a manual cutover checklist — was a real ongoing cost for a solo project. After the free year, the bill would be ~$7.90/mo anyway. At that price you can just buy a VPS that has the memory you need and none of the ceremony.

Attempt 3: Oracle Always Free

Oracle's Always Free tier is, on paper, absurd. The A1 Flex shape gives you up to 4 OCPU and 24 GB RAM at no cost, permanently. ARM64, which is what Hetzner's cheapest VPS uses anyway. UK London region available. I signed up.

"The selected shape is not available in this Availability Domain. Please try a different Availability Domain or shape."

I tried every Availability Domain in UK London. Same message. I tried Frankfurt. Same message. I tried Amsterdam. Same.

This isn't a new problem. The Oracle community forum has threads going back two years with hundreds of people reporting A1 capacity unavailable in every European region. Oracle adds capacity occasionally, and it disappears within hours as people snap it up. The forum advice is to script retries and keep trying. I tried that for a few weeks.

The Always Free tier only works if you can actually provision the instance. If capacity is gone, it's gone indefinitely. For a project you want to actually ship, "keep retrying and hope" isn't a deployment strategy.

What actually worked: Hetzner CAX11

Hetzner's CAX11 is €3.29/mo. ARM64, 2 vCPU, 4 GB RAM, 40 GB NVMe SSD, 20 TB/month egress included. I signed up, got the server provisioned in about 30 seconds, and had Medusa running the same afternoon.

The setup that's been stable since:

Two systemd services, one box. Dev and production run as separate Medusa instances — different ports, different .env files, different PostgreSQL databases. Caddy sits in front and routes api-dev.nadiapoe.co.uk and api.nadiapoe.co.uk to the right one. Each service restarts automatically on failure. No Docker, no orchestration — just two medusa.service unit files and a Caddy config.

Deploys via GitHub Actions. On push to main, a workflow SSHes in, pulls the latest code, runs bun install and bun run build, and restarts the appropriate service. Under 60 seconds end to end.

Backups to Cloudflare R2. A nightly cron runs pg_dump and uploads the compressed archive to a dedicated R2 bucket (nadiapoe-backups). R2 is already in the stack for media — adding a backup bucket costs nothing extra. Retention is 7 daily dumps on-server, 30 in R2. If the VPS burns down, restoring is pg_restore and a git pull.

The total monthly cost: €3.29. Both environments. All services. Backups included.

The lesson

"Free" hosting for stateful backend workloads usually means one of two things: a RAM ceiling that kills anything real, or a capacity queue where "available" means "available when someone else cancels." For a stateless frontend or a simple API, free tiers are great — Cloudflare Pages handles the storefront for nothing. But the moment you have a process that needs to stay alive, own persistent state, and run at startup, a cheap paid VPS is more reliable than a free tier with asterisks.

Hetzner CAX11 at €3.29/mo is less than most people spend on a coffee a month. It's not free. It's better than free.

One genuine acknowledgement before moving on: the free tiers from Cloudflare, Resend, Neon, and Upstash make it possible to build and prove a business before it earns a penny. They lower the bar for anyone who wants to try something without betting money on it first. That matters, and it's worth saying.

Live shop: nadiapoe.co.uk.

Blazingly Fast Ecommerce Stack for Less Than a Coffee a Month — No Marketplace, No Platform Cut

David Bartalos — Mon, 18 May 2026 06:30:00 +0000

If you've ever looked at a marketplace's fee page and felt your eye twitch, this post is for you.

The major selling platforms take their cut from every angle — transaction fees, listing fees, monthly subscriptions, payment processing. The percentages vary but the direction doesn't: a meaningful slice of every sale goes to infrastructure you don't own or control. And that's before the visibility problem: on a marketplace of millions of listings, the algorithm decides whether your work gets seen at all.

My girlfriend had been listing her work on one of the big marketplaces for a while — barely any traffic, zero sales. The fees were almost beside the point. I saw the disappointment and floated the idea: her own site, her own corner of the internet — and I'd build it.

I'm a software engineer. I like a challenge. So I set out to give it a shot. The result runs at €3.29/mo for all backend infrastructure. The site is live at nadiapoe.co.uk. Here's the stack and the decisions behind it.

The constraints

Artwork loads instantly. Watercolours are the product. A 2-second LCP would send visitors away before they saw a painting. No image-CDN that stamps a watermark on the hero image, no spinner while the page wakes a cold serverless function.
No third-party watermarks. Image-CDN convenience — Cloudinary, imgix — isn't worth a logo in the corner of the hero. This is an artist's portfolio. The paintings deserve respect.
Real commerce, not a payment link. Multi-currency (GBP / EUR / USD / AUD), international fulfillment for prints, originals shipped from the UK. A Stripe payment link in the Instagram bio wasn't going to cut it.
No tracking, no cookie banner. The site doesn't follow visitors. No analytics cookies, no third-party pixels, no consent popup to dismiss before you can see a painting. Purchase data goes only as far as it needs to: card details to Stripe, a shipping address — originals are shipped by us from the UK, prints via a print-on-demand provider for international orders. Nothing retained beyond what's needed to get the order out the door.
Indie budget. One artist, no team, no investor. Anything more than ~£10/month total infrastructure is a recurring tax on the creative work. That ceiling shaped every hosting decision in the stack.

The stack, piece by piece

The infrastructure splits cleanly across two providers.

Cloudflare (free tier)

Everything the visitor touches runs on Cloudflare. CDN and WAF sit in front of everything — Bot Fight Mode, rate limiting, R2 hotlink protection. Behind them:

Cloudflare Pages hosts the Astro 6 storefront. Static by default, per-route SSR where needed (checkout callbacks, contact form, structured data feeds). The painting pages are pure HTML — the entire collection ships zero JS until the cart is opened.

Cloudflare R2 stores all images and process videos. Zero egress fees, served from a custom domain (media.nadiapoe.co.uk). Videos are pre-encoded to four variants locally with ffmpeg (720p desktop, 480p mobile, JPEG poster, 64×64 thumb) and uploaded via wrangler. No URL transforms, no image-service quotas to exhaust.

Cloudflare D1 is the edge SQL database — one table, one purpose: like counts. The like button stores your choice in localStorage and increments a counter in D1. No cookies, no tracking, no consent popup. You see the count; nothing sees you.

Hetzner VPS — €3.29/mo

Everything commerce-related runs on a single Hetzner CAX11: 2 vCPU ARM64, 4 GB RAM, 40 GB NVMe, 20 TB/month egress. On it:

Medusa v2 — the commerce backend. Dev and prod as separate systemd services, both reverse-proxied by Caddy.
PostgreSQL — orders, products, customers.
Redis — BullMQ event bus and workflow engine.

Render, AWS, and Oracle Always Free each failed for a different specific reason. Hetzner just works.

One gap in Medusa v2 worth knowing: there's no official Resend provider. Order confirmation emails skip the notification module entirely and call the Resend SDK directly from an order.placed subscriber.

Third-party services

Stripe handles payments across four currencies (GBP / EUR / USD / AUD). Cloudflare injects cf.country into a <meta> tag at the edge; the storefront reads it to pick the matching Medusa region and present prices in the local currency. User override persists in localStorage.

Resend handles transactional email — 3,000 emails/month free, then $1/1,000.

The interactive layer

Svelte islands handle the cart drawer, quantity controls, painting gallery, and region selector. Nano-stores (cartStore, cartUpdating, regionStore) keep islands in sync without a framework router.

The shop grid itself is static Astro HTML — no Svelte involved. The paintings are the product; a visitor should see the full collection immediately, not wait on an inventory check before anything renders. So every card defaults to "available," then a plain <script> tag calls the Medusa API in the background and patches data-status on each card to flip sold originals to a faded state. No layout shift, no spinner, no framework overhead for a read-only grid.

One Astro 6 gotcha that cost an afternoon: server-side secrets must come from import { env } from 'cloudflare:workers'. The old Astro.locals.runtime.env was removed and import.meta.env silently bakes undefined for server-only vars. No build error, no runtime warning — just missing data in production.

What it actually costs

Backend hosting: €3.29/mo — both staging and production Medusa instances, PostgreSQL, Redis, Caddy, automated nightly backups to Cloudflare R2. Frontend, CDN, edge SQL, object storage, WAF, analytics: free tier. The metered costs are Stripe (1.5–2.9% per transaction — unavoidable regardless of platform, but at least there's no extra platform cut on top) and Resend (3,000 emails/month free, then $1/1,000).

Compare that to a typical marketplace taking 6–7% on a £150 original watercolour — that's £9–10 per sale, forever, to infrastructure you don't own. At even modest volume the self-hosted setup pays for itself inside the first month.

Will this survive a traffic spike? Honestly, no idea — this shop has never been Slashdotted, and a 2 vCPU ARM box with 4 GB RAM is not going to win any load test. But if it ever buckles under the weight of people trying to buy original watercolours, upgrading the VPS will be the easiest problem on the list that day.

One snippet worth stealing

This pattern only works because the HTML is served through a Cloudflare Worker — but if you're already on Cloudflare Pages, you have that for free.

The full CSP is set per-request with a fresh nonce, injected into every <script> tag at the edge. No build-time hash dance, no list of inline script hashes to maintain. From client/src/middleware.ts:

export const onRequest = defineMiddleware(async (context, next) => {
  const response = await next()
  if (typeof HTMLRewriter === 'undefined') return response
  if (!response.headers.get('content-type')?.includes('text/html')) return response

  const nonceBytes = crypto.getRandomValues(new Uint8Array(16))
  const nonce = btoa(String.fromCharCode(...nonceBytes))

  const rewritten = new HTMLRewriter()
    .on('script', { element(el) { el.setAttribute('nonce', nonce) } })
    .transform(response)

  const headers = new Headers(rewritten.headers)
  headers.set('Content-Security-Policy', buildCsp(nonce))
  return new Response(rewritten.body, { status: rewritten.status, headers })
})

Cloudflare's own bot-fight challenge scripts get whitelisted automatically — they read the nonce from the CSP header and stamp themselves with it. On a static-only setup you're stuck with hashes, and those break the moment Cloudflare rotates a challenge token. The Worker approach sidesteps that entirely.

The site is nadiapoe.co.uk if you want to see the result.

DEV Community: David Bartalos

Static Site, Live Inventory: Two Sources of Truth That Don't Fight Each Other

Layer 1: build-time hint

Layer 2: runtime hydration

What happens when Medusa is down

The filter system

Why two layers instead of one

When this pattern doesn't fit

Transactional Email in Medusa v2 Without the Notification Module

The approach

The ESM trap: why the template lives inline

The subscriber

The contact form: no SDK needed

Four API keys, not one

DNS: the boring bit that breaks everything if you skip it

What you give up

Three Cloudflare Patterns Earned the Hard Way

1. CSP nonces via middleware, not build-time hashes

2. Server secrets via cloudflare:workers, not import.meta.env

3. R2 hotlink protection with an inverted WAF rule

Closing

Medusa v2 in Production: Three Bugs That Each Ate a Weekend

Bug 1: The Date.parse shipping rule trap

Bug 2: There are two shipping workflows, and you have to hook both

Bug 3: The workaround that aged badly

The Hosting Rejection Tour: Render, AWS EC2, Oracle, and How I Ended Up on a €3.29/mo VPS

Attempt 1: Render

Attempt 2: AWS EC2

Attempt 3: Oracle Always Free

What actually worked: Hetzner CAX11

The lesson

Blazingly Fast Ecommerce Stack for Less Than a Coffee a Month — No Marketplace, No Platform Cut

The constraints

The stack, piece by piece

Cloudflare (free tier)

Hetzner VPS — €3.29/mo

Third-party services

The interactive layer

What it actually costs

One snippet worth stealing

2. Server secrets via `cloudflare:workers`, not `import.meta.env`

Bug 1: The `Date.parse` shipping rule trap