Blog Title

Custom API Keys in Laravel AI SDK

2026-09-05T01:08:21Z

I've been working with Laravel's AI SDK recently, and I ran into a common problem: how do you handle custom API keys for different users or tenants? The SDK works great out of the box when you have a single API key in your configuration, but what about multi-tenant applications where each tenant (or user) brings their own API key (BYO key)?

This is a typical scenario in SaaS applications where you want to let users connect their own OpenAI (or compatible) accounts to your service. The Laravel AI SDK doesn't have a built-in mechanism for this, but it's surprisingly easy to solve with a small extension.

The Problem

When you look at the Laravel AI SDK, the Laravel Magicᵀᴹ creates drivers using configuration from your config/ai.php file. For OpenAI-compatible drivers, it looks something like this:

// AiManager.php
    public function createOpenaiCompatibleDriver(array $config): OpenAiCompatibleProvider
    {
        return new OpenAiCompatibleProvider(
            $config,
            $this->app->make(Dispatcher::class)
        );
    }

The issue is that this pulls the API key directly from your configuration, which is static and shared across all users/tenants. In a multi-tenant app, you need this key to be dynamic based on the current user or tenant.

The Solution

The fix involves three simple steps:

Create a custom class that extends AiManager::class.
Override the driver creation method to inject your custom API key or a user-selected model.
Extend the AIManager:class binding in your service provider.

Here's exactly how to do it:

Step 1: Create the Custom Manager

First, create a custom AI manager that extends the base one:

// App/Ai/CustomAiManager.php
namespace App\Ai;

use Illuminate\Support\Arr;
use Laravel\AI\Managers\AiManager;

class CustomAiManager extends AiManager
{
    public function createOpenaiCompatibleDriver(array $config): OpenAiCompatibleProvider
    {
        // Get the current tenant's API key however you want.
        Arr::set($config, 'key', Auth::user()->api_key);

        // Maybe the user has also selected a default model they want to use.
        Arr::set($config, 'models.text.default', Auth::user()->default_text_model);

        // Call the parent method with our modified config
        return parent::createOpenaiCompatibleDriver($config);
    }
}

Any of the configuration keys can be changed, depending on what the users need to do.

Step 2: Extend the Binding

Next, in your service provider (usually AppServiceProvider), extend the AIManager binding:

// App/Providers/AppServiceProvider.php
use App\Ai\CustomAiManager;
use Illuminate\Support\Facades\App;
use Laravel\AI\Managers\AiManager;

public function register(): void
{
    $this->app->extend(AiManager::class, function (AiManager $manager, Application $app) {
        return new CustomAiManager($app);
    });
}

How It Works

What's happening here is clean and straightforward:

We extend the base AiManager to create our own version.
We override just the method we need to customize (createOpenaiCompatibleDriver).
In that method, we modify the $config array to use the current user's API key.
We call the parent method to do the actual driver creation with our modified config.
Finally, we tell Laravel's service container to use our custom manager instead of the default one.

The key insight is that you only need to override the specific driver creation method you're using. If you're also using Anthropic or Gemini drivers, you'd override those methods similarly.

Why This Approach Works Well

This solution has several advantages:

Minimal footprint - You're only adding a few lines of code.
Leverages existing SDK - You're not reimplementing anything, just extending.
Maintainable - Clear separation of concerns, easy to understand.
Flexible - Easy to adapt to different authentication systems.
No configuration changes - Works with your existing AI config as a fallback.

This pattern of extending Laravel's managers is powerful and can be applied to many other situations where you need to customize framework behavior based on the current user or tenant context. It's clean, follows Laravel's conventions, and keeps your solution tightly focused on the problem you're solving.

Free AI-Assisted Software Development with OpenCode

2026-08-25T18:23:16Z

Free AI-Assisted Software Development with OpenCode

Using AI for programming doesn't necessarily mean incurring the cost of a new monthly subscription.

If you are a developer who prefers working via the command line, OpenCode offers a great way to experience "agentic coding" using free models from various providers. You can use OpenCode’s free Zen models, add free inference endpoints from NVIDIA, and switch between providers if (when) you hit rate limits.

While this doesn't provide unlimited AI coding, it can be surprisingly powerful and useful—and best of all, it is free to get started, and stays free, unless you really increase your usage.

Installing OpenCode

Start by visiting the OpenCode website.

OpenCode offers several installation methods, including:

curl
npm
bun
brew
paru

Choose the method that suits your operating system and copy the installation command into your terminal.

Once installed, there is no need to set up a bunch of API keys; there's an easier way to get started.

Connecting OpenCode to OpenCode Zen

Open OpenCode Zen and follow the steps outlined in the Get started with Zen section.

You will link your GitHub account to OpenCode. You might see an option to add payment (billing) information, but you do not need to do this for this setup, as we will be using only the free models. After linking your account, open your command-line interface and run the following command:

opencode

OpenCode will connect to opencode.ai and generate an API key for your Zen account.

At this point, you are ready to start using the models provided by OpenCode via Zen.

Understanding Free Models

The free models available via Zen are subject to change, so check the pricing page periodically:

OpenCode Zen Pricing

These are the OpenCode models free as I write this post.

Look specifically for models listed as free. The free plan is subject to a usage limit, which resets at midnight UTC. Your experience with this limit may vary significantly; I have had days when I exhausted the allowance just a few hours after the reset, while on other days, I never reached the limit at all.

This makes the free plan useful, but it is not an option I would rely on as a sole provider of AI services.

Extending Your Zen Usage

There is a simple trick that can make a surprisingly big difference (You won't believe #1!).

When you have been working in a session for a while, enter the following command:

/new

This starts a new OpenCode session.

Why is this command important?

An agentic coding session can accumulate a massive amount of context; Your previous prompts, responses, tool calls, and other conversation history become part of what the model needs to process. As the session lengthens, you effectively burden every subsequent interaction with additional overhead.

Starting a new session, however, provides the model with a clean context (free of previous data).

Naturally, you will lose the conversation history, so avoid doing this in the middle of a task where that history is crucial. Yet, when you reach a natural stopping point, the /new command can make your token consumption much more manageable.

OpenCode will compress the session when the usage gets full, but it controls what falls out of context. For a long-running process, compaction is better than nothing, but don't underestimate a fresh session for every task.

Adding Free NVIDIA Models

This is where the setup process gets interesting.

The NVIDIA Build platform offers access to a wide range of models via NVIDIA-hosted inference APIs.

NVIDIA currently allows developers to use its models for free during the prototyping phase. Instead of charging per token, the free plan relies primarily on request-rate limits.

According to NVIDIA’s current FAQ, most models allow up to 40 requests per minute on the free plan, with no charges based on token count. Your specific limit is displayed in the NVIDIA dashboard. If you later require greater capacity, NVIDIA offers options to use partner endpoints or to self-deploy a NIM model.

The nature of this limitation differs significantly from the one found in Zen's free plan. Instead of having a relatively limited usage quota consumed throughout the day, you are generally constrained by the allowed request rate. For an individual developer routinely engaged in agentic coding, a limit of 40 requests per minute is a very generous ceiling.

Creating an NVIDIA API Key

Go to NVIDIA Build and log in or create an account.

Once you are in the dashboard, generate an API key.

Next, return to OpenCode and enter the following command:

/connect

Locate NVIDIA in the list of providers and enter the API key you just created.

That’s it.

You can now use the NVIDIA models available via the Build platform with OpenCode.

NVIDIA Model Catalog

The available model lineup will change over time, so do not rely on this link as a static list of specific models; instead, consider it...

Securing your DNS with TSIG and Age Keys

2026-08-19T02:45:44Z

Securing Your DNS: TSIG Keys for BIND 9 and Age Keys for Secrets

If you run your own authoritative DNS with BIND 9, you have probably hit the two classic problems: how do you let an automated system (a web control panel, a sync tool, or a script) update your zones securely, and how do you safely move zone data around without trusting the whole internet? And once you have DNS working, the next question is always secrets: how do you encrypt a message so only the right person — or the right machine — can read it?

This post walks through both. First, we create a TSIG key, wire it into BIND 9 so it can update your apex domain and every subdomain, and enable AXFR zone transfers with it. Then we generate an age key pair, publish the public half, and use it to encrypt and decrypt messages from the command line.

Section 1: TSIG Keys — Authenticated DNS Updates and Transfers

DNS updates and zone transfers are sensitive. By default, nsupdate traffic is unauthenticated and the server will happily talk to anyone who asks. TSIG (Transaction SIGnature) solves this by signing every DNS message with a shared secret key, proving to both sides that the message really came from who it says it did.

Step 1: Generate the Key

BIND ships with a dedicated tool for this, tsig-keygen (on older systems you may find dnssec-keygen -a HMAC-SHA256 -b 256 -n HOST instead). Run it from any machine; it just needs a name and produces a key snippet you can paste into your configuration.

$ tsig-keygen zoneforge. > /etc/bind/keys/zoneforge.key
$ cat /etc/bind/keys/zoneforge.key
key "zoneforge." {
    algorithm hmac-sha256;
    secret "Oeq1gvZbDD3hFcdPFsbgowpIpW9n7WqlveEHXeY+B8s=";
};

Any string which is a valid DNS name can be used as a key name.

Since we want a valid DNS name without any surprises, remember to add the dot to the end of your key name, just like a domain name.

Keep that output somewhere safe. The secret is a shared secret — anyone who has it can sign updates and request transfers as you. Don't worry about that key I showed, it's not a live key.

Step 2: Put the Key in the Configuration

On your BIND server, create a key file (or drop the snippet straight into named.conf). A tidy approach is to keep it in its own file and include it:

# /etc/bind/keys/tsig-keys.conf  (or wherever your named.conf lives)
key "zoneforge." {
    algorithm hmac-sha256;
    secret "Oeq1gvZbDD3hFcdPFsbgowpIpW9n7WqlveEHXeY+B8s=";
};

Then include it from named.conf:

include "/etc/bind/keys/tsig-keys.conf";

Step 3: Grant Update Permission for the Apex Domain and All Subdomains

Now the important part: telling BIND what this key is allowed to do. You do that inside your zone definition with update-policy. A common pattern is a "dynamic zone" managed entirely by your automation:

zone "example.com" {
    type master;
    file "/var/lib/bind/db.example.com";
    update-policy {
        grant zoneforge zonesub any;
    };
};

Let's break down that single grant line, because it is easy to get wrong:

grant zoneforge — the name of the key we created.
zonesub — the scope of the grant. zonesub matches the apex zone name and every name beneath it, i.e. example.com, www.example.com, mail.example.com, and so on. If you used zone, the key could only touch records at the apex itself; if you used subdomain, only records strictly below the apex. For "apex + all subdomains", zonesub is exactly right.
any — the record types the key may touch. any lets it add, delete, and update any record type. If you want to be more conservative you can list specific types, e.g. grant zoneforge zonesub TXT A AAAA;.

Traefik and your TSIG Key

A common use is to create a key for your traefik instance and use it to validate DNS challenges:

Suppose we have this key:

key "traefik-acme." {
    algorithm hmac-sha256;
    secret "XPEosedwqiO3SiRUHh/fi52RdP1XkLFT2mFSs8EzrK4=";
};

Include it in your /etc/bind/named.conf.local file, and give permissions to the DNS challenge. In this case, we only want the traefik-acme key to have access to _acme-challenge.example.com. so we explicitly list it in the zone stanza.

include "/etc/bind/keys/traefik-acme.key";
zone "example.com" {
    type master;
    file "/var/lib/bind/db.example.com";
    update-policy {
        grant traefik-acme name _acme-challenge.example.com. TXT;
    };
};

In your traefik configuration, add the following keys (note the ending dots):

DNSUPDATE_TSIG_KEY=traefik-acme.
DNSUPDATE_TSIG_SECRET=XPEosedwqiO3SiRUHh/fi52RdP1XkLFT2mFSs8EzrK4=
DNSUPDATE_TSIG_ALGORITHM=hmac-sha256.

Restart Bind

After editing, reload the bind9 server:

$ rndc reload

Test it with nsupdate using the same key file:

$ nsupdate -k /etc/bind/tsig-keys.conf
> server ns1.example.com
> zone example.com
> update add _challenge.example.com 300 TXT "abc123"
> send

A silent success (no error message) means the update was accepted and signed.

Step 4: Allow AXFR Zone Transfers with the Same Key

Zone transfers (AXFR) let a secondary server — or a sync tool, or a backup system — pull a full copy of a zone. You should never allow open AXFR. Use the same TSIG key to restrict who may transfer, again via update-policy in the zone:

zone "example.com" {
    type master;
    file "/var/lib/bind/db.example.com";
    update-policy {
        grant zoneforge zonesub any;
    };
    also-notify { 192.0.2.10; };      /* your secondary / sync tool */
    allow-transfer { key zoneforge; };
};

allow-transfer { key zoneforge; }; says: only servers that can present this TSIG key may pull a full zone copy. That one line is the difference between "anyone can slurp my zone data" and "only my authenticated peers."

Verify the transfer works from the requesting side with dig and the key:

$ dig @ns1.example.com example.com AXFR -y hmac-sha256:zoneforge:aB3dEf9...long-base64-secret...

If you see the records stream out, the AXFR with TSIG is working.

Putting It Together

The same key now does double duty: authenticated updates for the apex and all subdomains (update-policy grant ... zonesub any), and authenticated zone transfers (allow-transfer { key zoneforge; }). Add allow-update { key zoneforge; }; only if you are on an older BIND version — update-policy is the preferred mechanism on BIND 9.16+.

Section 2: Age Keys — Modern, Simple File Encryption

Now let's talk secrets. age is a modern file-encryption tool: simple, audited, and designed as a friendlier replacement for PGP for the common case of "encrypt this file for this person." It uses modern cryptography (X25519 + ChaCha20-Poly1305) and has a tiny, comprehensible CLI.

Step 1: Install and Generate a Key Pair

Install it — brew install age on macOS, apt install age on Debian/Ubuntu, pacman -S age on Arch, or grab a release binary from the project. Then generate a key pair:

$ age-keygen -o key.txt
Public key: age1qrv95sau5h02a7wueelak7c83qgf6xf4tx08vcnyaqs6ef99ppvq34x062

Two things just happened:

key.txt contains your identity (private key), which can decrypt messages meant for you. It is a secret — protect it like one (chmod 600, keep it in a vault, etc.).
The terminal printed your public key (age1...). This is what people and machines use to encrypt messages to you. It is safe to share anywhere.

Step 2: Publish the Public Key

The public key is meant to be public. Add it to your website, your SSH/Git profile, a keys page in your docs, or a key.pub file in your repo — however you want people to find you. For example, put this in a keys.md or a pubkey endpoint:

My age public key:

age1examplemushroom...long-public-key...

Anyone who sees it can now encrypt a file that only you can read. That is the whole trick of asymmetric encryption: share the public key freely, guard the identity.

Step 3: Encrypt a Message

Encrypt a file for a recipient using their public key:

$ age -e -r age1examplemushroom...long-public-key... \
    -o message.age message.txt

-e means encrypt, -r specifies the recipient's public key, and -o names the output file. The result, message.age, is binary and safe to email, post, or commit — it leaks nothing without the matching identity.

You can also pipe text straight in without touching disk:

$ echo "hello, secure world" | age -e -r age1examplemushroom... > message.age

Just like gpg, you can use the -a/--armor option to armor encode the output.

And you can encrypt to multiple recipients at once — handy when a secret needs to reach several people:

$ age -e \
    -r age1alice... \
    -r age1bob... \
    -o secret.age secret.txt

Step 4: Decrypt a Message

To decrypt, use your identity file (the private half you generated earlier):

$ age -d -i key.txt -o message.txt message.age
$ cat message.txt
hello, secure world

-d means decrypt.
-i key.txt tells age which identity to use. If the file was encrypted to that key, decryption succeeds; otherwise age will error out and produce nothing.

You can also decrypt from stdin without saving the decrypted output to disk:

$ age -d -i key.txt < message.age

A Practical Combined Example

Encrypt a backup, then decrypt it later — or on another machine that holds the identity:

$ tar czf - /var/lib/bind | age -e -r age1examplemushroom... > bind-backup.tgz.age
$ age -d -i key.txt < bind-backup.tgz.age | tar xzf -

Why This Matters Next to TSIG

Notice a theme: in both halves of this post, one secret does the work. Your TSIG key authenticates DNS updates and zone transfers between machines that share it. Your age identity decrypts secrets sent to you by anyone who has your public key. In each case the rule is the same:

Publish the non-secret part (the age public key; the zone names and policy you configure).
Guard the secret part (the TSIG secret; the age identity).
Restrict what the key can do (a zonesub grant instead of a blanket allow-update; an age identity kept off shared filesystems).

DNS controls where things live and who can talk to the servers; age controls what is readable and by whom. Put both together, and you have a solid foundation for automating DNS administration without handing out keys or secrets to everyone who asks.

I use my agekey to encrypt messages in my DNS zones. When I was manually editing a zone, then rndc reload example.com then remembering that I forgot to update the serial number, and reediting, and seeing something else that just wasn't formatted right, and doing it all over again, and wondering if the serial number increment and rndc reload command was working correctly, I had comments in my zone files. An old IP address, a service renewal, an url of a site that that had the SSHFP record generator: ssh-keygen -r jeffharris.us.

Then, when I started using nsupdate, and using dynamic zones, I lost my comments. So now, I use my agekey to encrypt a string to myself, and add it as a TXT record in an _infra zone. Agekey strings are long, so don't try to encrypt a whole novel, but it works, and you don't know what's there.

I wonder if this will ever turn up in a spy novel as a way of passing information across the globe. Using an internet cafe or a VPN to do a dig of some site, copy the data, and you have your secret instructions for world domination.

Why This Post

I built age encryption into ZoneForge, which conveniently lets you use your TSIG key, if configured correctly to allow both nsupdate and AXFR transfers, to administer your bind9 files without that pesky SSH, and totally without webmin. I'm still working on it, so your miles may vary if it's close to the date of this post.

Sign up, enter your TSIG key, and validate your first zone. We'll use your key to place a temporary TXT record on your zone, then pull the record from DNS and remove the record. From then, you can make any changes you need. If you make other changes outside the ZoneForge system, just click the button for an AXFR transfer, and we'll fetch all the records and update the view.

This is designed for those of us still using our own Bind9 DNS servers, and not the registrar's name servers.

Dynamic Zone Files

2026-08-13T20:01:32Z

I run my own dns servers. It all started when I wanted to put my SSHFP records in my DNS. At the time, I had a small child, and a trip to DisneyLand was not an unexpected weekend trip. But I didn't quite trust the hotel internet connections back then, and wanted to make sure that I was actually connecting to my little server. SSHFP records were a way to validate that no one in the hotel was running some MITM attack to try to get anything. If they knew my server, they wouldn't want it, but still.

So over the years, I now have four DNS servers scattered across the States, all with different providers, completely robust; the only global failure would be if my billing doesn't go through.

Adding to my Bind9 servers, I've hooked up Traefik and have fought through sometimes confusing or lacking documentation to configure Traefik/lego to use RFC2136 to issue DNS challenges for wildcard domains. Doing this required all my zone files to become dynamic. That's fine, of course there's nothing wrong with dynamic zones.

Except for my comments. I had my zone files littered with comments: old IP addresses to reference if I had hardcoded an address that I forgot; domain renewal dates; specific VPC machines that housed a domain. And my include files. It was simple to have an include file that held all the common NS records and a CNAME for opengpgkey, for a domain hosted on GitLab Pages, or if it had Google SMTP servers, or Zoho, or other commonalities that would be best for include files.

The loss of comments saddened me, but I figured I could take a JSON string, and encode it with an Age Key and add it as a TXT record on an _infra host. I still have the data available, and no one else knows my secrets. Of course, who needs to know when my annual renewal is due besides me, right?

Wanting an easy way to create these encrypted TXT records, I created ZoneForge. It requires your TSIG key to send updates to your hosted Bind9 server for all record types, and uses your own Age Key to encrypt and decrypt the _infra TXT records. It's still in pre-release/bugfix/finalizing stage, but I've been able to change the DNS settings for Is Dave Canales Gone Yet, and I've added records to a new domain.

You will need to have a zone already added in your named.conf files, and a TSIG key with the proper grants, and I need to finish configuration, but that will be coming shortly.

DateTime Errors

2026-08-09T22:18:23Z

I've learned a few lessons lately, one of them regards when not to make something multi-tenant. I started a project and thought, "Yes, Multi-tenancy sounds like a good idea." I know that multi-tenancy can be a good idea, but it turned out to be too much for this project, so now I'm unwinding multi-tenancy. Just having a tenant landing page isn't enough for a multi-tenancy application.

The other issue I have was invisible until just a few days ago. I ran some tests after 8:00 pm on the US east coast, and tests that had never failed before were suddenly failing. In this project, I want the user to select a date, and the backend converts it to a timestamp corresponding to the start of day in the Organization's timezone. So someone in Los Angeles picks 2026-08-09, and the system converts it to 2026-08-09 00:00:00.0 America/Los_Angeles, then converts that to UTC for the database. In this case, I didn't want the user to pick a date less than today in whatever timezone they're in. My FormRequest contained code similar to

$date = Carbon::parse((int) $this->server('REQUEST_TIME'), $this->organization->timezone)->format('Y-m-d');

This code worked before, but now, after 8:00 pm, it fails. It's tomorrow UTC, so I know that there's something with the dates.

Big Pickle tells me: When you pass an integer Unix timestamp to Carbon::parse (), it treats the timestamp as absolute and ignores the timezone argument (verified: Carbon::parse (time (), 'America/Chicago') stays +00:00). So "earliest start" is computed in UTC, not the org's timezone.

So my form validation files were failing because the earliest start couldn't be less than tomorrow.

The solution is to use

$date = Carbon::createFromTimestamp(
        (int) $this->server('REQUEST_TIME'),
        $this->organization->timezone,
    )->format('Y-m-d');

createFromTimestamp() honors the timezone (2026-08-06 in both NY and Chicago, verified above), so "earliest start" = today in the org's timezone.

The test case isn't really deterministic, and it can be modified to be. This allows creating tests at any time, testing all edges. Instead of relying on the real REQUEST_TIME, it should be pinned via withServerVariables()

$response = $this
    ->withServerVariables(['REQUEST_TIME' => Carbon::parse('2026-08-07 01:00:00', 'UTC')->getTimestamp()])
    ->post(route('model.store'));

If you have a numeric timestamp, Carbon::parse() will ignore a timezone, and it's what you want. If you have a numeric timestamp and a timezone, Carbon::createFromTimeStamp() is your friend.

Getting DESIGN.md Design Systems Working with OpenCode's MCP

2026-07-27T03:05:05Z

I've been running more powerful AI models lately and wanted to use opencode.ai to add some real styling to my blog. The stock template was fine to get started, but I didn't want it looking like every other default setup out there.

That led me to DESIGN.md, a site where people publish design systems as markdown files. Think of it like a design system registry. You browse, you download, you implement. Simple enough.

They have an MCP server, which means you can plug it directly into AI coding tools like OpenCode and query design systems right from your editor. In theory.

The Setup

OpenCode uses an opencode.jsonc config file where you declare your MCP servers. The DESIGN.md docs show you the standard MCP config:

{
  "mcpServers": {
    "designmd": {
      "command": "npx",
      "args": [
        "designmd-mcp"
      ],
      "env": {
        "DESIGNMD_API_KEY": "your-key-here"
      }
    }
  }
}

OpenCode's config format is a little different, it uses "mcp" at the top level and drops the mcpServers wrapper. So you end up with something like this:

{
  "mcp": {
    "designmd": {
      "type": "local",
      "command": ["npx", "designmd-mcp"],
      "enabled": true,
      "env": {
        "DESIGNMD_API_KEY": "dk_your_key_here"
      }
    }
  }
}

Straightforward. I plugged in my API key, fired up OpenCode, and asked it to grab a design system.

The Error

It failed with:

DESIGNMD_API_KEY environment variable is not set.

Wait, what? The key is right there in the config. I triple-checked the spelling, the quotes, the comma placement. All good. I even asked an OpenCode model to check my work.

Here's the thing (according to DeepSeek V4): the MCP tools that DESIGN.md exposes check process.env.DESIGNMD_API_KEY at runtime. When OpenCode starts the MCP server, it passes the env vars from the config stanza just fine, the server itself can see them. But the tool functions that the server exposes to the AI apparently run in a different context where that env var isn't inherited.

At least, that's its best guess after poking at it for a while.

The Fix

What worked was setting the environment variable at the shell level:

export DESIGNMD_API_KEY="dk_your_key_here"

Drop that in your .zshrc or .bashrc, open a new terminal, launch OpenCode, and suddenly everything works. The MCP tools can see the key because it's in the parent process environment that OpenCode inherits.

The Takeaway

None of this is documented anywhere obvious. The DESIGN.md MCP docs show you the MCP config format but don't mention that you might also need the shell env var. And the error message points you back to the MCP config, which is already correct.

If you're using DESIGN.md with OpenCode (or probably any MCP client that doesn't perfectly bridge server env vars to tool execution contexts), save yourself the head-scratching and add the key to your shell profile too. The double config is harmless, the MCP stanza still matters for the server itself, and it saves you from the confusing error loop.

A small doc update or a better error message would go a long way here. Until then, hopefully this saves someone the twenty minutes I spent going in circles.

But on the other hand, I have a better design for this little piece of my digital home.

Becoming numb to pain

2026-07-08T00:00:00Z

There is a post from Joel Clermont about not becoming numb to pain in your project, and I want to expand on it.

When joining a new project, you have the opportunity to do a tissue test of the setup documentation. I heard the term tissue test years ago, and can't find a definitive source anymore. Too many results for biological tests are in the way.

A tissue test refers to a test that you can only do once. Once you've done it, you have probably done some troubleshooting or installations that make future tests different from the first. It's like using a tissue; you can only use it once. Every time you attempt to fix a problem, you're changing the situation. If a dependency has been abandoned, or a major release changes an option, you've now changed the starting point, and your tissue test is invalid.

I ran into that same problem recently when trying to give .NET a whirl. I was installing tools from scratch, and found an issue in the setup documentation. Unfortunately, because the people who could fix the bug already had working systems, they couldn't duplicate my starting point to verify the issue. I guess that's why there's Stack Overflow.

All through high school band, and continuing through my community chorus and barbershop quartet, we become numb to pain. There are certain spots in the numbers where there isn't adequate tuning, or a discrepancy in phrasing. It's always thought of as "you can't fix everything at the same time," so we fix the most glaring issues. As time goes on, the less obtrusive errors continue, becoming habit in the performers, and in everyone else's ears.

We become numb to the fact that the first phrase of the song has suboptimal tuning because the reprise needs more work. It's not just development that becomes numb to pain, it's everything. Even football teams become numb to the pain of their offensive line, saying "we'll work on that in the off-season." And that's why the Raiders were on the draft clock since the 18th week of last year's season.

Another area in which to turn numb is typography. I'm working on another project, and the fonts are all default, just like every other project out there. So I want a slightly different serifed typeface. I pick one, and decide that it looks a little goofy for the project. That's not a problem, I'll change it later. But you become blind to that pain.

Crumb Crusted Protein recipe

2026-05-12T15:49:59Z

Crumb Crusted Protein

You will need

1/2 cup bread crumbs
1/2 tsp House Salt
1 tsp italian seasoning
1/2 tsp grated Parmesan cheese product
2 portions of protein (chicken breast, pork chop, whatever floats your boat)

Instructions

Combine dry ingredients in a gallon-sized zip bag
Pat protein dry
Slather protein in Duke's Mayonnaise
Shake protein in zip bag with dry ingredients to coat.
Bake on a cooking rack over a baking sheet at 350 F until done. Use a thermometer to check doneness.

Optional changes

If you have the cheese in the green container, and you're in a hurry, go ahead and use it. Only you will know. Want to be cheesier? Add more.
Add a slice or two of provolone cheese to the chicken about 5 minutes before cooking is finished, top with your favorite tomato-based pasta sauce and serve on top of a bed of spaghetti.
Substitute Ranch Seasoning for the Italian seasoning and house salt.

House Salt

1/2 tbsp table salt
1/4 tbsp pepper
1/4 tbsp garlic powder.

Combine and store in a sealed container.

Make this in whatever volume you want, just know that the garlic powder may clump with the salt and pepper, so only make what you're going to use in a month.

Using a logged-in User in Tinker

2026-05-08T14:59:31Z

During Laravel testing, we can use the actingAs() method to authenticate a user into the testing environment.

class ExampleTest extends TestCase
{
    #[Test]
    public function authenticated_user_can_see_dashboard(): void
    {
        $this->actingAs(User::factory()->create())
           ->get('/dashboard')
           ->assertOk();
    }
}

I have an event in a model that requires the authenticated User:

class Organization extends Model
{
    #[\Override]
    protected static function booted(): void
    {
        static::created(static function (Organization $organization) {
            OrganizationCreatedEvent::dispatch($organization, Auth::user());
        });
    }
}

During testing, we use the actingAs() method to fill the Auth::user() model, but what happens when we need to create an Organization in the tinker shell?

> $o = Organization::factory()->create()

   TypeError  App\Events\OrganizationCreated::__construct(): Argument #2 ($user) must be of type App\Models\User, null given, called in vendor/laravel/framework/src/Illuminate/Foundation/Events/Dispatchable.php on line 15.

> $this->actingAs($user)

   Error  Using $this when not in object context.

We can't use $this-> because, like the error message says, we're not in an object.

But it's easy enough to add the user:

> $user = User::factory()->create();

[!] Aliasing 'User' to 'App\Models\User' for this Tinker session.
= App\Models\User {#8767
    name: "Mrs. Candace Runolfsdottir",
    email: "wauvot.kiara.borer@example.net",
    email_verified_at: "2026-05-08 14:43:37",
    #password: "\$2y\$12\$ehsEQzkwABxZiH37PT1zpuQsR5ncLR1A78hEYPYMTAL1gxr..9XV6",
    #remember_token: "lnVyiUqw6d",
    #two_factor_secret: null,
    #two_factor_recovery_codes: null,
    two_factor_confirmed_at: null,
    updated_at: "2026-05-08 14:43:37",
    created_at: "2026-05-08 14:43:37",
    id: 4,
  }

>  app('auth')->guard(null)->setUser($user);

= Illuminate\Auth\SessionGuard {#8687
    +name: "web",
  }

> $o = Organization::factory()->create()

[!] Aliasing 'Organization' to 'App\Models\Organization' for this Tinker session.
= App\Models\Organization {#9165
    name: "Reilly Ltd",
    updated_at: "2026-05-08 14:43:52",
    created_at: "2026-05-08 14:43:52",
    id: 2,
  }

Now the only thing I need to do is figure out how to fake or skip a Notification automatically while in the tinker console.

Rule 13

2026-05-07T00:00:00Z

Rule 13 states that when you give a document to someone else to proofread, always leave a simple, intentional error in the document. Don't make it obvious, like misspelling the very last word or the main title, but keep it in there somewhere.

If they don't tell you about the error, they probably didn't read it. Ask someone else to proofread your document.