Forem: Alejandro

How Rate Limiting Saved Me $500 in One Day (Real Story)

Alejandro — Mon, 29 Dec 2025 20:15:00 +0000

4 AM. Phone buzzes. Cloudflare alert: "Worker exceeded daily request limit."

I check the dashboard. 500,000 requests in 2 hours.

My free tier Worker just got hammered. And I had no rate limiting.

What Happened

Someone (or something) found my API endpoint and started hitting it. Hard.

Without rate limiting:

Every request went through
My D1 database got slammed
I hit the 100k/day limit by noon
Had to upgrade to paid plan immediately

Cost: $5/month plan + overage fees = ~$50 that month.

But it could have been worse. Much worse.

The Fix: Rate Limiting

I implemented this the same day:

import { RateLimiter } from '@cloudflare/workers-rate-limiter';

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const limiter = new RateLimiter({
      // 100 requests per minute per IP
      requests: 100,
      period: 60
    });

    const clientIP = request.headers.get('CF-Connecting-IP');

    const { success } = await limiter.limit({ key: clientIP });

    if (!success) {
      return new Response('Too many requests', { 
        status: 429,
        headers: {
          'Retry-After': '60'
        }
      });
    }

    // Normal request handling
    return handleRequest(request);
  }
};

The Impact

Next time the bot came back:

First 100 requests went through
Everything else got 429
My costs stayed normal
Database didn't get slammed

Lessons Learned

Rate limiting is not optional for production
100 req/min is usually enough for legitimate users
Return 429 with Retry-After header
Monitor rate limit hits (they tell you about bots)

Different Strategies

Per IP:

const key = request.headers.get('CF-Connecting-IP');

Per User:

const key = `user-${userId}`;

Per Endpoint:

const key = `${clientIP}-${url.pathname}`;

The Math

That attack would have cost me:

Without rate limiting: $500+ in compute costs
With rate limiting: $5 monthly plan

ROI of 10 lines of code: $495.

Bottom Line

Don't deploy to production without rate limiting. Ever.

I learned this lesson expensively. You don't have to.

My complete rate limiting template (plus 8 other production-ready templates) is in my deployment guide for $29: https://appybot.gumroad.com/l/oatoe

Have you been hit by a bot attack? What happened?

Speed Up Your Worker with Cache API (5 Lines of Code)

Alejandro — Mon, 29 Dec 2025 10:05:12 +0000

Want to make your Worker 10x faster?

Cache API is your friend. Here's how to use it in 5 lines:

The Code

export default {
  async fetch(request: Request): Promise<Response> {
    const cache = caches.default;

    // Try to get from cache first
    let response = await cache.match(request);

    if (!response) {
      // Cache miss - fetch from origin
      response = await fetch(request);

      // Cache for 1 hour
      response = new Response(response.body, response);
      response.headers.set('Cache-Control', 'max-age=3600');

      // Store in cache
      await cache.put(request, response.clone());
    }

    return response;
  }
};

That's it. 5 lines (the important ones).

What This Does

Checks if response is in cache
If yes → returns cached version (super fast)
If no → fetches from origin
Stores in cache for next time
Returns response

The Impact

Before caching:

Every request hits your origin
Response time: 200-500ms
High CPU usage

After caching:

Cached requests return in <10ms
70-90% cache hit rate is common
Minimal CPU usage

Real Numbers

On my API:

P50 latency: 450ms → 15ms
P95 latency: 800ms → 25ms
Cache hit rate: 85%

Pro Tips

Only cache GET requests
Set appropriate TTL (don't cache forever)
Use cache keys for different variants
Invalidate cache when data changes

Cache API is built into Workers. No setup. No cost. Just speed.

Want more performance patterns? I've got caching strategies, database optimization, and more in my complete guide: https://appybot.gumroad.com/l/oatoe

This CORS Mistake Exposes Your API (I See It Everywhere)

Alejandro — Sat, 27 Dec 2025 09:40:57 +0000

Saw this in 70% of Workers I've reviewed:

headers.set('Access-Control-Allow-Origin', '*');
headers.set('Access-Control-Allow-Credentials', 'true');

Looks harmless, right?

It's a security hole.

The Problem

When you use wildcard (*) with credentials, you're telling browsers:

"Allow ANY website to make authenticated requests to my API."

This means malicious sites can:

Read user data
Make requests on behalf of logged-in users
Steal session tokens

The Fix

Option 1: Use specific origins

const allowedOrigins = ['https://yourdomain.com', 'https://app.yourdomain.com'];
const origin = request.headers.get('Origin');

if (allowedOrigins.includes(origin)) {
  headers.set('Access-Control-Allow-Origin', origin);
  headers.set('Access-Control-Allow-Credentials', 'true');
}

Option 2: Don't use credentials

If you don't need cookies/auth headers:

headers.set('Access-Control-Allow-Origin', '*');
// No credentials header at all

The Rule

Wildcard OR credentials. Never both.

Simple as that.

Have you made this mistake? Don't worry—so have I. And pretty much everyone else when they started.

5 Critical Mistakes I Made Deploying Cloudflare Workers to Production (And How to Avoid Them)

Alejandro — Thu, 25 Dec 2025 18:06:27 +0000

5 Critical Mistakes I Made Deploying Cloudflare Workers to Production (And How to Avoid Them)

I've deployed over 50 Cloudflare Workers to production. And honestly? I've made every mistake
in the book.

Some were minor annoyances. Others were costly. One mistake cost my company an entire morning
of downtime. Another exposed a security vulnerability I didn't catch until a user reported it.

But each mistake taught me something. And after years of learning (the hard way), I finally
have a system that works.

Today, I want to share the mistakes I made—and how you can avoid them.

Mistake #1: Deploying Without a Security Checklist

What I did:
Built a Worker, tested it locally, and deployed. Seemed fine.

What I missed:

No CORS configuration (browser blocked requests)
No rate limiting (got slammed with requests)
No security headers (exposed to XSS attacks)
Secrets hardcoded in environment... wait, actually, I was paranoid enough to use Cloudflare Secrets, but I didn't validate input

The consequence:
My API got hit with a flood of requests. No rate limiting = crashed. Then a user reported
they could inject malicious data.

How to avoid it:
Create a security checklist BEFORE deploying:

✅ CORS configured for your domain only (not wildcard)
✅ Rate limiting enabled
✅ Input validation on all endpoints
✅ Security headers set (HSTS, CSP, etc.)
✅ Secrets in Cloudflare (not code)
✅ JWT tokens have expiration
✅ Error messages don't leak system info

I now use a checklist for every single deployment. Takes 10 minutes. Saves countless headaches.

This is exactly why I created a 7-checklist system (plus production-ready code templates)
for deploying Workers safely. Security is just one of them. Get the complete guide for $29 →

Mistake #2: Not Testing Performance Before Production

What I did:
Built locally, tested in staging, deployed to production.

What I missed:
My database queries were slow. My caching wasn't configured. I didn't realize some endpoints
took 2+ seconds to respond.

The consequence:
Users complained about slowness. My CF Workers bill was higher than expected (unnecessary
database calls). I had to rollback and optimize.

How to avoid it:
Before deploying:

Test response time under load (not just locally)
Check P95 latency (not just average)
Profile database queries
Implement caching for repeated requests
Verify bundle size is under 1MB

A simple console.time() during development would have caught this immediately.

console.time('db-query');
const users = await env.DB.prepare('SELECT * FROM users').all();
console.timeEnd('db-query');
// Output: db-query: 145ms

I learned this the hard way, which is why I included a complete performance checklist and
a caching template in my deployment guide. Check it out → $29

Mistake #3: Forgetting to Set Up Proper Logging

What I did:
Deployed, assumed it would work, didn't set up any monitoring.

What I missed:
When something broke, I had no idea what happened. No logs. No error tracking. Just... nothing.

The consequence:
Spent 2 hours debugging blindly. Could have found the issue in 5 minutes with proper logs.

How to avoid it:
Set up logging from day one:

✅ Enable Workers Logs in wrangler.toml
✅ Structured logging (JSON format)
✅ Include RequestID for tracing
✅ Log different levels (DEBUG, INFO, WARN, ERROR)
✅ Set up alerts for high error rates

Example:

const logger = new Logger({
  requestId: crypto.randomUUID(),
  path: url.pathname,
  method: request.method
});

logger.info('Request received', { endpoint: '/api/users' });
// Output: {"timestamp":"2025-12-25T...", "level":"INFO", "message":"Request received", ...}

I've since built a structured logging template and included it in my guide. Along with
monitoring, health checks, and everything else you need. Get $29 access →

Mistake #4: Not Having a Rollback Plan

What I did:
Deployed a broken version and panicked when it broke production.

What I missed:
I had no idea how to quickly revert to the previous version. My fix took 30 minutes because
I was scrambling.

The consequence:
30 minutes of downtime for users. Lost trust. Could have been 2 minutes with a practiced
rollback procedure.

How to avoid it:
Before deploying to production:

Know the rollback command by heart: wrangler rollback DEPLOYMENT_ID
Test it in staging first
Document it in your team's runbook
Practice it (seriously, do a test rollback)

A 5-minute practice session saves 30 minutes of panic later.

Mistake #5: Not Documenting What You Did

What I did:
Deployed a critical update, didn't document the changes, didn't tell my team.

What I missed:
My coworker deployed an hour later without knowing about my changes. Created a conflict.

The consequence:
Confused config, broken deployment, rolled back my changes, had to redeploy the next day.

How to avoid it:
Create a deployment checklist for your team:

What changed?
Why did it change?
What to watch for?
How to rollback?
Who deployed it?
When?

A 5-minute deployment log saves hours of confusion later.

The System That Works

After all these mistakes, I finally developed a system:

Before deployment:

Use a pre-deployment checklist (configuration, secrets, database)
Use a security checklist (auth, CORS, headers, validation)
Use a performance checklist (caching, queries, bundle size)
Use a testing checklist (unit, integration, staging)

During deployment:

Use a deployment-day checklist (health checks, metrics, alerts)
Monitor continuously for 24 hours
Watch error rate and response time

After deployment:

Use a post-deployment checklist (logs, metrics, team notification)
Document what changed
Celebrate (you earned it)

This system has eliminated 95% of my production issues. Now when things do break, they're
caught immediately and fixed in minutes instead of hours.

The Boring But Necessary Truth

Deployments aren't glamorous. Checklists aren't exciting. But they work.

The best teams I've worked with weren't the smartest. They were the most disciplined.

They had checklists. They followed them. They rarely had incidents.

And when something did go wrong? They had a plan. Fixed it in minutes. Moved on.

That's why I spent time compiling all of this into one guide. Not to sell you something,
but because I genuinely believe every developer should have this. It includes:

✅ 25-page production deployment guide
✅ 7 printable checklists (ready to print and tape to your desk)
✅ 9 production-ready code templates

For just $29. Get it here →

Where to Start

If you're reading this and thinking "yeah, I should probably have a system..."

Here's what I recommend:

Print a security checklist and tape it to your monitor
Create a simple deployment checklist for your team (or grab one from my guide)
Set up one alert in Cloudflare for high error rates
Test a rollback once

Takes 1 hour. Could save you from a 6-month security nightmare.

Or, if you want everything ready to go, grab the complete guide for $29 →
It has all the templates, checklists, and code examples already done.

Final Thoughts

I learned these lessons through expensive mistakes. You don't have to.

The smartest move isn't writing perfect code on the first try. It's creating a system that
catches mistakes before they hit production.

Checklists. Monitoring. Logging. Rollback procedures.

Boring? Maybe. But your ops team will love you. Your users won't experience outages. Your
CEO won't yell at you.

Worth it.

Have you made any of these mistakes? What did you learn? Let me know in the comments—I'd
love to hear about your deployment war stories.

And if you're looking for a complete system to avoid these issues, I've put together
everything here for $29 →

What's Inside the Guide

Since I keep mentioning it, here's what you actually get for $29:

The Guide:

25 pages of production deployment knowledge
Everything from pre-deployment config to post-deployment monitoring
Real errors and how to solve them

The Code:

9 production-ready TypeScript templates
- JWT Authentication
- CORS Handler
- Rate Limiting
- Caching Strategy
- Security Headers
- Structured Logging
- Input Validation
- Health Checks
- Complete Worker Setup

The Checklists:

7 printable checklists (one for each phase)
- Pre-Deployment
- Security
- Performance
- Testing
- Monitoring
- Deployment Day
- Post-Deployment

The Extras:

Configuration examples
Complete troubleshooting guide
FAQ with 20+ answered questions

Everything ready to use, customize, and scale.

Get it for $29 →

30-day money-back guarantee if you're not satisfied.