This is my write-up for the TryHackMe room on Report Writing for SOC L2. Written in 2026, I hope this write-up helps others learn and practice cybersecurity.

Task 1: Introduction

Moving into an L2 SOC analyst role means communicating findings outside the internal queue. L1 analysts log ticket notes; L2 analysts write structured incident summaries for lead…

Read more

This is my write-up for the TryHackMe room on SOC L2 Alert Triage. Written in 2026, I hope this write-up helps others learn and practice cybersecurity.

Task 1: Introduction

The SOC Level 2 role centers on investigating escalated alerts and managing active incidents. While L1 analysts focus on initial alert review and SLA metrics, L2 analysts dive deeper i…

Read more

It almost feels easy to blame others for something that you fail at, blame nearby people, or yet, while you have to decide the things you need to do.

You are searching for who must be responsible for your failure, instead of getting focused on being a better person than yesterday. Something that I realize, because the goal is very simple.

You just need to be better than yourself yesterday, do your best today, and then do better tomorrow. I will start trying to do math for a real example.

The example is you are trying to do regular push-ups today, so how many should you do? You just need to do 1 push-up, yes just one push-up. And for tomorrow, let's say you do 2 push-ups; you just need to add 1 each day.

In the gym, maybe we can call this "progressive overload."

So how about in one quarter? You will do approximately 90 push-ups. How about 6 months, and how about 1 year?

365 push-ups

How many total regular push-ups do you do in just one year?

If it happens to be a 366-day leap year, the final total would be 67,161 push-ups.

That is just push-ups; I prefer to choose that because we can do it more easily, even just in the bedroom or another place.

How about other things? Maybe writing? You just need to change the 1 push-up to a word.

I think it will be even more possible that in one year you can create more than 67,161 words originally.

This is my write-up for the TryHackMe room on Complimentary. Written in 2026, I hope this write-up helps others learn and practice cybersecurity.

Task 1: Complimentary

The Byte Lotus Wellness web application (http://complimentary-wellness-app-332173347248.s3-website-us-east-1.amazonaws.com/) delivers a login-free experience that automatically recognizes u…

Read more

This is my write-up for the TryHackMe room on Packed Light. Written in 2026, I hope this write-up helps others learn and practice cybersecurity.

Task 1: Packed Light

The Packed Light room challenges analysts to investigate suspicious network traffic captured from a hotel guest network (traffic.pcapng). The capture shows an infected host regularly beaconin…

Read more

This is my complete walkthrough for the Room 404 room on TryHackMe (Hacker Holidays Day 2). In this challenge, we perform directory enumeration against an unlisted web application hosted on port 8080, locate an exposed .git version control repository, dump the source code, and recover the flag.

Read more

This is my complete walkthrough for The Concierge Knows Too Much room on TryHackMe (Hacker Holidays Day 1). In this challenge, we analyze VERA (Very Efficient Resort Assistant), an AI concierge bot protecting an internal escalation code, and bypass its safety system instructions through prompt injection and persona impersonation.

Read more

Complete walkthrough for the Intro to Cloud Security TryHackMe room. Learn cloud delivery models, security risks, IAM, networking, storage, and policies.

This is my complete walkthrough and write-up for the Intro to Cloud Security room on TryHackMe. In this room, we examine core cloud deployment models, shared responsibility frameworks, data lifecycles, …

Read more

Walkthrough for OWASP API Security Top 10 - Part 1 TryHackMe room. Master BOLA, BUA, excessive data exposure, rate limiting, and function authorization.

This is my complete walkthrough and write-up for the OWASP API Security Top 10 - 1 room on TryHackMe. In Part 1 of this series, we explore the top 5 API security risks, analyzing vulnerable endpoints, ex…

Read more

This is my complete walkthrough and write-up for the Virtualization and Containers room on TryHackMe. In this room, we examine the fundamental concepts of virtualization, hypervisors, Docker containers, and Kubernetes cluster orchestration.

Read more

This is my complete walkthrough and write-up for the Network Security Protocols room on TryHackMe. In this room, we examine primary protocols essential for network security across each layer of the OSI model.

Read more

This write-up covers the Network Device Hardening room on TryHackMe. We will configure secure virtual private networks, build router firewall rules, implement secure administration protocols, and deploy network monitoring tools.

Read more

This is my complete walkthrough and write-up for the Active Directory Hardening room on TryHackMe. In this lab, we will cover key techniques for hardening Active Directory (AD) environments, including secure authentication settings, the Tiered Access Model, Group Policy Objects, and mitigating common AD attacks.

Read more

Earlier this year, while configuring Content Security Policy (CSP) options for my apps, I ran into a cryptic configuration error in the Astro framework. To help other developers, I submitted a pull request directly to the Astro core repository: docs(csp): improve validation messages for directives (withastro/astro#16685) which successfully closes issue #16663.

Here is a full technical walkthrough of the problem, the codebase implementation, and what I learned from contributing to a major open-source project.

The Problem: Cryptic Zod Union Errors

Astro uses the Zod library to define and validate its configuration schema. Zod is excellent for validating structures, but it can struggle with user-friendly messages when checking union types.

In Astro's security configuration, users can define CSP directives in security.csp.directives. However, because of how browser parsers behave, the directives script-src and style-src must be handled separately using dedicated options like security.csp.scriptDirective and security.csp.styleDirective.

If a developer mistakenly placed script-src directly into the general directives array like this:

// astro.config.mjs
export default defineConfig({
  security: {
    csp: {
      directives: ["script-src 'self'"]
    }
  }
});

Astro's validation engine would output a frustratingly vague error:

[config] Astro found issue(s) with your configuration:
! security.csp: Did not match union.

This occurred because the configuration schema evaluated the input against a union of valid directives and fell back to the generic Zod union error, leaving the developer with no indication of what went wrong or how to fix it.

The Solution: Refactoring Zod Schema & Custom Error Maps

To resolve the issue and provide clear, actionable instructions, we had to apply a two-step surgical update to the Astro core package.

Figure 1: The lifecycle flow of a custom configuration validation error traversing the schema and zod-error-map.

1. Refactoring schema validation with superRefine

In packages/astro/src/core/csp/config.ts, the original schema for checking allowed directives was a simple z.custom returning a boolean check:

export const allowedDirectivesSchema = z.custom<CspDirective>((value) => {
  if (typeof value !== 'string') {
    return false;
  }
  return ALLOWED_DIRECTIVES.some((allowedValue) => {
    return value.startsWith(allowedValue);
  });
});

I refactored this validator to use .superRefine. This allowed us to inspect the invalid inputs and attach distinct custom issues depending on the specific error context:

export const allowedDirectivesSchema = z.custom<CspDirective>((v) => typeof v === 'string').superRefine(
  (value, ctx) => {
    const isAllowed = ALLOWED_DIRECTIVES.some((allowedValue) => {
      return value.startsWith(allowedValue);
    });
    if (!isAllowed) {
      if (value.startsWith('script-src') || value.startsWith('style-src')) {
        ctx.addIssue({
          code: z.ZodIssueCode.custom,
          message: `Directives \`script-src\` and \`style-src\` are not allowed in \`security.csp.directives\`. Please use \`security.csp.scriptDirective\` and \`security.csp.styleDirective\` instead.`,
          fatal: true,
        });
      } else {
        ctx.addIssue({
          code: z.ZodIssueCode.custom,
          message: `Invalid directive: "${value}". Allowed directives are: ${ALLOWED_DIRECTIVES.join(', ')}`,
          fatal: true,
        });
      }
    }
  },
);

2. Surfacing custom messages in zod-error-map.ts

Even with superRefine adding the custom issues, Zod's default union error formatter would still swallow the custom messages during validation formatting.

To fix this, we updated Astro's custom Zod error formatter in packages/astro/src/core/errors/zod-error-map.ts. We intercepted custom issue codes containing security.csp and directly pushed the custom messages to the expected error shape array:

if (
  _issue.code === 'custom' &&
  _issue.message &&
  _issue.message.includes('security.csp')
) {
  expectedShape.push(_issue.message);
} else if ('expected' in _issue && typeof _issue.expected === 'string') {
  expectedShape.push(
    relativePath ? `${relativePath}: ${_issue.expected}` : _issue.expected,
  );
}

This bypasses the union-flattening logic, successfully outputting our clean, helpful instructions to the developer's console.

Testing the Validation

To ensure the new error mapping behaves correctly, I added a new unit test in packages/astro/test/units/config/config-validate.test.ts:

it('should provide a helpful error message when script-src or style-src is used in directives', async () => {
  const configError = await validateConfig({
    security: {
      csp: {
        directives: ["script-src 'self'"],
      },
    },
  }).catch((err) => err);

  const formattedError = stripVTControlCharacters(formatConfigErrorMessage(configError));
  assert.equal(
    formattedError,
    `[config] Astro found issue(s) with your configuration:\n\n! security.csp: Did not match union.\n  > Expected type boolean | Directives script-src and style-src are not allowed in security.csp.directives. Please use security.csp.scriptDirective and security.csp.styleDirective instead.\n  > Received { "directives": [ "script-src 'self'" ] }`,
  );
});

The test runs a config validation, formats the message, strips terminal coloring control characters, and asserts that our specific help instruction is rendered perfectly alongside the union error representation.

Contribution Takeaways

Contributing to Astro's core was a fantastic experience. The codebase is clean, well-tested, and uses changesets to automate package version patches. Because this validation error directly affects DX (Developer Experience), it was merged quickly and rolled out in a patch release, resolving configuration confusion for thousands of developers worldwide.

Thanks for reading. See you in the next lab.

We have all done it. We open our AI coding assistant, type a vague command like "implement OAuth login" or "refactor this database handler", and hit enter.

Immediately, the autonomous agent starts spinning. It refactors three files, creates two new utility modules, updates the dependencies, and generates a massive diff. You compile, and the build fails. You realize the AI made a dozen unchecked assumptions about your architecture, secret keys, and routing structures.

Vague prompts are the absolute enemy of autonomous coding. To fix this, we need to change how we interact with our agents. Instead of letting them guess, we need to let them interrogate us.

Enter the Grill-Me paradigm.

Figure 1: Comparison of execution cycles: Vague prompts lead to broken builds, whereas Socratic alignment loops produce clean, surgical code edits.

Originally developed as part of Matt Pocock's skills repository, the grill-me skill shifts the human-agent relationship from black-box execution to an interactive Socratic alignment loop.

The Socratic Flow: How the Grill Works

The mechanics of the grill-me skill are intentionally restrictive and highly disciplined:

1. One Question at a Time: The agent is forbidden from dumping a list of questions. It must ask exactly one probing question at a time to keep your cognitive load low.

2. Recommended Answers: For every question asked, the agent must propose a suggested answer (e.g., "Recommended: Use the existing auth helper in utils.js"). You can accept it with a simple yes or refine it with your own input.

3. Codebase Awareness: The agent is instructed to explore your codebase first. It should never ask you questions that can be answered by looking at your files.

This creates a systematic decision tree. You resolve dependencies one by one before a single line of code is edited.

The Developer's Lens: Resolving Plan Confusion

As developers, we often start tasks feeling slightly confused or overwhelmed. We know the high-level goal, but we haven't mapped out the edge cases or implementation details.

When you prompt an agent with /grill-me, it forces you to pause.

By interviewing you, the AI acts as a sounding board. As you respond to its questions, you are forced to clarify your own requirements. You decide on routing parameters, database constraints, and error boundaries before writing code.

Instead of staring at a blank editor trying to plan, you simply answer a sequence of simple prompts. By the time the interview is complete, you and the agent share a perfect, validated blueprint of the task.

The Agent's Lens: Preventing Wasted Autonomy

From the AI agent's perspective, vagueness is a recipe for context drift and token waste.

When an agent doesn't have clear requirements, it is forced to hallucinate constraints. It might over-engineer a simple solution or refactor unrelated files. Once it takes a wrong turn, it gets stuck in feedback loops, burning through your API limits.

Grilling the user beforehand acts as a guardrail. It locks down the implementation parameters (like library versions, error formats, and target paths). This keeps the agent's edits surgical, reduces token usage, and increases the success rate of the build on the first attempt.

Getting Started with Grill-Me

You can add the grill-me skill to your agent's configuration using the following command:

npx skills add https://github.com/mattpocock/skills --skill grill-me

Once installed, simply prefix your complex tasks with /grill-me (e.g., /grill-me I want to add a caching layer to our API routes) to initiate the interview.

By shifting the starting line from writing code to answering questions, you eliminate guesswork, save your API budget, and build a clearer understanding of your own projects.

Thanks for reading. See you in the next experience.

In a world engineered for hyper-stimulation, doing absolutely nothing has become a radical act. Between doom scrolling, notifications, and background music, our brains are constantly flooded with cheap dopamine.

Recently, I began practicing a simple ritual: the 10-minute wall-staring method. Before starting a 3-hour session of deep study or deep work, I sit in a chair and stare at a completely blank wall for exactly ten minutes. No phone, no music, no food - just me and the wall.

This simple practice has transformed my productivity, but I quickly realized it has a strict prerequisite: mental visual clarity. Here is how the method works, why it is deeply connected to strict self-control, and how intentional boredom resets your focus.

The Mirror of the Wall: Connecting to Self-Control

"If you want to destroy any nation without war, make adultery or nudity common in the young generation."
Saladin the Wise

This ancient observation points to a timeless truth: a society's focus and strength are directly tied to its self-control. On an individual level, the same principle applies. If you want to destroy your own focus without effort, flood your mind with hyper-stimulation.

When you stare at a blank wall, there are no external inputs to distract you. You are looking at a blank canvas. Factually, your eyes see nothing, which means the wall becomes a projector for your internal thoughts. It reflects whatever you have been feeding your mind.

If you do not exercise strict self-control (especially regarding highly stimulating content like sexual content, nudity, or doom scrolling), staring at a blank wall becomes significantly harder.

In that blank space, your brain attempts to replace the lack of external visual stimulation with internal imagery. If your mind is cluttered with hyper-sexualized thoughts or the residue of cheap stimulation, those unclean loops will flood your consciousness. You will struggle to sit still, get anxious, and find it extremely difficult to maintain peace. This discipline is found across many spiritual traditions, most strictly in Islamic teachings on guarding one's gaze and thoughts.

To reap the benefits of the wall-staring method, you must first keep your mental canvas clean. Cultivating self-control removes the high-stimulus clutter, allowing the blank space of the wall to remain calm rather than chaotic.

The Friction of Extreme Boredom

Staring at a wall for ten minutes sounds easy until you try it.

Around the three-minute mark, an intense, crushing boredom sets in. Your brain, desperate for a dopamine hit, will start suggesting alternative, "productive" distractions. You will think:

• "This is a waste of time. Doing push-ups would be much better than doing nothing!"

• "I should quickly tidy up my desk."

• "Let me plan my study schedule instead."

The core rule of the method is that you must hold. You must resist even productive urges until the 10-minute timer is completely finished. You have to sit through the friction of doing nothing.

Re-calibration: Deep Work as a Reward

The magic of the wall-staring method lies in the phenomena of measurable, intentional boredom. By forcing your brain to experience absolute inactivity, you lower your dopamine threshold.

Figure 1: Comparison of dopamine thresholds: over-stimulation blocks cognitive tasks, while wall-staring recalibrates sensitivity.

If you spend ten minutes staring at a blank wall, your baseline adjusts. When the timer finally goes off, starting to read a technical book, writing code, or studying feels like a stimulating escape. Your brain welcomes the work because it is infinitely more engaging than the void of the wall.

By contrast, if you start your study session after doom scrolling or looking at sexual content, your dopamine threshold is raised so high that sitting down to study feels like pulling teeth.

Doing nothing with a clean mind is a powerful tool to reset your baseline, allowing you to transition easily into 3 hours of uninterrupted, deep focus.

Thanks for reading. See you in the next experience.

Earlier this year, I started a side project called Daily Threads Watermark, which is a static web application designed to help runners and fitness enthusiasts generate watermarked workout summaries and text drafts for Threads.

One of the application's most popular features was its seamless Strava integration. However, due to recent policy shifts in the Strava Developer Program, this integration is now completely broken for free-tier users. Here is what happened, how the integration worked, and the workaround for developer-athletes.

The History: Asynchronous Static Sync

Because the application is hosted as a serverless static site on GitHub Pages, we could not query the Strava API directly from the client side without leaking private credentials (Client Secret).

To solve this securely, the app was designed around an asynchronous build pipeline:

1. GitHub Actions Workflow: A cron job triggered every 30 minutes.

2. Strava API Query: The workflow read repository secrets (STRAVA_CLIENT_ID, STRAVA_CLIENT_SECRET, and STRAVA_REFRESH_TOKEN), fetched my latest run and walk distances directly from Strava's endpoints, and compiled the data.

3. Static Summary File: The workflow wrote the fetched metrics into a public JSON summary at public/data/strava-summary.json.

4. Local Consumption: When the static frontend loaded in a browser, it requested the local JSON file to pre-fill the day's distance, avoiding direct API requests from client code.

This architecture allowed for a lightweight, zero-cost, and completely secure sync cycle.

The Policy Shift: Pay-to-Play API Access

In June 2026, Strava overhauled its Developer Program. The most significant change directly affects "single-player" developers who write scripts or small tools for their personal use:

• Subscription Mandate: Access to the Standard Tier API (up to 10 athletes) now requires an active, paid Strava subscription.

• Effective Date: The policy went into effect immediately for new applications, with a grace period for existing active developer accounts ending on June 30, 2026.

Without an active Strava subscription connected to the developer account, API requests are rejected, immediately halting the GitHub Actions automated sync workflow. You can check your application status and subscription eligibility directly on your Strava API Settings Dashboard.

Figure 1: The Strava API Application dashboard displaying the banner warning that API access is updating to be subscriber-only.

The Fallback: Manual CSV Imports

Fortunately, when designing the application, I built in a fallback mechanism in anticipation of potential API outages or sync errors.

Rather than relying on automated API hooks, users can manually export their activity history from their Strava account settings and upload the CSV file directly into the browser. The application processes the CSV locally in-memory, parses the activity distances by date, and updates the daily counter dashboard without sending any data to external servers.

While the automation era of Strava's free API tier is officially over, static tools can still survive by shifting data ownership back to local browser storage and manual exports.

Follow Me on Strava

If you want to look or follow my daily workouts, feel free to check out my Strava account here:

Figure 2: Feel free to check out or follow my athlete profile at strava.com/athletes/farrosfr.

Thanks for reading. See you in the next lab.

A few weeks ago, my pull request tokio-rs/axum#3782 was merged into axum. This contribution resolves a long-standing limitation in Axum's typed routing system: the inability to support affixed (prefixed or suffixed) capture patterns in typed paths.

Here is the story behind the problem, how the macro parser was updated, and what this means for your Rust APIs.

What is Axum?

Axum is a modern web application framework built for Rust, the systems programming language known for memory safety, performance, and concurrency. Axum is developed as part of the Tokio ecosystem (Rust's premier asynchronous runtime), making it highly efficient for handling concurrent network traffic at scale.

Axum stands out because of its ergonomic, declarative programming model:

1. Type-Safe Routing: Routes map requests directly to handler functions.

2. Extractors: Handlers extract parameters (such as JSON payloads, headers, query parameters, or paths) directly from signature arguments using types.

3. Middleware: Built on top of the tower ecosystem, allowing modular middleware stack reusability.

Here is a simple example of a standard Axum server setup in Rust:

use axum::{routing::get, Router};

#[tokio::main]
async fn main() {
    // Define routing and handlers
    let app = Router::new()
        .route("/", get(hello_world))
        .route("/users/{id}", get(get_user));

    // Run server on localhost:3000
    let listener = tokio::net::TcpListener::bind("127.0.0.1:3000").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

async fn hello_world() -> &'static str {
    "Hello, World!"
}

async fn get_user(axum::extract::Path(id): axum::extract::Path<u32>) -> String {
    format!("User ID: {}", id)
}

By leveraging Rust's strong static typing and macro system, Axum compiles checks for route correctness, route parameters, and request payload safety at build time.

The Problem: Segment-Bound Captures

Axum provides a powerful macro-based router extension called TypedPath. It allows developers to define type-safe routes by deriving the TypedPath trait on structs representing route parameters:

use axum_extra::routing::TypedPath;
use serde::Deserialize;

#[derive(TypedPath, Deserialize)]
#[typed_path("/users/{id}")]
struct ShowUser {
    id: u32,
}

However, the previous typed path parser in axum-macros split route paths strictly by the / separator and assumed each path segment was either entirely static or entirely a capture (surrounded by { and }).

This design meant route patterns with prefixed or suffixed captures (such as /@{username} for user profiles or /files/{name}.json for format extensions) would fail to compile, even though they are perfectly valid route patterns in standard routers.

The Solution: Parsing Affixed Captures

To solve this, we needed to update the macro parser in axum-macros/src/typed_path.rs. Instead of checking if a segment starts and ends with braces, we updated the parser to scan for capture brackets inside each path segment.

Figure 1: Visual flowchart showing the parsing logic extracting static prefixes, capture keys, and static suffixes from a route segment.

Here is the core logic implemented in the PR to split segments by capture boundaries while handling double-brace escaping (e.g., {{escaped}}):

fn parse_path(path: &LitStr) -> syn::Result<Vec<Segment>> {
    let value = path.value();
    let mut segments = Vec::new();
    let mut rest = value.as_str();

    while let Some(start) = find_first_not_double(b'{', rest.as_bytes()) {
        if start > 0 {
            segments.push(Segment::Static(rest[..start].to_owned()));
        }

        rest = &rest[start + 1..];

        if let Some(end) = rest.find('}') {
            let capture = &rest[..end];
            if capture.is_empty() || capture.contains('{') {
                return Err(syn::Error::new_spanned(path, "invalid capture in path"));
            }

            segments.push(Segment::Capture(
                capture.strip_prefix('*').unwrap_or(capture).to_owned(),
                path.span(),
            ));

            rest = &rest[end + 1..];
        } else {
            segments.push(Segment::Static(format!("{{{rest}")));
            rest = "";
        }
    }

    if !rest.is_empty() {
        segments.push(Segment::Static(rest.to_owned()));
    }

    Ok(segments)
}

We also introduced a helper function, find_first_not_double, to skip escaped braces so they are treated as static route components rather than dynamic captures:

fn find_first_not_double(needle: u8, haystack: &[u8]) -> Option<usize> {
    let mut possible_capture = 0;
    while let Some(index) = haystack
        .get(possible_capture..)
        .and_then(|haystack| haystack.iter().position(|byte| byte == &needle))
    {
        let index = index + possible_capture;

        if haystack.get(index + 1) == Some(&needle) {
            possible_capture = index + 2;
            continue;
        }

        return Some(index);
    }

    None
}

Verifying with Formatting & Tests

A crucial part of TypedPath is implementing the Display trait so path instances can be formatted back into URLs:

let path = PrefixedCapture { username: "alice".to_owned() };
assert_eq!(format!("{}", path), "/@alice");

Because the parser now isolates the static prefix and suffix parts of a segment, TypedPath preserves formatting, percent-encodes capture values correctly (e.g. spaces turn into %20), and supports all standard Rust primitive types and custom deserialize structures.

The test coverage added in the PR ensures that prefixed, suffixed, and escaped routes compile and execute correctly:

#[derive(TypedPath, Deserialize)]
#[typed_path("/@{username}")]
struct PrefixedCapture {
    username: String,
}

#[derive(TypedPath, Deserialize)]
#[typed_path("/files/{name}.json")]
struct SuffixedCapture {
    name: String,
}

This PR makes Axum's typed routing much more flexible and brings full path matching parity with standard dynamic route definitions.

Thanks for reading. See you in the next lab.

This is my write-up for the TryHackMe room on Microsoft Windows Hardening. Written in 2026, I hope this write-up helps others learn and practice cybersecurity.

Task 1: Introduction

System hardening improves a workstation's security posture by reducing vulnerabilities in its services, identity permissions, network connectivity, storage configurations, and …

Read more

I recently shared a post on Threads about how generous Cloudflare's free tier is for side projects.

This isn't theoretical. I run a production app on this exact stack, handling 27,000+ requests per day with zero errors and an average CPU time of 5.24ms per request, all without paying a single cent.

Figure 1: Cloudflare D1's free tier includes 5 GB storage, 5 million reads/day, and 100,000 writes/day.

Why Cloudflare's Free Tier?

Most cloud providers give you a "free trial" that expires after 30 days. Cloudflare's free tier is permanent. No credit card required, no surprise bills. For indie developers and side projects, this is a game changer.

Here's what you get for free:

Figure 2: Summary of Cloudflare's permanent free tier limits for Workers, D1 database, KV store, and Pages.

Combined, this gives you a full-stack platform: compute, database, caching, and static hosting, all at the edge, globally distributed.

Figure 3: A real production dashboard. 27K requests in 24 hours, 0 errors, bindings for D1, KV, Assets, and Images.

The Architecture

The key insight from my experience: not everything needs to be server-rendered. By using Astro's hybrid rendering mode, you can prerender static pages at build time and only use SSR for pages that genuinely need real-time data. This dramatically reduces your D1 reads and keeps you well within free tier limits.

┌─────────────────────────────────────────────────┐
│                  Cloudflare Edge                │
│                                                 │
│  ┌──────────┐   ┌──────────┐   ┌─────────────┐  │
│  │  Assets  │   │  Worker  │   │     KV      │  │
│  │ (Static) │   │  (SSR)   │◄──│  (Sessions) │  │
│  └────┬─────┘   └────┬─────┘   └─────────────┘  │
│       │              │                          │
│       │              ▼                          │
│       │         ┌──────────┐                    │
│       │         │    D1    │                    │
│       │         │   (SQL)  │                    │
│       │         └──────────┘                    │
│       ▼                                         │
│   Static Pages    Dynamic Pages                 │
│   (prerendered)   (server-rendered)             │
└─────────────────────────────────────────────────┘

Static pages (homepage, about, blog posts) are prerendered at build time and served directly from the Assets binding. No Worker invocation, no D1 reads.

Dynamic pages (dashboard, user settings, API routes) are server-rendered by the Worker, which queries D1 for data and KV for session management.

Edge Routing with _routes.json

When you build an Astro hybrid application, the @astrojs/cloudflare adapter automatically generates a _routes.json file in the build output (dist/). This file is a configuration manifest for Cloudflare's edge router, defining:

• Include rules: Wildcard patterns for routes that must invoke the Worker (e.g., /bookmarks, /api/*).

• Exclude rules: Patterns for routes that should bypass the Worker completely and serve static assets directly from Cloudflare's CDN storage (e.g., /about, /_astro/*, /favicon.svg).

A typical automatically generated _routes.json looks like this:

{
  "version": 1,
  "include": [
    "/bookmarks",
    "/api/*"
  ],
  "exclude": [
    "/about",
    "/_astro/*",
    "/favicon.svg"
  ]
}

Because this routing happens at Cloudflare's CDN layer before reaching the Worker:

1. 0ms Worker CPU Time: Static pages cost zero Worker compute, leaving the full 10ms CPU limit for dynamic endpoints.

2. 0 Worker requests count: Excluded routes do not count toward your daily 100,000 Workers request quota.

Serverless SQL Without Connection Pooling

In a traditional cloud setup (such as AWS Lambda or traditional VMs), scaling serverless functions requires connecting to a relational database like PostgreSQL or MySQL. This introduces two major performance bottlenecks:

1. TCP Handshake Latency: Creating new database connections is slow and expensive.

2. Connection Exhaustion: High concurrent traffic can crash the database by exhausting available connections, requiring complex external poolers (like PgBouncer).

Cloudflare D1 is different. It is a serverless SQL database built on SQLite that runs directly inside Cloudflare's V8 isolate environment. Because the database bindings are native, there is zero TCP connection overhead and zero pool limit constraints. When your Worker runs a query, it accesses D1 instantly without a database cold start.

Step 1: Initialize the Project

Start by creating a new Astro project with the Cloudflare adapter:

npm create astro@latest ./my-app -- --template minimal --yes
cd my-app
npx astro add cloudflare --yes

This sets up Astro with the @astrojs/cloudflare adapter, which compiles your app into a Cloudflare Worker.

Step 2: Create the D1 Database

Use Wrangler (Cloudflare's CLI) to create a D1 database:

npx wrangler d1 create my-app-db

This outputs a database ID. Add it to your wrangler.toml (create this file in your project root):

name = "my-app"
compatibility_date = "2026-07-01"

[assets]
directory = "./dist"

[[d1_databases]]
binding = "DB"
database_name = "my-app-db"
database_id = "your-database-id-here"

Now create your schema. Create a file called schema.sql:

CREATE TABLE IF NOT EXISTS bookmarks (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  url TEXT NOT NULL,
  title TEXT NOT NULL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

Apply it:

npx wrangler d1 execute my-app-db --file=./schema.sql

Figure 4: Cloudflare D1 dashboard displaying total queries, row metrics (reads and writes), and current storage usage.

Managing D1 with a GUI

If you are used to desktop database managers like PGAdmin (for Postgres), Laragon/phpMyAdmin (for MySQL), or DBGate, you don't have to manage D1 solely via the command line. You can explore and edit your database using graphical interfaces:

1. Remote Database: Cloudflare Dashboard Console

For your deployed production database, Cloudflare provides a built-in web console and data explorer:

• Log in to your Cloudflare Dashboard.

• Navigate to Workers & Pages > D1 and select your database (my-app-db).

• Click the Console tab to run SQL queries directly in your browser.

• Click the Tables tab to browse schemas, view rows, and edit table values visually without writing SQL.

Figure 5: Cloudflare D1 Studio interface displaying visual table columns, rows, and datatypes.

2. Local Database: Standard SQLite Clients (TablePlus, DBeaver, DB Browser)

When developing locally using Wrangler's local dev server, your database state is stored as a standard SQLite file inside your project directory at: .wrangler/state/v3/d1/miniflare-D1DatabaseObject/

You can open this .sqlite file directly in any desktop SQLite client (such as TablePlus, DBeaver, DB Browser for SQLite, or the VS Code SQLite Viewer extension) to manage tables, run queries, and edit mock data locally.

Step 3: Set Up KV for Sessions

Create a KV namespace for session storage:

npx wrangler kv namespace create SESSION

Add the output to your wrangler.toml:

[[kv_namespaces]]
binding = "SESSION"
id = "your-kv-namespace-id-here"

KV is ideal for sessions because reads are extremely fast (edge-cached globally) and sessions are typically small key-value pairs. With 100K free reads/day, you can handle thousands of authenticated users.

Step 4: Configure Astro for Hybrid Rendering

Update your astro.config.mjs to enable hybrid rendering:

import { defineConfig } from 'astro/config';
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
  output: 'hybrid',
  adapter: cloudflare({
    platformProxy: { enabled: true },
  }),
});

With output: 'hybrid', pages are prerendered by default. Only pages that explicitly opt in to SSR will run on the Worker. This is how you keep your D1 reads low.

Step 5: Build a Dynamic Page

Create a server-rendered page that queries D1. Create src/pages/bookmarks.astro:

---
export const prerender = false;

const runtime = Astro.locals.runtime;
const db = runtime.env.DB;

const { results } = await db
  .prepare('SELECT * FROM bookmarks ORDER BY created_at DESC')
  .all();
---

<html>
  <body>
    <h1>My Bookmarks</h1>
    <ul>
      {results.map((b) => (
        <li>
          <a href={b.url}>{b.title}</a>
          <small>{b.created_at}</small>
        </li>
      ))}
    </ul>
  </body>
</html>

The key line is export const prerender = false. This tells Astro to server-render this page instead of prerendering it.

Step 6: Add an API Route

Create src/pages/api/bookmarks.ts to handle form submissions:

export const prerender = false;

import type { APIRoute } from 'astro';

export const POST: APIRoute = async ({ request, locals }) => {
  const db = locals.runtime.env.DB;
  const form = await request.formData();
  const url = form.get('url')?.toString();
  const title = form.get('title')?.toString();

  if (!url || !title) {
    return new Response('Missing fields', { status: 400 });
  }

  await db
    .prepare('INSERT INTO bookmarks (url, title) VALUES (?, ?)')
    .bind(url, title)
    .run();

  return Response.redirect(new URL('/bookmarks', request.url), 303);
};

Step 7: Deploy

Deploy your app to Cloudflare:

npx astro build
npx wrangler deploy

That's it. Your full-stack app is live on Cloudflare's global edge network.

Optimization: Staying Within Free Tier Limits

Here's the strategy I use to keep my app comfortably within the free tier:

1. Prerender Everything You Can

Any page that doesn't need real-time data should be prerendered. Homepage, about page, blog posts, documentation, all static. This means zero D1 reads for the majority of your traffic.

2. Use Indexes on D1

D1 counts every row scanned, not just rows returned. A full table scan on a 5,000-row table counts as 5,000 reads even if you only return 1 row. Always add indexes on columns you filter or sort by:

CREATE INDEX idx_bookmarks_created
  ON bookmarks(created_at DESC);

3. Use KV as a Cache Layer

For frequently-read but rarely-changed data, cache D1 results in KV:

const cacheKey = 'bookmarks:latest';
let cached = await env.SESSION.get(cacheKey, 'json');

if (!cached) {
  const { results } = await env.DB
    .prepare('SELECT * FROM bookmarks ORDER BY created_at DESC LIMIT 20')
    .all();
  await env.SESSION.put(cacheKey, JSON.stringify(results), {
    expirationTtl: 300,
  });
  cached = results;
}

This pattern converts D1 reads into KV reads, which have a much higher free tier limit (100K vs 5M, but KV reads are faster and reduce database load).

4. Use Astro's Built-in Static Pages

For your landing page and marketing content, keep prerender = true (the default in hybrid mode). These pages are served directly from the Assets binding with zero Worker invocations.

Final Thoughts

Cloudflare's free tier is genuinely one of the best offerings for indie developers right now. The combination of D1 (SQL database), KV (fast caching), Workers (edge compute), and Assets (static hosting) gives you a complete full-stack platform without spending a cent.

The trick is architecture: use Astro's hybrid rendering to keep static pages static, index your D1 tables properly, and cache aggressively with KV. Do this right, and you can serve tens of thousands of requests per day, completely free.

Thanks for reading. See you in the next lab.