标签：#Serverless

I wanted two things: short links under my own brand (every link I share points traffic back to my site ), and a real excuse to run a complete system on the edge — DNS, distributed compute, storage, auth and a dashboard — in production, at zero infrastructure cost. The result is flino.link : a shortener that responds in under 10 ms from 300+ locations, runs entirely on Cloudflare's free tier, and whose only expense is the domain: $4.68 a year. This post covers the design decisions, which is where the interesting parts are. The architecture in 30 seconds A single Cloudflare Worker serves the whole domain: GET /<slug> — the hot path. One read from Workers KV (globally replicated) and a 302 redirect. Nothing else touches that path. /api/links — a REST API with Bearer auth to create, list and delete links. /admin — a single-page dashboard served as inline HTML from the Worker itself. No framework, no build step. A Durable Object with embedded SQLite keeps per-slug click counts. No servers, no containers, no database to manage. The whole Worker is three TypeScript files and zero runtime dependencies. Why a dedicated domain? My first idea was to hang the shortener off a route on flino.dev . Bad idea: shorteners attract abuse — spam, phishing — and their domains sooner or later end up on blocklists. If that happens, I don't want it dragging my main domain down with it. A separate domain isolates that reputation risk completely, and a short .link costs less than a coffee per year. KV for links, a Durable Object for counters This is the central design decision. Workers KV is perfect for a shortener's access pattern — read-heavy, write-light, reads served from the edge — but its writes are eventually consistent : two concurrent increments in different datacenters would clobber each other. For counting clicks, it's useless. A Durable Object solves exactly that: it's a single global instance with transactional SQLite storage. Every increment, no matter which datacenter it comes

Introduction Serverless computing has become a buzzword in cloud architecture. But like any tool, it has sweet spots and sharp edges. After building and maintaining several serverless applications, I've learned where it shines and where it creates headaches. This article shares those lessons. When Serverless Helps 1. Event-Driven Workloads Serverless excels when your code runs in response to events: file uploads, database changes, HTTP requests. The pay-per-execution model means you don't pay for idle time. // AWS Lambda handler for image resizing exports . handler = async ( event ) => { const bucket = event . Records [ 0 ]. s3 . bucket . name ; const key = event . Records [ 0 ]. s3 . object . key ; // resize and save return { statusCode : 200 }; }; 2. Variable or Unpredictable Traffic If your app has occasional spikes (e.g., a marketing campaign), serverless auto-scales instantly. No need to provision for peak load. 3. Rapid Prototyping and MVPs You can deploy a fully functional API in minutes without managing servers. This accelerates feedback loops. 4. Microservices and Glue Code Serverless functions are perfect for small, single-purpose services that connect other services (e.g., processing webhooks, data transformation). When Serverless Hurts 1. Long-Running Processes Most providers have a maximum execution timeout (e.g., 15 minutes for AWS Lambda). Batch processing or video transcoding may hit this limit. # This will timeout if processing takes > 15 minutes def handler ( event , context ): process_large_file ( event [ ' file ' ]) return { ' done ' : True } 2. Cold Starts After a period of inactivity, the first request may have a delay of several seconds. This is detrimental for latency-sensitive applications like synchronous APIs. 3. Stateful Applications Serverless is stateless by design. If you need persistent connections (e.g., WebSockets) or local state, you'll need additional services like Redis or DynamoDB, adding complexity. 4. High, Steady Load If your

If you've ever hit deploy on AWS Fargate and watched the task sit in PENDING forever, this one's for you. I ran a small experiment with Seekable OCI (SOCI) the AWS thing that promises to fix Fargate cold starts. This article is what I learned. The good, the boring, and the "wait, that didn't work?" bits. You'll walk away knowing what SOCI is, whether you should bother setting it up, and what real numbers look like! Prerequisites ✅ You've deployed something on AWS Fargate before. You know what a Docker image is. You have an AWS account you're OK spending ~$5 on. That's it. 🤔 The Problem Fargate is great. Push a container, get a running task. No nodes to manage! Until you use a big image. Every Fargate task pulls the whole image before starting. No shared cache. No head start. If your image is 3 GB, your task waits for 3 GB to download. Every time. Every task. For an ML model or a heavy Java service, cold start becomes minutes, not seconds. Two stats made me actually care about this: 76% of container startup time is just downloading the image. Only 6.4% of that image data is needed to actually start the app. So you're pulling 100% to use 6.4%. And it costs you 76% of your startup budget doing it. That's ridiculous!! This isn't a Fargate-only problem, by the way. It's a container problem. But Fargate hurts more because you can't cache anything at the host level. I presented this talk at AWS Community Days Bangalore 2026 💡 What is SOCI? SOCI stands for Seekable OCI . Simple idea: Instead of downloading the whole image before starting the container, download only the parts the app needs right now. Everything else gets pulled lazily, in the background, while the app is already running. The way it works: You push your image to ECR like normal. A separate tool builds an index a byte-level map of what's in each layer. Fargate reads the index at startup and only fetches the bytes it actually needs to boot the process. As the app tries to read more files, Fargate fetches those

I've built a lot of voice integrations. Every single one needed a deployment whose only job was to talk to the Sinch API: receive the callback, translate it into SVAML or a Conversation API call, hand off to the rest of the application. Not the interesting part. Just the piece that has to exist because your code and Sinch's network live in different places, with a round trip between them on every call event. Sinch Functions moves that piece into the network itself. Your voice and messaging handlers run on the same infrastructure that's already carrying your calls and messages, right where the callbacks originate. This isn't a general-purpose Lambda replacement: the rest of your application, and any compute that isn't glue against Sinch's APIs, stays exactly where it is, whether that's AWS, Azure, or your own infrastructure. Your order lookup, your database writes, your actual business logic: still on Lambda or wherever you already have it. Functions is specifically for the code that exists only to bridge your app and the Sinch network, not a place to run your whole system. I've been trying it out and this post walks through getting set up, writing a basic voice function, and deploying it. Pricing is usage-based and separate from your Voice and Conversation usage: $0.10 per compute-hour (first hour free each month), $0.05 per GB-month of storage (first 0.1 GB free), $0.05 to $0.15 per GB-month for the database depending on tier (first 0.1 GB free), and $5.00 per month per function if you want it kept always-on instead of scaling to zero. These are the current Standard rates from your project's Billing Overview in the Sinch dashboard; treat them as a snapshot, not a guarantee, given the Alpha status below. Sinch Functions is listed as Alpha in the Sinch Build dashboard. Expect the CLI, runtime APIs, pricing, and this walkthrough itself to change before general availability. Treat it as something to experiment with, not something to put in front of production traffic y

If you are a fellow blogger or web developer looking to build a high-performance, developer-friendly,...

I've been working in software for more than 15 years. This is the first piece I've decided to write about the job. I picked this topic because it was a small, real problem that cost me time more than once, until I finally stopped and fixed it properly. Quick disclaimer: this isn't distributed tracing or multi-service observability. It's a targeted fix for one specific problem: correlating logs within a single Step Function execution. If your scenario is different, the problem takes a different shape. What matters here is the reasoning, not the recipe. Quick context for anyone who doesn't work with serverless: AWS Step Functions is an orchestration service. You design a workflow as a state machine (JSON), and each state usually triggers an AWS Lambda (a function that runs on demand, no server to manage). In my case, a request kicks off a state machine execution that passes through several Lambdas in sequence: some do validation, others call external services, and one waits on a callback response before moving on. The fix turned out to be simpler than it sounds: a field Step Functions already offered for free, and I just wasn't using it. A request was processed 120 days ago. The customer calls: "Did you receive my request? I never heard back." You open the AWS Console. The Step Functions execution is already gone. Execution history only sticks around for 90 days, and even within that window, finding one specific execution among thousands is already a hassle. That leaves CloudWatch, with logs from every Lambda in the pipeline. You have one piece of data: the case ID. But every Lambda logged its own way: no standard, no correlation between them. To reconstruct what happened, you have to open each function's logs in the order the workflow probably ran, and piece it together by hand. It wasn't the error itself that hurt. It was the time lost just organizing the logs before you could actually start investigating. The Chaos The pipeline wasn't huge, but it wasn't trivial ei

#NebiusServerlessChallenge Live dashboard: Myth-Busting Quantitative Terminal · Live endpoint: /predict on Nebius Serverless · Code: github.com/KoralZakai/stocksPredictionAfterTweet Everyone on a trading desk knows the story. He tweeted about Intel, and the stock ran for months. He posts about Iran, oil spikes. The anecdotes are vivid, specific, and everybody has one. While the prevailing myth suggests that Trump's tweets drive market movements, my research — built on an analysis of 78,130 posts, with Llama-3.3-70B reading every market-relevant tweet — reveals a more nuanced reality. The findings demonstrate that the market tends to price in significant events long before the tweet is even posted. This indicates a case of reverse causality, where the market dictates Trump's narrative, rather than the other way around. He isn't moving the market; he is simply riding the wave of established trends. Forward — the direction you could trade — the signal is a coin flip, and I can show that with pre-registered tests rather than vibes: 0 of 63 cells survive correction. Getting to that answer honestly was the hard part. Seven times this pipeline produced a beautiful, publishable, completely false positive — each one looking exactly like the discovery the anecdotes promise. Those seven are the engineering content of this post. The setup Data. 78,130 public posts; 8,317 in the study window (2025-01-01 → 2026-07-06). Daily OHLCV bars for 62 tickers, committed to the repo. Public data only — a stranger can re-run every number without a single private key. The model. meta-llama/Llama-3.3-70B-Instruct on Nebius AI Studio , zero-shot, reading only the tweet text : what is this post about, which instruments does it touch, and which way does each one go. 476 tweets, 1,296 instrument calls. No fine-tuning — the question is whether the text carries signal, and a fine-tune would smuggle the outcome into the answer. The architecture. Nebius Serverless AI Jobs run the batch research pipel

I've been building AI agents for a while now, and streaming responses to a UI has always been the painful part. In previous projects I tried API Gateway streaming, Lambda response streaming, and even AppSync Events via an agent tool call to notify the UI. I also looked at adding my own WebSocket API through API Gateway, which requires managing $connect , $disconnect , and $default routes, storing connection IDs in DynamoDB, and posting messages back through @connections . All of these approaches felt like too much ceremony for what should be simple. That's when I found that AgentCore has built-in WebSocket support. The browser can just connect directly to the agent. No middleman. I built WearCast to demonstrate this functionality. This is an AI agent that helps you pick out what to where based on the weather. I've found this very helpfu when packing for a trip. The code for this application is public and you can find the full implementation on this GitHub repo . The problem with the traditional approach We usually build app applications as we do REST APIs User → REST API → Lambda → AI Service → Lambda → REST API → User Every message makes a round trip through multiple intermediaries. The response waits until the entire generation is complete, and then it all comes back at once. For a chat interface, this feels sluggish. Users stare at a spinner while the model generates hundreds of tokens they could already be reading. Even if you add Server-Sent Events or long-polling, you're still stitching together a real-time experience on top of infrastructure that seemed like overkill. I wanted something better. The architecture Here's what I ended up with: ┌─────────────┐ ┌──────────────────┐ │ React UI │─── JWT ─▶│ API Gateway + │──▶ Lambda (presigned URL) │ (Cognito) │ │ Cognito Auth │ └──────┬──────┘ └──────────────────┘ │ │ WebSocket (SigV4 presigned URL) │ ← No middleman! Direct connection → ▼ ┌──────────────────────────────────┐ ┌────────────────────┐ │ AgentCore Runtim

Database branching is one of the best ideas serverless Postgres brought to the mainstream. Fork the database at a point in time, get an isolated copy with all the data, run something risky against it, throw it away. It made preview databases and safe migrations feel routine. But a real application is not just a database. It is a database, plus the files it stores in object storage, plus the backend code that serves it, plus, increasingly, the model and gateway config it calls for AI. When you branch only the database, those other three stay shared. Your "branch" points at the same S3 bucket, the same deployed backend, and the same AI configuration as everything else. So it is half a copy, and the half it leaves out is where a lot of the interesting bugs and the scary migrations live. Neon's platform preview changes what a branch contains. A branch now forks the database and its data, the object storage and its files, the functions that run your backend, and the AI gateway config, all at the same point in time, all isolated. A branch stops being a database copy and becomes a whole environment. To make sure that is a real claim and not a diagram, I took a full-stack project, branched it, and checked every layer. Here is what happened. TL;DR Elsewhere, "branch" means the database only. Object storage, backend deploys, and AI config stay shared, so you bolt on scripts to fake per-branch versions of them. A Neon branch forks all four together: Postgres + data, object storage + files, functions (each branch gets its own URL), and the AI gateway. I proved it: branched a project with a DB, a bucket of files, a function, and the gateway. The branch came up with a copy of the rows, a copy of the files on its own storage endpoint, its own function URL, and the gateway. A write to the branch left main untouched, and deleting the branch removed all of it. That makes a branch a real environment: true preview stacks, whole-state bug reproduction, and disposable sandboxes for agent

At re:Invent 2025, AWS announced Lambda Durable Functions . The feature introduces a checkpoint/replay mechanism that allows Lambda executions to run for up to one year, automatically recovering from interruptions by replaying from the last checkpoint. Lambda's 15-minute timeout is not a bug or a limitation to work around. It is a deliberate design choice that encourages keeping functions simple and focused, and in most cases it does its job well. When a function needs more time, the usual approach is fanout : split the work into smaller Lambdas, orchestrate them, move on. I have done it many times and it works perfectly fine. But a few days ago I was developing a new Lambda function for a pipeline orchestrated by Step Functions, and the execution time exceeded 15 minutes. I could have done the usual split, but durable functions had just come out and I wanted to try them. At first glance, durable functions can look like a replacement for Step Functions. Both services manage multi-step workflows , both offer checkpointing and automatic recovery , and both let you coordinate complex operations. For certain use cases, that might actually be the case: if your entire workflow lives inside a single Lambda, durable functions can handle everything on their own without an external orchestrator. But the AWS documentation actually suggests using them together. The "Hybrid architectures" section says it explicitly: many applications benefit from combining the two services, using durable functions for application-level logic within Lambda and Step Functions to coordinate the high-level workflow across multiple AWS services. My case fit that description, and more than a perfect architectural match, I wanted to learn how the two services actually work together and form my own opinion on when the hybrid approach makes sense. I figured integrating the two would be a small change. It was my first time working with the durable execution SDK, and since the code I write is mostly infras

I built a tool that answers one question: when a website won't load, is it your connection or the site? It runs two checks in parallel — measures your own line in the browser (latency + a 1 MiB download), and probes the target from Cloudflare's edge — then returns one of four verdicts: it's not you, it's you, it's both, or all clear. Demo: https://itsnotyou.site The interesting part isn't the tool, it's that the whole thing — app, ~120 monitored sites with 24h history, SSR status pages, share cards, outage alerts — runs for $0/month plus domains. The one thing that wanted to cost money Everything fit the Workers free plan except a background monitor probing ~120 sites on a tight cadence. As a Worker cron that's ~120 subrequests/run and, done naively, thousands of KV writes/day — which pushes you onto Workers Paid. The real ceiling is KV: 1,000 writes/day. So I split it. The user-facing test stays on Cloudflare — the edge probe still measures from the colo nearest the user, which is the point of edge. But the background sweep moved to a cheap VPS I already had: it probes the roster on a systemd timer and pushes results back into KV over the REST API. Staying under 1,000 KV writes/day One KV key, not key-per-site. All ~120 statuses live in a single blob. Key-per-site at sweep cadence would be millions of writes/month; a single blob is one write per sweep. Widen the cadence. I started at 2 min = 720 writes/day. Cloudflare emailed that I'd hit 50% of the daily limit (the sweep wasn't the only writer). I went to 3 min = 480/day, leaving headroom for share cards and the notify list. Move the hot counter off KV. The anonymous "tests today" counter was the sneaky risk — a traffic spike could exhaust the write budget and stall the status sweep, the one thing you can't let happen. It went to Analytics Engine instead (free, uncapped, separate budget). Now no amount of user traffic can starve the monitor. Reader and writer share code so their rules never drift: the streak/histo

When Neon became the official database partner of DEV Community, I was already a user. But the partnership made me look closer at why I chose Neon — and whether those reasons apply to other AI developers. They do. Here's why Neon is the ideal database for AI applications in 2026. The Problem: AI Apps Have Unique Database Needs AI applications have database requirements that traditional web apps don't: High write volume — every AI request generates logs, metrics, and cost data Variable load — traffic spikes when a model goes viral, then drops to zero Schema evolution — you're constantly adding models, routing rules, and analytics tables Dev/prod parity — you need to test routing changes against real production data Edge compatibility — AI APIs need sub-100ms response times globally Traditional PostgreSQL (RDS, Aurora) struggles with all five. Neon was built for them. Feature 1: Database Branching (The Game-Changer) This is Neon's killer feature. It works like git branch but for your entire database: # Create a branch from production neon branches create --parent main --name test-deepseek-v31 # Get a connection string for the branch neon connection-string test-deepseek-v31 # → postgresql://...@ep-test-deepseek...neon.tech/neondb # Run migrations on the branch npx prisma db push --url $BRANCH_URL # Test your new routing algorithm against REAL data # (the branch is a copy-on-write clone of production) # When tests pass, merge neon branches merge test-deepseek-v31 Why This Matters for AI Apps When I added DeepSeek V3.1 to my model pool, I needed to test: Would the new model break existing routing rules? Would the cost calculations be correct? Would the latency meet my SLA? With traditional PostgreSQL, testing against real data meant either: Copying production to a staging DB (hours, $$) Testing with synthetic data (unreliable) With Neon branching, I branched, tested in 30 seconds, and merged. Zero downtime, zero risk. Feature 2: Scale-to-Zero (Cost Optimization) Neon's c

Your order-processing Lambda starts sending duplicate confirmation emails. Not always — maybe one order in twenty. CloudWatch shows more invocations than messages published. The function code hasn't changed in weeks. What changed is that someone added a fraud check that pushed processing time from 25 seconds to around 45, and your SQS queue is still running the default 30-second visibility timeout. That combination is the whole bug. When a Lambda pulls a message from SQS, the message isn't deleted — it's hidden for the duration of the visibility timeout. If the function is still working when that window closes, SQS assumes the consumer died and hands the same message to another invocation. Now two Lambdas are processing the same order, both will "succeed," and both will send the email. Nothing errors. Nothing retries. There is no log line that says "this message was delivered twice because your timeouts are misconfigured." Infrawise ( npm ) flags this exact mismatch as a high-severity finding before it costs you an afternoon of staring at idempotency-free handler code. This post walks through why the bug is so hard to see, how the detection works, and how to keep an AI assistant from reintroducing it. Why you never catch this one yourself Three things make this misconfiguration nearly invisible: It passes every test. In local tests and staging, your handler processes a synthetic message in two seconds. The 30-second visibility window never comes close to expiring. The bug only exists under production conditions — real payload sizes, real downstream latency, cold starts stacking on top of slow dependencies. The defaults set the trap. SQS queues default to a 30-second visibility timeout. Lambda functions routinely get their timeout bumped to 60, 120, or 900 seconds as they grow. Nobody bumps the queue at the same time, because the two settings live in different consoles, different IaC resources, and usually different pull requests. The failure signature points elsewhe

Every developer has that one project. The passion build that sits in the back of your mind for months—or even years—before you finally sit down, crack your knuckles, and make it a reality. For me, that project was building a modern, open-access bilingual digital lexicon bridging English and Assamese: AssameseDictionary.org . While it started as a personal milestone dream, it quickly turned into a massive data engineering and architecture challenge. Here is how I tackled parsing a massive vocabulary database and serving it globally with near-zero latency. 🏗️ The Core Challenge: Scale vs. Speed A dictionary isn't like a standard SaaS app or landing page. It lives and dies by its database depth. To make this a truly definitive tool, I compiled, cleaned, and programmatically validated an extensive vocabulary index mapping over 293,000 words . The dataset doesn't just hold simple translations; it maps complex bidirectional lookups, phonetic transliterations, advanced English definitions, context usage examples, and cross-linked synonym tokens. If I threw this massive dataset into a traditional relational database hooked up to a standard server setup, I ran into immediate roadblocks: Latency: Heavy search queries on a dataset this size can cause noticeable lag. Cost/Overhead: Maintaining and scaling database servers for unpredictable public traffic gets expensive fast. I wanted the search utility to snap back instantly. To achieve that, I had to ditch traditional server paradigms entirely. ⚡ The Architecture: Serverless Edge Caching To keep things ultra-lightweight, highly cost-effective, and blazing fast, I built the platform around an edge-computing topology: The Runtime: I offloaded the backend logic entirely to Cloudflare Workers . Instead of routing traffic to a centralized origin server, queries are intercepted and executed at serverless edge locations physically closest to the user. The Data Layer: Instead of an active SQL database bottleneck, I mapped the data mat

Let's be honest—traditional A/B testing is broken. If you've ever implemented client-side testing, you know the drill. Your users load the page, wait for JavaScript to execute, and then—flicker—the content changes. It's jarring. It hurts your Core Web Vitals. And worst of all, your experiments might be measuring user frustration instead of genuine engagement. But what if you could run A/B tests with zero flicker? What if you could modify your HTML before it even reaches the browser? That's exactly what Cloudflare Workers make possible . The Server-Side Advantage A/B testing at the edge means making decisions about which variant a user sees before any HTML is sent to their browser . Instead of: Load the page Execute JavaScript Flicker Apply the variant Track the result You get: Decision made at the edge Correct HTML streamed immediately Zero flicker Better performance Companies like Ninetailed are already using Cloudflare Workers to achieve 2-3x cost savings compared to traditional serverless platforms, all while delivering personalized experiences with minimal latency . How It Actually Works The concept is surprisingly elegant. Your Cloudflare Worker intercepts incoming requests, checks for a cookie to maintain user consistency, and routes users to the appropriate variant . Here's a simplified version that's production-ready: javascript const NAME = "myExampleWorkersABTest"; export default { async fetch(req) { const url = new URL(req.url); // Determine which group this user is in const cookie = req.headers.get("cookie"); if (cookie && cookie.includes(`${NAME}=control`)) { url.pathname = "/control" + url.pathname; } else if (cookie && cookie.includes(`${NAME}=test`)) { url.pathname = "/test" + url.pathname; } else { // New user—randomly assign them (50/50 split) const group = Math.random() < 0.5 ? "test" : "control"; url.pathname = `/${group}` + url.pathname; // Fetch and modify the response to set a cookie let res = await fetch(url); res = new Response(res.body, res

My "serverless" database was billing me like it never slept. Neon has this great feature called scale-to-zero. Your Postgres compute suspends when it's idle, so you only pay for the queries you actually run. For a pre-revenue product, that should cost a few cents a month. Mine ran 24/7. The compute never once scaled to zero. The culprit wasn't my app logic. It was my database driver. I was using postgres-js, which holds a persistent connection open to the database. From Neon's side, an open connection looks like activity, so it never suspended. It just stayed awake and kept quietly billing me. The fix was basically one conceptual change: switch to @neondatabase/serverless, the HTTP driver. Instead of a long-lived connection, every query becomes a stateless one-shot HTTP request. The query fires, the connection closes, and the compute is free to suspend. Scale-to-zero finally worked. The lesson I keep relearning as a solo founder: "serverless" is a property of your whole stack, not a checkbox on one service. One persistent connection upstream and the whole cost model breaks.

The access you revoked in your last review is probably still live. I know how that sounds, but it is how most access recertification actually works. A tool generates a list, an owner clicks approve or revoke, the cycle gets marked complete, and then nothing touches the real resources. The review produces a record. The permissions stay exactly where they were. You attested to a state that was never made true. That gap bothered me for a long time, so I built something to close it and open-sourced it on AWS's aws-samples org. It is called VIGIL. The core idea A normal review answers one question: should this access still exist? The owner says no, a ticket gets filed, and maybe someone actions it next quarter. Between the decision and the change, the risk just sits there. I wanted the decision and the change to be the same step. So VIGIL does four things: It discovers resources by their owner tag and works out who actually has access to each one. It asks the owner to keep, trim, or remove that access. It applies that decision on the live resource. It records what happened in a way you can later prove. The part I care about most: scoped enforcement The lazy way to revoke someone's access to one bucket is to detach their policies. That nukes their access to everything, and it is how you cause an incident while trying to improve security. VIGIL never does that. If the access came from a bucket policy, it removes just that principal, or just the specific actions, from that bucket's policy. If the access came from the principal's own IAM policy, it adds a resource-scoped explicit Deny instead of touching shared policy, so nothing else the principal can do is affected. In practice it can remove only s3:PutObject for one principal on one bucket and leave everything else alone. If a change cannot be made safely and narrowly, it raises a ticket instead of guessing. I would rather it do nothing than do something broad. Making enforcement durable Enforcement is not a synchronous c

I built a zero-knowledge secret sharing tool. Text and files are encrypted in the browser with AES-GCM 256 before upload - the server only ever sees ciphertext. The decryption key lives exclusively in the URL fragment (#k=...). URL fragments are never sent in HTTP requests (RFC 9110 §4.2.3), so Cloudflare Workers, D1, and R2 never see it - even in logs. A few things I tried to do right: Single-use by default: Durable Objects handle atomic read→decrement→delete with blockConcurrencyWhile, no race conditions on concurrent requests Paranoid mode: returns not_found instead of expired/burned, no timing oracle Revoke endpoint: delete a drop before it's read using a SHA-256'd token with constant-time comparison CLI: burnafter send / burnafter receive - full E2E from terminal, key never touches a browser - /security page with a live in-browser AES-GCM demo and a manual Node.js decryption snippet so you can verify without trusting me Stack: Cloudflare Workers + D1 + R2 + Durable Objects. No third-party crypto libs. Live: https://burnafterread.casablanque.com Source: https://github.com/casablanque-code/burnafterread Verify: https://burnafterread.casablanque.com/security

What just happened On June 22, 2026, AWS quietly launched Lambda MicroVMs. Not a Lambda feature update. A new compute primitive sitting between Lambda Functions (stateless, 15-min max) and EC2 (full VM, you manage everything). Each MicroVM is an isolated Firecracker VM with its own HTTPS endpoint, running your code from a pre-built snapshot. Stateful. Up to 8 hours. Suspend when idle, resume on demand. I tested it the same week. Here's what I found. The test setup A minimal Python HTTP server packaged as a Dockerfile: from http.server import HTTPServer , BaseHTTPRequestHandler import json , time , os class Handler ( BaseHTTPRequestHandler ): start_time = time . time () request_count = 0 def do_GET ( self ): Handler . request_count += 1 body = json . dumps ({ " message " : " Hello from Lambda MicroVM! " , " uptime_seconds " : round ( time . time () - Handler . start_time , 2 ), " requests_served " : Handler . request_count , " pid " : os . getpid () }) self . send_response ( 200 ) self . send_header ( " Content-Type " , " application/json " ) self . end_headers () self . wfile . write ( body . encode ()) HTTPServer (( " 0.0.0.0 " , 8080 ), Handler ). serve_forever () The Dockerfile: FROM public.ecr.aws/lambda/microvms:al2023-minimal RUN dnf install -y python3 && dnf clean all WORKDIR /app COPY app.py . EXPOSE 8080 CMD ["python3", "app.py"] How it works Three steps: Zip code + Dockerfile → upload to S3 create-microvm-image builds the container, starts the app, takes a Firecracker snapshot of memory and disk run-microvm launches from that snapshot Every launch resumes from the pre-initialized state. No cold boot. Your app is already running the moment the MicroVM starts. aws lambda-microvms create-microvm-image \ --name hello-microvm-test \ --code-artifact "uri=s3://my-bucket/artifact.zip" \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn arn:aws:iam::123456789:role/MicroVMBuildRole Image build took about 3 minutes. Once done: aw

TL;DR for vibe coders: Shipped an app with Cursor, Claude Code, or v0 and got a scary Vercel or Neon bill? You probably don't need a bigger plan. You need a few fixes. Not technical? Copy the agent-rules folder from the companion repo into your project and tell your AI editor "apply these cost rules." That's the whole job. You don't need Vercel Pro. You don't need to "Launch" on Neon. A lot of the time you need the opposite of an upgrade. You need your stack to go to sleep. Here's the moment that started this. A Neon bill landed, across three small Next.js apps running on Vercel with a Neon Postgres database, and the breakdown was lopsided in a way that gave the whole game away. $32.65 of it was compute. Storage was 5 cents. History and data transfer were zero. The meter said 308 hours of compute time in about three weeks, which is a database awake for roughly fifteen hours a day, every day. The instinct when a bill climbs is "I must be getting traffic, time for a bigger plan." So before doing that, I opened Google Analytics. Zero users in the last 30 minutes. Meanwhile the database compute was pinned active, and had been more or less around the clock. So this was never a storage problem or a traffic problem. Almost the entire bill was one thing: paying for a database to stay awake doing nothing. Both of those things were true at the same time, and here's the part I'll say up front so nobody has to guess: I didn't hand-write the mistakes that caused this. AI coding agents did. I described features, the agent shipped working code, and that code carried a handful of patterns that quietly defeat scale-to-zero. That's not a confession of bad engineering. It's just what building looks like in 2026. Most of us are vibe-coding onto serverless and cloud infra now, and the agent optimizes for "make the feature work," not "keep the database asleep when no one's around." It has no idea your compute bills by the hour it stays awake, so it has no reason to care. That's the whole