DevCharms

A fresh start for DevCharms

Sat, 01 Mar 2025 12:00:00 GMT

This site spent a long time carrying demo posts from the original AstroPaper template. They were fine for scaffolding, but they were never really DevCharms. So we cleared the slate.

From here, this space is for honest engineering notes: things we tried, what broke, what stuck, and the occasional opinion grounded in shipping real work. The stack stays familiar—Astro, Markdown, Tailwind—but the voice is ours.

If you are reading this right after the purge, thanks for sticking around. The old URLs from the template era are gone; new posts will get their own slugs and their own reasons to exist.

Open Table of contents

What is coming next

What is coming next

Expect a mix of short stories from the terminal and longer write-ups when a topic deserves depth. No promises on cadence—only that when something ships here, it should be worth your time.

Welcome to the new chapter.

Before I hit publish on a static site

Thu, 26 Mar 2026 15:00:00 GMT

Shipping a static site can feel low risk until you remember there is no server to patch later for a broken RSS path or a typo in canonical URLs. The safety net is discipline before deploy.

Here is the checklist I actually run through—not exhaustive, but enough to catch the mistakes that waste an evening.

Open Table of contents

Build and smoke
Links and slugs
Social and feeds
Content passes
Done

Build and smoke

Run a production build locally and fix every warning you agree matters. Open the generated dist (or let CI artifacts do it) and click the pages that changed—not only the homepage.

Links and slugs

If you renamed posts or slugs, search the repo for old paths and for internal links that still point at retired URLs. Static hosts will happily serve 404 forever.

Regenerate or inspect rss.xml and any sitemap output. Feed readers do not forgive a bad link, and search engines notice when metadata drifts from the page title.

Content passes

Read the new post aloud once. Fix awkward sentences and check code fences. If you reference “today” or “this week,” decide whether it will age badly—and trim if it will.

Done

The goal is not perfection on day one. It is confidence that what you shipped matches what you think you shipped. The rest can ride in the next small change.

How CSS cascade layers let you win with lower specificity

Mon, 30 Mar 2026 12:00:00 GMT

Specificity is a useful tool until it becomes a scoreboard. You add a class, then a parent selector, then another class, and soon “winning” the cascade means out-gunning yesterday’s selectors instead of expressing intent. Cascade layers (@layer) change the game: they add a new step in the cascade—layer order—that is evaluated before specificity. That lets you keep selectors shallow and predictable while still controlling what wins.

Open Table of contents

What @layer actually does
The main benefit: order beats specificity across layers
Fewer reasons to use !important
Clear mental model for teams
How this pairs with modern CSS stacks
Practical cautions

What `@layer` actually does

The @layer at-rule groups styles into named layers. You declare an order once—often from low-level to high-level:

@layer reset, tokens, components, utilities;

Rules in utilities are considered after rules in components in the cascade, regardless of selector specificity (for normal declarations in author stylesheets). Only after layers are compared does the engine fall back to specificity, then source order.

So layers are not a replacement for specificity inside a layer; they are a way to structure conflict between kinds of styles (foundation vs. components vs. overrides) without turning every file into a specificity arms race.

The main benefit: order beats specificity across layers

Classic pain: a third-party or legacy block uses .sidebar .nav li a.active and you need a one-off tweak. Without layers, you either match or beat that specificity, reach for !important, or duplicate structure in your selector.

With layers, you might put that legacy chunk in @layer legacy and your app overrides in @layer app. A single class in app can override a long chain in legacy because the layer wins first. You are not “reducing specificity” in the mathematical sense for rules in the same layer—you are making specificity less often the deciding factor between layers you own.

That is the practical payoff: simpler selectors for the code you write every day, because where it lives in the stack is explicit.

Fewer reasons to use `!important`

!important often appears when specificity and source order leave no clean escape hatch. Layers give you a structured escalation path: add a higher layer (for example utilities or overrides) instead of marking every declaration important.

You still should not create dozens of micro-layers without reason—broad, stable layers (reset → base → components → utilities) are easier to reason about than a layer per file.

Clear mental model for teams

Layers encode intent in the stylesheet architecture:

reset / normalize — browser quirks, low precedence.
base — element defaults and typography.
components — BEM-style blocks, cards, nav patterns.
utilities — small, single-purpose helpers (spacing, visibility).

New contributors can read @layer declarations like a table of contents for the cascade. That reduces “why did this style lose?” debugging sessions that end in a 0–4–2 specificity lecture.

How this pairs with modern CSS stacks

Frameworks and build tools increasingly respect layers (for example, importing Tailwind with layered preflight and utilities). Whether you author layers by hand or adopt a layered preset, the underlying idea is the same: separate concerns by layer, keep selectors inside each concern as simple as the design allows, and let layer order carry cross-cutting priority.

Practical cautions

Unlayered author styles still sit above layered styles in the cascade for normal rules—so stray global CSS outside @layer can still surprise you. Prefer moving everything into layers once you adopt them, or be deliberate about what stays unlayered.
Same-layer conflicts still use specificity and source order; layers do not remove the need for sensible selectors inside a layer.
Scoped styles (for example in Shadow DOM) follow their own encapsulation rules; layers apply within the same origin and tree as usual, but component boundaries still matter for what actually applies.

Cascade layers are not magic—they are structure. If your project fights the cascade with ever-longer selectors, @layer gives you a way to lower the temperature: define a small number of layers, put resets and utilities in the right slots, and let order do what you used to do with specificity gymnastics.

@container: responsive layout that follows the component, not the viewport

Tue, 07 Apr 2026 12:00:00 GMT

Media queries answer a single question: how wide is the viewport? That is the right default for page-level concerns, but components rarely care about the window—they care about the space they actually get. A card might sit in a narrow sidebar or a full-width column; container queries let styles react to that box instead of guessing from 100vw.

Open Table of contents

From viewport to containment
The @container rule
- Named containers
How this differs from clamp() and flex
Practical pattern: one card, many homes
Support and progressive enhancement

From viewport to containment

Container queries need an element marked as a query container. You declare what the browser should track (usually inline size) with container-type:

.card-grid {
  container-type: inline-size;
}

inline-size — the container’s width in horizontal writing modes (what you want for most “responsive component” patterns).
size — both inline and block dimensions participate (heavier; use when you truly need height-based rules).

Optionally name the container so nested layouts stay clear:

.card-grid {
  container-type: inline-size;
  container-name: cards;
}

Shorthand:

.card-grid {
  container: cards / inline-size;
}

The `@container` rule

Inside a subtree, you write @container blocks that mirror @media, but the condition is evaluated against ancestor query containers—typically the nearest one unless you target a name.

@container (min-width: 28rem) {
  .card {
    display: grid;
    grid-template-columns: auto 1fr;
    gap: 1rem;
  }
}

When the container (not the viewport) is at least 28rem wide, those rules apply. The same .card markup can stack in a narrow rail and split in a wide main column, with one stylesheet and no duplicate breakpoints keyed to page templates.

Named containers

If multiple wrappers could qualify, pin the query to a specific container:

@container cards (min-width: 40rem) {
  .card-grid {
    grid-template-columns: repeat(3, 1fr);
  }
}

That reads cleanly in design systems: **“at this card track width, use three columns”—**not “at this screen width, maybe three columns if we are on the right page.”

How this differs from `clamp()` and flex

Fluid type and spacing (clamp(), min(), viewport units) smooth scales globally. Flex and grid distribute siblings inside a parent. Container queries add contextual breakpoints: “when this layout region is wide enough, change this subtree.” They complement media queries—you still use @media for navigation patterns, page gutters, and coarse layout—but component internals often belong in @container.

Practical pattern: one card, many homes

.product-card {
  container-type: inline-size;
  container-name: product;
}

@container product (max-width: 20rem) {
  .product-card__actions {
    flex-direction: column;
  }
}

@container product (min-width: 36rem) {
  .product-card__media {
    aspect-ratio: 16 / 9;
  }
}

Drop that card into a marketing grid, a cart drawer, or a comparison table—the local width drives the local layout.

Support and progressive enhancement

Container queries and @container are widely available in current browsers. For older environments, treat container-driven rules as enhancement: base styles work everywhere; @container blocks refine layout where supported. You can mirror critical breakpoints in @media only when you must support legacy clients—but many static and content sites can ship container queries alone.

If your breakpoints are labeled sm:, md:, lg: but the real variable is “how wide is this widget,” @container is the at-rule that finally matches how you think about the UI.

Why CSS logical properties are the efficient default

Fri, 27 Mar 2026 14:00:00 GMT

For years we reached for padding-left and padding-right because the screen felt like “horizontal.” That works until you support right-to-left layouts, vertical writing modes, or you simply want one declaration instead of two. Logical properties describe space along the inline and block axes—where text flows and where blocks stack—not “west” and “east” of the viewport.

Open Table of contents

One declaration instead of two
The mental model: inline vs block
RTL without duplicate rules
Efficiency in the real sense

One declaration instead of two

If you want equal horizontal padding, this is familiar:

.card {
  padding-left: 1rem;
  padding-right: 1rem;
}

With logical properties you express the same intent in one line:

.card {
  padding-inline: 1rem;
}

You write less CSS, and the meaning is clearer: “padding on the inline axis,” not “padding on two arbitrary sides.” That is a small win in every component file—and it adds up across a design system.

The mental model: inline vs block

Inline is the direction text runs in a line (usually left-to-right in English; right-to-left in Arabic or Hebrew).
Block is the direction blocks stack (usually top-to-bottom).

So margin-inline covers start and end along the line; margin-block covers the perpendicular direction. When you use physical properties, you are naming compass directions. When you use logical ones, you are naming flow, which is what layout is actually about.

Common pairs:

Physical (two values)	Logical (one value)
`padding-left` / `padding-right`	`padding-inline`
`padding-top` / `padding-bottom`	`padding-block`
`margin-left` / `margin-right`	`margin-inline`
`width` / `height` (in flow context)	often `inline-size` / `block-size`

Shorthands like inset-inline for left+right (or their logical equivalents) follow the same idea.

RTL without duplicate rules

The big payoff is internationalization. If you mirror a layout for RTL, physical properties force you to duplicate or override rules: one block for LTR, another for RTL. Logical properties flip with the writing direction, so the same rule can serve both—no [dir="rtl"] patch for every component that used margin-left.

That is not just “accessibility”—it is less code to maintain and fewer bugs when someone adds a new panel and forgets the RTL override.

Efficiency in the real sense

“Efficiency” here is not only bytes on the wire (though fewer properties help). It is:

Fewer declarations for symmetric spacing and sizing.
One source of truth for layout that should follow writing mode.
Clearer intent for the next person reading the stylesheet.

Logical properties are well supported in modern browsers. For legacy constraints, you can still layer physical fallbacks or use tools that emit both; for greenfield components, defaulting to logical naming keeps the cascade simpler from day one.

If you are still typing left and right for symmetric gutters, try inline once—your RTL future self (and your line count) will notice.

Ditch the post-it notes: protect your business secrets with a password vault

Mon, 11 May 2026 20:00:00 GMT

A password on a post-it note stuck to a monitor is not a security strategy. Neither is a shared spreadsheet, a notebook in a desk drawer, or a Slack message that says “hey, what’s the AWS login again?” Yet these habits persist in companies of every size, from startups to publicly traded firms.

The reasoning usually sounds practical: “We only have five people,” or “I’ll remember it,” or “We’ve never had a problem.” That last one is survivorship bias wearing a name badge. The problem has not happened yet.

Open Table of contents

The real cost of “just remembering it”
AI has changed the math on password guessing
What a vault like 1Password actually gives you
”We’re too small for this”
The habit shift

The real cost of “just remembering it”

When credentials live in someone’s head—or worse, on a scrap of paper—three things quietly go wrong.

People reuse passwords. If the company WiFi password is also someone’s email password, one breach unzips everything. Verizon’s 2024 Data Breach Investigations Report found that stolen or weak credentials were involved in nearly half of all breaches. That statistic has barely moved in a decade.

Onboarding and offboarding become dangerous. A new hire asks around for the staging server password. Someone texts it. When that person leaves six months later, nobody rotates the credential. The door stays open and everyone forgets it exists.

There is no audit trail. If something goes wrong, you cannot answer the most basic question: who had access to what, and when?

AI has changed the math on password guessing

Brute-forcing a short, predictable password has always been feasible. What has changed is that large language models and purpose-built cracking tools can now make educated guesses at scale.

Researchers at Home Security Heroes demonstrated in 2023 that an AI-powered tool called PassGAN could crack over half of common passwords in under a minute and 71 percent of them in less than a day. It works by learning the patterns humans fall into—capitalizing the first letter, appending a year, substituting @ for a—and generating candidates that feel random to us but are statistically predictable to a model.

If your company’s convention is CompanyName2025! or Summer2026#, an attacker armed with a fine-tuned model, a list of leaked hashes, and commodity GPUs does not need luck. They need patience measured in hours, not years.

A password vault solves this at the source. It generates long, truly random strings—x7$qL!9mWv@kR2pZ—that no human would choose and no model can predict from patterns, because there are no patterns to learn.

What a vault like 1Password actually gives you

A password vault is not just a digital notebook with a lock. It is an infrastructure layer. Here is what it provides that you would never build or sustain on your own.

Need to give a contractor access to a staging API key? In 1Password, you share a vault or a single item. The contractor sees the credential inside the app but never copies it into a text file. When the engagement ends, you revoke access in one click. Compare that to the alternative: sending a password over email, hoping they delete it, and wondering six months later if they did.

Watchtower: breach detection you would never do manually

1Password’s Watchtower feature cross-references your stored credentials against known breach databases (like Have I Been Pwned) and flags weak, reused, or compromised passwords automatically. No human is going to check 200 service accounts against a breach list every morning. Watchtower does it continuously and silently, surfacing only the items that need attention.

Secrets automation for development teams

For engineering teams, 1Password offers a Secrets Automation platform and a CLI that inject credentials into builds, CI/CD pipelines, and server environments without ever writing them to disk or committing them to a repository. A .env file checked into Git is an open invitation. A reference to a 1Password secret that is resolved at runtime is not.

Travel Mode

Crossing an international border where devices may be inspected? 1Password’s Travel Mode lets you temporarily remove sensitive vaults from a device. Only vaults marked “safe for travel” remain visible. Once you arrive, you toggle Travel Mode off and everything reappears. Try replicating that with a notebook.

Passkey and MFA management

Passwords are already giving way to passkeys in many services. 1Password stores and autofills passkeys alongside traditional credentials, so the transition does not mean juggling yet another tool. It also serves as an authenticator for TOTP two-factor codes, consolidating what would otherwise be a mess of separate apps and backup codes.

”We’re too small for this”

You are not. A freelancer with a handful of client logins is exactly the profile that suffers most from a single breach—because there is no security team to contain the damage and no PR department to manage the fallout.

1Password’s pricing starts at a few dollars per user per month. The time you save not resetting forgotten passwords, not onboarding people through DMs, and not lying awake wondering if the intern still has the production database password will pay for itself before the first quarterly review.

The habit shift

Moving to a vault is less a technology decision than a habit change. The hardest part is the first week: importing existing passwords, agreeing on a vault structure, and convincing the person who “has a system” that their system is a liability.

After that, the daily experience is easier than what it replaces. You stop typing passwords. You stop resetting passwords. You stop wondering if that Google Doc full of credentials is shared with the right people.

Post-it notes are great for reminding yourself to buy milk. They are not where your business secrets belong.

Hunting Dictionary Bots: Inside a Sophisticated WordPress Membership Attack

Wed, 27 May 2026 12:00:00 GMT

Automated registration spam is shifting away from traditional brute-force tactics. Standard security layers often fail against modern bot scripts that pass visual challenges and bypass baseline web application firewalls. These advanced campaigns mimic legitimate human patterns to compromise open registration endpoints.

This post examines the mechanics of Dictionary Attack Bots, details the concrete risks they pose to membership platform integrity, and provides implementation code to secure your user tables.

The Membership Threat: Impact by the Numbers

Allowing automated registrations to pool in your database creates immediate operational hazards:

42% Database Inflation: Automated accounts distort core engagement metrics. They skew active user KPIs, churn rates, retention tracking, and email marketing segmentation analytics.
Origin Server Overhead: Bulk account creation triggers repetitive INSERT queries, invalidates user cache clusters, and drives high CPU utilization.
8.3x Email Delivery Risk: Automated sign-ups generate high bounce rates and trigger spam complaints during onboarding automation. This degrades your transactional email domain authority and lands critical system emails in user spam folders.
Downstream Vulnerabilities: Attackers weaponize these dormant accounts later for credential stuffing, automated API scraping, or content/comment injection.

Anatomy of the Exploit: Dictionary Word Pairing

Traditional registration scripts rely on randomized character strings (e.g., xj947_ktr). Modern security filters identify and block these strings easily. To circumvent detection, this script uses coordinated dictionary pairings.

The bot engine generates identifiers by combining two distinct English dictionary terms, appended with a single or double digit: [Noun/Adj] + [Noun] + [Digit]. This structure targets validation suites that assume standard dictionary terms indicate human input.

Data from an active database trace reveals clear structural patterns across separate registration batches:

User ID	Registered Username	Target Domain Name	Structural Formula
4372	`basketoption7`	`koiot.de`	`[Noun] + [Noun] + [Digit]`
3537	`basketperch1`	`koiot.de`	`[Noun] + [Noun] + [Digit]`
4341	`basketriver9`	`koiot.de`	`[Noun] + [Noun] + [Digit]`
4481	`basketwomen0`	`koiot.de`	`[Noun] + [Noun] + [Digit]`
4528	`actman4`	`koiot.de`	`[Noun] + [Noun] + [Digit]`
N/A	`adultmiddle4`	`calculator.city`	`[Adj] + [Noun] + [Digit]`
N/A	`actormuseum8`	`bitingmites.org`	`[Noun] + [Noun] + [Digit]`

The script rotates target domains across separate waves, altering infrastructure footprints while maintaining the underlying username generation logic. The email handles often use standard human name formats (e.g., johne@calculator.city) to blend in with valid registrations.

Defensive Engineering: Programmatic Remediation

Because these registration payloads exist entirely within the body of incoming POST requests, standard proxy layers cannot always parse or drop them based on payload content alone. Remediating this threat requires a defense-in-depth approach across your technical stack.

1. Application Layer Domain Restrictions

The fastest method for stopping active registration waves involves validating the registration array directly inside WordPress. Hooking into the registration_errors filter intercepts the registration process before the application executes a database transaction.

/**
 * Restrict known malicious domains from creating WordPress user accounts.
 * Drops the registration request before hitting the database.
 */
add_filter('registration_errors', 'devcharms_restrict_spam_domains', 10, 3);
function devcharms_restrict_spam_domains($errors, $sanitized_user_login, $user_email) {
    $banned_domains = [
        '24faw.com',
        'igtikrenai.com',
        'koiot.de',
        'temz.net',
        'emailmin.com',
        'calculator.city'
    ];

    $email_parts = explode('@', $user_email);
    $domain      = end($email_parts);

    if (in_array(strtolower($domain), $banned_domains)) {
        $errors->add(
            'banned_domain_error',
            __('<strong>ERROR</strong>: Registration parameters rejected.')
        );
    }

    return $errors;
}

2. Remediate Existing Users (Purge the Spam Already Inside)

Once these accounts exist, blocking new registrations won’t fix the damage already done to your tables and analytics. The simplest remediation path is to go to Admin → Users, search by the offending domain (for example @koiot.de), and bulk-delete the matching accounts.

This approach (Admin UI bulk delete or WP-CLI) is almost always safer than “just deleting rows” in the database. User emails and IDs can be duplicated across core and plugin tables, and a manual DB purge can leave orphaned metadata, broken relationships, or stale activity records—especially on community sites running BuddyPress, bbPress, membership plugins, or LMS/ecommerce add-ons.

Common places these users can persist include:

Core WordPress: wp_users, wp_usermeta
BuddyPress: wp_bp_activity, wp_bp_activity_meta, wp_bp_friends, wp_bp_groups*, wp_bp_notifications, wp_bp_messages*, wp_bp_xprofile*
bbPress: forum/topic/reply content in wp_posts plus related post meta in wp_postmeta
Other plugins: their own custom tables and user meta keys (memberships, LMS, ecommerce, forms, etc.)

If you have WP-CLI access, you can do the same cleanup much faster from the command line by deleting users whose email matches a domain pattern:

wp user delete $(wp user list --search="*@koiot.de" --field=ID)

Reasons to set up a Cloudflare Tunnel

Sat, 20 Jun 2026 10:00:00 GMT

Let’s say you are running a service on your home network—maybe a smart home dashboard (like Home Assistant), a private website you’re coding, or a home file server. You want to be able to access it when you are away from home, or you want a friend to look at it.

To let the outside internet in, the old-school method is called port forwarding. This is the digital equivalent of unlocking a specific window in your house, publishing your home address to the world, and hoping no burglars notice the open window.

Cloudflare Tunnel changes the game. Instead of unlocking any windows, your home computer reaches out to Cloudflare’s secure servers in the cloud and establishes a private, encrypted hallway between them. When someone wants to visit your site, they talk to Cloudflare, and Cloudflare passes the message back to your computer through this private hallway. No windows are unlocked, and your home address remains hidden.

Do I need this?

If you are running a self-hosted app, home server, or development site and need it safely accessible from the internet, a Cloudflare Tunnel is the gold standard. If you’d rather not deal with the configuration, DNS routing, or firewall settings yourself, Shrinkray Interactive can handle the entire setup for you.

To learn how tunnels work and why they are so secure, see below.

Ready to secure your network? Reach out to Greg to get your own custom tunnel configured today!

Open Table of contents

You stop opening doors on your router
If they can’t find your door, they can’t knock on it
Changing home addresses stops being a headache
Free security padlocks without the headaches
Your small project gets enterprise-grade shields
Add a bouncer to your site in two clicks
Easy integrations for developers (Webhooks)
It works even when your internet provider blocks you
The free plan is actually free and powerful
When is a tunnel not the right tool?
Time to lock the doors
Let me build your own Custom Tunnel

You stop opening doors on your router

Ports are like doors on your internet router. By default, your router blocks all incoming traffic to keep you safe. Port forwarding means you carved a small pet door into your firewall and pointed it directly at your device (like a home storage drive or computer).

The problem is that automated bots crawl the internet 24/7, shaking every door handle they can find. If you leave a port open, those bots will find it and try to exploit outdated software or guess your passwords.

With a tunnel, you don’t open any doors. The tunnel software (a tiny program running on your computer) makes an outbound connection. It’s like your computer calling out to Cloudflare and keeping the phone line open. Traffic comes in through that phone line, meaning your router’s doors remain locked tight.

For homelabs, side projects, and small business gear sitting on a consumer connection, that is a meaningful security upgrade without buying enterprise hardware.

If they can’t find your door, they can’t knock on it

Attackers can’t hack what they can’t see. When you use port forwarding, your public IP address is exposed, meaning anyone can scan your connection. If there is a bug (a security vulnerability) in your home software, they can exploit it.

With a tunnel, your home setup is invisible to the public internet. Visitors only see Cloudflare’s massive network. Think of Cloudflare as a highly trained security guard standing at the entrance of a gated community. If a bot or hacker tries to spam your site or send malicious traffic, the guard blocks them at the gate before they ever get near your actual home network.

Changing home addresses stops being a headache

Every home internet connection has an IP address—think of it as your house’s mailing address. However, home internet providers constantly change this address every few days or weeks (this is called a “dynamic IP”). If you are hosting a website, this means your site’s address is constantly changing, making it impossible for people to reliably connect to it.

Normally, you have to buy a costly “static IP” or set up complicated updater tools (Dynamic DNS) that break when you least expect it.

Because a Cloudflare Tunnel keeps a constant connection open from your computer out to Cloudflare, it doesn’t matter if your home’s mailing address changes. Cloudflare always knows where your computer is because the computer is the one keeping the connection alive. Your website name (like myproject.com) stays online without you needing to lift a finger.

Free security padlocks without the headaches

When you visit a website, you expect to see the secure padlock icon in your browser address bar. This is powered by HTTPS and an SSL/TLS certificate—a digital security badge proving your site is secure.

Setting up these certificates on your own home computer is notoriously frustrating. You have to install renewal tools, make sure they run every few months, and configure complex server software. If something breaks, visitors get a scary “This site is not secure” warning.

When you use a tunnel, Cloudflare automatically provides and manages the SSL certificate for you. Visitors get a secure, encrypted connection to Cloudflare, and Cloudflare encrypts the rest of the journey to your home computer. You get the padlock icon instantly without configuring any certificate tools at home.

Your small project gets enterprise-grade shields

Your home computer or a cheap virtual server was never designed to handle thousands of visits at once. If your site gets popular, or if a malicious group tries to overwhelm it with fake traffic (a DDoS attack), your home internet will crash.

By routing your traffic through Cloudflare’s tunnel, you get to borrow their massive global network. If a flood of traffic hits your site, Cloudflare absorbs it and only sends the legitimate visits down the tunnel to your home computer. It’s like having a giant buffer that prevents your home internet from being knocked offline.

Add a bouncer to your site in two clicks

Just because your project is online doesn’t mean you want the public to see it. Maybe it’s a private family photo album or a dashboard for your home smart devices.

Normally, keeping these secure means setting up a complex VPN (Virtual Private Network) or managing logins inside your app.

With Cloudflare, you can turn on a feature called Cloudflare Access. This acts like a bouncer at the door. Before anyone is even allowed to see your website, they have to log in using an approved method—like their Google account, GitHub, or a one-time email code. If they aren’t on the list, Cloudflare turns them away before they ever reach your computer.

Easy integrations for developers (Webhooks)

If you are building apps, you often need external services to send messages to your local computer. For example, when someone pays you on Stripe or pushes code to GitHub, those services need to send a notification (a “webhook”) to your project.

Getting these notifications to reach a computer in your living room is incredibly hard because home networks block outside requests by default.

A tunnel gives you a simple, public link that connects directly to the app running on your computer. You can test payment systems, chat bots, and other tools on your own computer without having to pay for online servers or mess with insecure router settings.

It works even when your internet provider blocks you

Many modern internet providers use a technology called CGNAT (Carrier-Grade NAT). Essentially, they share a single public IP address among hundreds of different homes in your neighborhood. Because of this, traditional port forwarding is physically impossible—you don’t have your own “front door” to unlock.

Similarly, if you are at an office, a university, or a coffee shop, their firewalls will block any incoming connections.

But because a Cloudflare Tunnel is an outbound connection (your computer initiating the call to Cloudflare), CGNAT and strict network firewalls don’t block it. If your computer can browse the web, it can host a tunnel.

The free plan is actually free and powerful

Usually, security tools like this are expensive or have severely limited free plans. Fortunately, Cloudflare’s tunnel feature is completely free for personal use, side projects, and small teams. You can run multiple tunnels, connect different projects, and secure them with login screens without paying a cent.

When is a tunnel not the right tool?

Tunnels are amazing for making a specific app or website reachable. But they aren’t a cure-all:

If you need access to your entire home network: If you want to connect to your home printer, your smart TV, and all your computers at once while away, a VPN (like WireGuard or Tailscale) is a better choice.
If you have strict data privacy needs: Since all traffic goes through Cloudflare’s servers to be inspected for security, companies with strict government compliance rules may not want their data passing through a third party.

Time to lock the doors

Setting up a tunnel usually takes under ten minutes. You install a small helper program, log in to your Cloudflare account, name your website, and point it at the app running on your computer.

Once you do, you can log into your home router and lock every single inbound port. You stop thinking about your home’s public IP address as your front door. Cloudflare becomes your front door, your bouncer, and your security system—giving you peace of mind that your home network is completely secure.

Let me build your own Custom Tunnel

If you want to secure your self-hosted websites, home servers, or private projects but don't want to wrestle with command line tools, DNS setups, or firewall settings, Shrinkray Interactive is here to help. We can design and implement secure outbound tunnel architectures, configure authentication bouncers, and audit your remote access setups to make sure your home or business network stays completely protected.

Ready to lock down your network? Reach out to Greg to get your own custom tunnel configured today!

Shipping small wins

Tue, 18 Mar 2025 16:45:00 GMT

Big launches look heroic in retrospectives. In real time they are often late, brittle, and stressful. I have come to prefer small wins: changes that can be explained in one sentence, reviewed without a map, and rolled back without a ceremony.

That does not mean avoiding ambition. It means cutting work so that each slice is real, observable progress—a bug fixed, a metric improved, a rough edge smoothed.

Open Table of contents

What “small” actually means

What “small” actually means

Small is not trivial. It is bounded. A small win has a clear finish line and leaves the codebase easier to change tomorrow, not harder.

This blog refresh is an example: remove dead content, publish a few posts that reflect how we actually work, ship it, iterate. No manifesto required—just momentum you can feel.

The bug that taught me to read the docs

Wed, 05 Mar 2025 14:30:00 GMT

I once burned most of a day on a bug that felt like a framework betrayal. Symptoms only showed up in production. Local looked perfect. Logs were noisy but unhelpful. I rewrote a hook, then a data layer, then blamed the CDN.

The fix was a single line in the official docs, in a section I had skimmed because the heading looked boring.

The behavior was exactly what the docs described: a default I had assumed was universal was only true in development. Production did the stricter, spec-correct thing. I had been “debugging” my own confirmation bias.

Open Table of contents

What I do differently now

What I do differently now

Before I refactor or rip out a dependency, I open the docs for the failing path and search for the error string or the API name. If the framework authors already named the edge case, I want to see that paragraph first—not after I have painted myself into a corner.

The bug was embarrassing. The habit stuck.

Why static sites still win for sites like this

Wed, 12 Mar 2025 09:15:00 GMT

Not every project needs a server at request time. For a blog and portfolio whose content changes when you publish—not when a user clicks—static generation is still one of the best bargains in web development.

Astro fits that model without pretending you never need interactivity. You can hydrate the pieces that matter and leave the rest as HTML that loads fast everywhere, including on cheap hosting and flaky networks.

Open Table of contents

When static is enough

When static is enough

If your content is mostly Markdown, your personalization needs are light, and you care about Core Web Vitals without a dedicated performance team, a static-first site is a feature—not a limitation.

We still reach for APIs, edge functions, and databases when the product demands it. For DevCharms, the default is simple, fast, and boring in the best sense of the word.

DevCharms

A fresh start for DevCharms

Table of contents

What is coming next

Before I hit publish on a static site

Table of contents

Build and smoke

Links and slugs

Social and feeds

Content passes

Done

How CSS cascade layers let you win with lower specificity

Table of contents

What @layer actually does

The main benefit: order beats specificity across layers

Fewer reasons to use !important

Clear mental model for teams

How this pairs with modern CSS stacks

Practical cautions

@container: responsive layout that follows the component, not the viewport

Table of contents

From viewport to containment

The @container rule

Named containers

How this differs from clamp() and flex

Practical pattern: one card, many homes

Support and progressive enhancement

Why CSS logical properties are the efficient default

Table of contents

One declaration instead of two

The mental model: inline vs block

RTL without duplicate rules

Efficiency in the real sense

Ditch the post-it notes: protect your business secrets with a password vault

Table of contents

The real cost of “just remembering it”

AI has changed the math on password guessing

What a vault like 1Password actually gives you

Secure sharing without exposure

Watchtower: breach detection you would never do manually

Secrets automation for development teams

Travel Mode

Passkey and MFA management

”We’re too small for this”

The habit shift

Hunting Dictionary Bots: Inside a Sophisticated WordPress Membership Attack

The Membership Threat: Impact by the Numbers

Anatomy of the Exploit: Dictionary Word Pairing

Defensive Engineering: Programmatic Remediation

1. Application Layer Domain Restrictions

2. Remediate Existing Users (Purge the Spam Already Inside)

Reasons to set up a Cloudflare Tunnel

Do I need this?

Table of contents

You stop opening doors on your router

If they can’t find your door, they can’t knock on it

Changing home addresses stops being a headache

Free security padlocks without the headaches

Your small project gets enterprise-grade shields

Add a bouncer to your site in two clicks

Easy integrations for developers (Webhooks)

It works even when your internet provider blocks you

The free plan is actually free and powerful

When is a tunnel not the right tool?

Time to lock the doors

Let me build your own Custom Tunnel

Shipping small wins

Table of contents

What “small” actually means

The bug that taught me to read the docs

Table of contents

What I do differently now

Why static sites still win for sites like this

Table of contents

When static is enough

What `@layer` actually does

Fewer reasons to use `!important`

The `@container` rule

How this differs from `clamp()` and flex