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.

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

Task 1: Introduction

Linux is a robust and cost-effective alternative to closed-source operating systems for hosting critical services. However, deploying Linux securely requires system hardening. This …

Read more

Connecting a Huawei SmartLogger 3000 to the cloud via a cellular 4G router, such as the TP-Link TL-MR6400, often presents routing and subnet mismatch challenges for solar PV installers.

This post provides a quick troubleshooting guide and step-by-step instructions to resolve gateway mismatches and connect your SmartLogger to the Huawei FusionSolar management system (NMS).

1. Network Theory: Subnets, Gateways, and DNS

To understand why connection issues occur, we must look at how data travels across the network. A foundational framework for this is the OSI (Open Systems Interconnection) Model, which divides network communication into seven logical layers:

Figure 1: Visual representation of the 7 OSI layers mapping to our SmartLogger setup.

While a complete connection relies on all seven layers, troubleshooting connectivity issues almost always starts at the bottom three layers: Physical (Layer 1), Data Link (Layer 2), and Network (Layer 3). Let's examine these core concepts in detail:

Subnetting and Subnet Masks

An IP address consists of two parts: the network address and the host address. The Subnet Mask determines where the division lies. For example, with a standard subnet mask of 255.255.255.0 (or a /24 prefix):

• Devices on the 192.168.8.x network can only communicate directly with other devices on 192.168.8.x.

• Devices on the 192.168.7.x network are isolated and cannot see the 192.168.8.x network, even if they are plugged into the same switch.

The Role of the Default Gateway

When a device (like a SmartLogger) wants to send a packet to an IP address outside its local subnet (for example, to a cloud server on the internet), it cannot send it directly. Instead, it must forward the packet to a local coordinator called the Default Gateway (typically your router). For routing to work:

1. The Default Gateway's IP address must be on the same subnet as the device's local interface.

2. If your device has an IP of 192.168.8.20, its gateway must be something like 192.168.8.1 or 192.168.8.2. It cannot be on another subnet like 192.168.0.1.

Domain Name Resolution (DNS)

When connecting to a server like intl.fusionsolar.huawei.com, the logger must translate that domain name into a numeric IP address. The DNS Server is responsible for this lookup. If your DNS setting is incorrect or pointing to a dead gateway, the logger will fail to resolve the domain, resulting in connection timeouts.

Solar PV Telemetry Architecture: Local Modbus to Cloud WAN

To contextualize this network theory, consider the physical and logical flow of telemetry in a typical commercial solar installation:

1. Data Acquisition (Field Level): Solar inverters, grid meters, and weather sensors (measuring solar irradiance and module temperature) generate raw telemetry. These devices communicate locally via RS-485 serial daisy-chains using the Modbus RTU protocol, or via local switches using Modbus TCP.

2. Data Aggregation (Edge Level): The SmartLogger acts as the network coordinator (Modbus Master), polling the slaved inverters and sensors at regular intervals (e.g., every 5 minutes) to gather active power outputs, voltage readings, and environmental diagnostics.

3. Data Transmission (WAN Level): The SmartLogger packetizes this data, encrypts it via SSL/TLS, and routes it out of its WAN interface into a local router (like the 4G TP-Link). The router forwards these outbound TCP packets across cellular or fiber WANs to the FusionSolar Cloud Network Management System (NMS).

The "Local vs. Cloud" Diagnostic Trap

When the default gateway is misconfigured, a classic diagnostic mismatch occurs:

• Locally: The SmartLogger successfully polls the inverters via local Modbus. The inverter status LEDs blink green, showing active generation.

• Remotely: The central NMS cloud portal registers the entire solar plant as offline and triggers alarms because the SmartLogger's outbound TCP packets cannot route past the misconfigured local gateway.

• The Trap: Field technicians often troubleshoot the physical cabling or serial Modbus parameters first, failing to realize the fault is a simple Layer 3 IP routing mismatch between the logger WAN port and the cellular router.

2. Case Study: Troubleshooting a Connection Mismatch

Let's look at a common scenario where a technician is onsite attempting to configure a SmartLogger using a laptop.

The Diagnostic State

To configure the SmartLogger without losing internet connectivity, the laptop is connected to two network ports simultaneously:

• Port 1 (Physical LAN Port): Connected via Ethernet cable directly to the SmartLogger.

  • Laptop IP: 192.168.7.100 (Static)

  • Destination Local WebUI: 192.168.7.10

• Port 2 (Wireless Wi-Fi Card): Connected wirelessly to the TP-Link Router.

  • Laptop IP: 192.168.8.100 (DHCP)

  • Default Gateway (Internet): 192.168.8.2

Laptop Dual-Routing Behavior

In this state, the laptop's operating system maintains two distinct routing paths:

1. Local Subnet Traffic: Packets bound for 192.168.7.x are routed directly out of the physical Ethernet interface to access the SmartLogger's local WebUI (Enspire).

2. Internet-Bound Traffic: All external traffic (requests to NMS portals, search engines, etc.) is routed out of the wireless interface to the TP-Link router (192.168.8.2), which serves as the default gateway. The SmartLogger is not a gateway router and does not provide internet access to the laptop over the LAN cable.

Running ipconfig on the PC displays the active configuration:

Figure 2: ipconfig output proving the TP-Link router resides on 192.168.8.2.

The Root Cause of Connection Failure

The SmartLogger's WAN port was configured with a static IP of 192.168.8.11, which matches the router's subnet (192.168.8.x). However, two critical parameters were misconfigured:

1. Default Gateway: Set to 192.168.8.1. Since the router is actually at 192.168.8.2 (as confirmed by the PC's Wi-Fi network gateway), all internet-bound packets from the logger were being sent to a non-existent IP address.

2. Primary DNS: Set to 192.168.8.1, which also failed to resolve.

Subnet Conflict & Ambiguity (LAN vs. WAN)

By default, the Huawei SmartLogger's LAN interface is pre-configured with the IP address 192.168.8.10 (subnet 192.168.8.x). However, the TP-Link cellular router also routes traffic on the 192.168.8.x subnet.

If the SmartLogger's LAN port is left at its default IP, connecting its WAN port to the TP-Link router results in a subnet routing conflict—where both physical interfaces belong to the same IP subnet. Since a device cannot distinguish routing paths when two active interfaces share a subnet, the routing table becomes ambiguous. To resolve this, the installer must change the SmartLogger's LAN port IP to a different subnet, such as 192.168.7.10 (subnet 192.168.7.x). This isolates local configuration traffic from WAN internet traffic.

Figure 3: Visual mapping of the routing mismatch (left) and the corrected working topology (right).

3. Practical Steps: Establishing the Connection

To connect the SmartLogger 3000 to the internet through the TP-Link router, perform the following steps:

Step 1: Physical Cabling

Connect a standard RJ45 Ethernet cable from the WAN port of the SmartLogger to one of the yellow LAN ports of the TP-Link router. Keep your laptop plugged into the SmartLogger's LAN port to access the settings.

Step 2: Configure Wired Network Parameters

Log in to the Enspire WebUI (default LAN IP https://192.168.8.10 or your custom IP, e.g., https://192.168.7.10). Navigate to Settings > Comm. Param. > Wired Network and configure the WAN parameters:

Figure 4: Wired Network configuration settings in Enspire.

• WAN/LAN port working mode: Set to WAN+LAN (default).

• IP Address: Set to 192.168.8.20 (use a static IP outside the router's DHCP pool—typically .100 to .199—to avoid IP conflicts).

• Subnet Mask: 255.255.255.0

• Default Gateway: 192.168.8.2 (Matching the router's LAN IP).

• Primary DNS Server: 8.8.8.8 (Google Public DNS).

• Secondary DNS Server: 8.8.4.4 (Backup DNS).

Click Submit to save and apply the settings.

Step 3: Configure the Management System (NMS)

Navigate to Settings > Comm. Param. > Management System to connect the logger to the Huawei FusionSolar cloud portal:

Figure 5: NMS settings showing successful connection status.

• Server: intl.fusionsolar.huawei.com (or regional servers like sg5.fusionsolar.huawei.com for Southeast Asia).

• Port: 27250 (or 25000 depending on the portal's SSL requirements).

• Address Mode: Logical address.

• SSL Encryption: Enable.

Click Submit. After a few moments, the NMS connection status should change from Connecting to Connected, verifying the logger is online and reporting telemetry successfully.

4. Troubleshooting Summary Checklist

When setting up solar monitoring network devices, always verify:

• Router IP Address: Double-check your router's actual LAN IP rather than assuming it is .1 or .254.

• Static IP Safety: Choose static IPs that sit outside your router's active DHCP range to prevent random connection dropouts due to IP conflicts.

• Gateway Congruence: Ensure your device's static gateway matches the router IP on the same subnet.

• DNS Verification: Configure a public DNS (e.g. 8.8.8.8) if your router does not support local DNS forwarding.

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

Task 1: What Is Defensive Security?

Defensive security focuses on preventing, detecting, and mitigating cyberattacks. Defenders, collectively known as the Blue Team, must adopt a defense mindset—understandin…

Read more

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

Task 1: Introduction

Cryptography is the practice of securing communications by mathematical scrambling, ensuring the confidentiality and integrity of data in transit. In a digital world where informatio…

Read more

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

Task 1: Introduction

JavaScript is a versatile programming language used widely for client-side interactions in web browsers and server-side applications through Node.js. In this room, we will build a …

Read more

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

Task 1: Introduction

Cybersecurity focuses on protecting the digital world—systems, networks, and applications. Specifically, security measures guard three core aspects of data: confidentiality, integrity, and a…

Read more

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

Task 1: Introduction

Python is a popular, high-level, general-purpose language widely used in automation, script writing, web applications, and data science. In this room, we will build a basic "Guess the …

Read more

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

Task 1: Introduction

This section introduces the Windows Command Prompt (CMD), a text-based interface where users type commands instead of clicking menus to interact with the system. Cybersecurity professio…

Read more

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

Task 1: Introduction

Computers store all data as numbers, relying on an agreed-upon mapping known as encoding to convert these numbers into characters like letters, punctuation, and emojis. Because each characte…

Read more