Apps on runtimeterror

Gokapi for self-hosted secure file sharing

2026-05-25T17:18:00+00:00

I recently wanted to share a 30MB file with someone, which is still a harder problem than it should be¹. Too big for most email providers, and I didn't want to have to run through the list of cloud file store options to see which we had in common. In the past, I've handled this by using Tailscale Funnel to temporarily expose a Caddy file_server↗ for long enough for the other party to retrieve the file(s). Hardly an elegant solution.

This time, though, I stumbled upon Gokapi↗ which checks a lot of my boxes²:

Open source
Self-hosted with a single container image
End-to-end encryption
Auto-expiring and download-limited links
OIDC authentication for being able to upload files
S3-like object storage support

I particularly like that I can connect Gokapi to external storage (to avoid using up all the storage on my VPS), that links (and corresponding files) will be automatically removed after a defined time period or number of downloads, and that it doesn't allow internet randos to upload files (my compute resources are finite, after all).

It only took me a few minutes to deploy the Gokapi container on an existing Hetzner VPS, link it to Pocket ID for auth, connect the storage backend to Bunny's (beta) S3 storage offering↗, and get on with sharing files.

Deployment

The Gokapi repo has an example docker compose file↗ to make it easy to get started. I just created an /opt/docker/gokapi/ folder on my server to hold the app's configuration and data (the integrated sqlite database) and then brought up the single-container stack:

services:
  gokapi:
    image: f0rc3/gokapi:latest
    container_name: gokapi
    ports:
      - "127.0.0.1:53842:53842"
    volumes:
      - /opt/docker/gokapi/data:/app/data
      - /opt/docker/gokapi/config:/app/config
    restart: always
    environment:
      TZ: UTC

The repo also provides an example .env file↗ in case you want to use environment variables to configure the deployment. This time I skipped right past that and instead used the web interface to perform the configuration. More on that in a moment.

But first, I used Caddy↗ to proxy the container with automatic TLS magic:

gokapi.example.com {
    reverse_proxy http://localhost:53842
    log {
        output file /var/log/caddy/gokapi.log
    }
}

After doing a quick docker compose up -d to start Gokapi and sudo caddy reload -c /etc/caddy/Caddyfile to ask Caddy to please start serving the new thing I can point my browser to https://gokapi.example.com/setup and get on with the configuratin'.

Hurry up!

Until the initial configuration is complete, anyone can access that URL to configure the instance. So you'll probably want to speed through the first-run config or configure Caddy to only allow access from your home IP for now↗.

After the first config, the /setup endpoint will only be available if you explicitly ask for it at container startup, and it will then also be protected by a randomly-generated username and password.

I just stick with the default sqlite database and initial webserver options, but I update two values on the Webserver 2/2 screen:

Public facing URL is set to https://gokapi.example.com/ to reflect the base URL where this thing will be served publicly.
Redirection URL points to my little jwq.lol↗ landing page. Basically there's no reason for an outside user to poke around the main page of my Gokapi instance so anyone that hits the index page will get sent elsewhere instead.

I want to use my Pocket ID setup for logging in to Gokapi's admin page, so I enable OIDC auth:

I then created a new OIDC client in my Pocket ID deployment:

Notable configuration details from that:

Client Launch URL: https://gokapi.example.com
Callback URLs: https://gokapi.example.com/oauth-callback
PKCE: disabled

Then I could use the Client ID and Client Secret for configuring the auth back in Gokapi:

The key here is that the Admin email address must match the email for your user in Pocket ID since that's how you'll be granted access.

Then I moved on to the storage setup. I wanted to use external S3-compatible object storage so I wouldn't have to worry about blowing up the disk on my VPS. So I selected Cloud Storage from the appropriate dropdown:

I'm using Bunny's new S3-compatible storage offering but the setup should be pretty similar for any provider:

CORS

Clicking the Test configuration button yielded a warning:

Test OK. WARNING: CORS settings do not allow encrypted downloads.

I know that Bunny's S3 support is still in early stages and doesn't yet support custom CORS rules and I suspect this warning may be related to that. Encrypted downloads work fine for me, but if you get a similar warning and they don't work, try enabling proxy downloads at the bottom of the previous storage configuration page.

And I want to use full end-to-end encryption; that makes the client work a little harder since it handles the encryption/decryption when files are uploaded/downloaded, but I like that the (possibly-sensitive) files will be completely encrypted at every step along the way.

Firefox issues

There's a pinned issue↗ on the Gokapi repo about Firefox (and derivatives) having trouble downloading files which were uploaded with end-to-end encryption. I haven't run into issues yet, probably since I've so far just been sharing files with sizes in the tens of megabytes. But if you intend to share much larger files you may want to use one of the lower encryption levels until that issue gets fixed.

All that's left is to click the big friendly Submit button to save my settings and get on with sharing files!

Usage

Now that setup is complete, if I just point my web browser to https://gokapi.example.com... I get immediately redirected to my profile page↗. Oh yeah, I did set up that redirect. Well it's cool that it works!

To be able to do stuff in Gokapi, I can instead head to https://gokapi.example.com/login, and this time I get redirected to the Pocket ID auth challenge:

Once I'm in.³, I immediately get hit with a screen telling me about the randomly-generated password to support end-to-end encryption.

This gets generated in my browser (not on the server) and and will be used for encrypting files uploaded the server. The server never knows about this password and thus wouldn't be able to access the encrypted even if it wanted to.

Save this somewhere safe!

The prompt isn't kidding: this random password won't be displayed again. It never gets uploaded to the server and exists solely in your local browser session. You'll need to re-enter the same password any time you log into Gokapi from a new machine (or erase your browser's local storage).

If you lose it, you can rerun the Gokapi setup to generate a new one - but you won't be able to access any of the files which were already uploaded.

Anyhoo, once I've confirmed receipt of the encryption password I can get on in to the main Gokapi interface:

I've got options there for limiting how many times a file can be downloaded, automatically removing it after a set number of days, and optionally setting a password for the file. These options will be applied to the next uploaded file.

I went ahead and left those options on their default settings, and uploaded a 1GB file to test things out.

Now that the file has been uploaded, I can click the little "copy URL" button at the right to grab the URL I can send to my friend. I could also click the little pencil icon to change the download limit, expiry, or password options for the file.

I'd like to see what the experience looks like on the other side of things, so I'm gonna go ahead and paste the download link into another browser and download the file:

After downloading the file once (the limit configured for that file) it gets automatically removed from the server and subsequent visits to the URL are met with a 404.

Reconfiguration

Once the initial setup has been completed, the only way to revisit and change settings is to restart the container and pass the --reconfigure flag. I usually do this by stopping the compose stack and then firing off a standalone container:

$ docker run --rm -p 127.0.0.1:53842:53842 \
        -v /opt/docker/gokapi/data:/app/data -v /opt/docker/gokapi/config:/app/config \
        f0rc3/gokapi:latest /app/run.sh --reconfigure

██████   ██████   ██   ██  █████  ██████  ██
██       ██    ██ ██  ██  ██   ██ ██   ██ ██
██   ███ ██    ██ █████   ███████ ██████  ██
██    ██ ██    ██ ██  ██  ██   ██ ██      ██
 ██████   ██████  ██   ██ ██   ██ ██      ██

Gokapi v2.2.4 starting

###################################################################
Use the following credentials for modifying the configuration:
Username: q12RsR
Password: 9yyrmvLPNN
###################################################################

Please open http://127.0.0.1:53842/setup to setup Gokapi.

I can then log in to https://gokapi.example/com/setup using the provided credentials and make my changes. Once I'm done, I exit the running container and restart the compose stack to pick up the changes.

Conclusion

I'm pretty pleased with this setup so far, and it seems to work rather well for my needs. I really like that the files automatically get removed after downloading so I don't have to worry about cluttering up storage somewhere, and being able to use external object storage means I don't have to provision a ton of storage on the server itself.

See XKCD 949↗. ↩︎
If you know what I mean... ↩︎
Said in my very best hacker voice. ↩︎

Pocket ID: Easy Passkey Authentication

2026-02-24T21:11:36-06:00

Waaay back in June, I posted about how I was using tsidp for effortless SSO in my tailnet. I closed that post with a promise that I would "soon" share details about my other OIDC setup. Well buckle up -- it's time for me to make good on that promise.

tsidp↗ is really great for automatically logging into stuff just by virtue of being connected to your tailnet. But what about stuff that you might want to access from other networks¹? Or maybe you want/need more control over the login experience, or to be able to allow certain other people to access your stuff. tsidp doesn't really work as well for those sorts of use cases².

Enter Pocket ID↗:

A simple and easy-to-use OIDC provider that allows users to authenticate with their passkeys to your services.

Pocket ID is very simple to set up and use, and I think it's particularly cool that it only supports passkey authentication. You set up a single passkey for Pocket ID and that will grant you easy access to any app for which you can configure OpenID Connect authentication. It's worked really well for providing me with out-of-tailnet access to a ton of stuff that I selfhost, including Forgejo, Linkding, OpenGist, and Coder³.

This post will go over how I deployed and configured Pocket ID as well as how to set it up as an authentication source for a few of those services.

Deployment

I wanted my Pocket ID deployment to be accessible from anywhere so I deployed it as a Docker Compose stack on a Hetzner VPS. My server runs Ubuntu 24.04 but any Linux flavor should work as long as it's got Docker installed↗. I front basically all my Docker deployments with a Caddy reverse proxy; I'm not going to detail that installation process↗ here either.

Pocket ID has a really nice installation guide↗ to help get things started, in case you don't want to just take my word for it.

DNS

This project begins, as many often do, with creating a DNS record for the thing I'm about to deploy. Naming things is hard, so I like to get it out of the way up front.

So I used DNSControl to create an A record for id.example.com pointed to the public IP of my VPS.

Docker Compose

Then I needed to create the compose file to define the deployment. This is just a lightly-adjusted version of the default↗.

services:
  pocket-id:
    image: ghcr.io/pocket-id/pocket-id:v2
    restart: unless-stopped
    ports:
      - 1411:1411
    volumes:
      - /opt/docker/pocket-id/data:/app/data
    environment:
      APP_URL: "${APP_URL}"
      ENCRYPTION_KEY: "${ENCRYPTION_KEY}"
      TRUST_PROXY: "true"
      MAXMIND_LICENSE_KEY: "${MAXMIND_LICENSE_KEY}"
      PUID: 1000
      PGID: 1000
    # Optional healthcheck
    healthcheck:
      test: "curl -f http://localhost:1411/healthz"
      interval: 1m30s
      timeout: 5s
      retries: 2
      start_period: 10s

Some key details:

Pocket ID will be served locally on port 1411.
Its data (including the default sqlite database) will persist in /opt/docker/pocket-id/data.
It will run with UID/GID 1000. Make sure to set that to whatever user actually owns the data directory so it can write to it and stuff.

And some environment variables to note:

Variable	Value/Description
`APP_URL`	`https://id.example.com`, the public address where this thing will live
`ENCRYPTION_KEY`	will be used to encrypt data, including private keys; generate with `openssl rand -base64 32`
`TRUST_PROXY`	`true`, since this will be served behind a reverse proxy which we should trust
`MAXMIND_LICENSE_KEY`	used for geolocating login attempts for audit purposes, get a free key here↗

Caddy reverse proxy

Caddy makes things almost too easy. This is all that needs to go in to /etc/caddy/Caddyfile to securely serve our little Pocket ID service with automatic TLS magic:

id.example.com {
  reverse_proxy http://localhost:1411
}

This will direct requests for https://id.example.com over to the Pocket ID container that is listening on port 1411.

Initial start

With the pieces in place, it's time to bring them up.

# start the container stack
$ sudo docker compose up -d
# reload the caddyfile
$ sudo caddy reload -c /etc/caddy/Caddyfile

Now I can just point my browser to https://id.example.com and see the lovely login page:

Settling in

Well Pocket ID is up and running, but it's not doing me a whole lot of good at this point. I can't even log in!

Let's get that sorted.

Since this is a brand new deployment, there aren't any accounts yet. I'll need to create one so that I can get in. So I'll repoint my browser to https://id.example.com/setup to perform that initial setup.

After filling in my details, and clicking Sign Up, I get prompted to set up my first passkey:

I click Add Passkey and go through the steps to add a new passkey in my password manager.

And then I'm in!

See that banner recommending that I add another passkey so I don't lose access? That sounds like a pretty good idea. Passkeys are really cool, but they can be a bit finicky at times. It's important to ensure I have multiple ways to log in if needed.

So I scroll down a bit to the Passkeys section and click the Add Passkey button above my existing passkey.

This time I dismiss my password manager's passkey handler and use my Yubikey instead. Now I'll be able to log in to Pocket ID using either my password manager or my physical token.

No fallbacks

Most sites which implement support for passkey authentication allow you to fall back to some less secure method if your passkey isn't available, like an SMS or email verification code. That kind of defeats (or rather bypasses entirely) the extra security provided by passkeys.

Pocket ID doesn't give you any other options. If you can't use one of your passkeys to get in, you can't get in. Period.

(Okay, technically the Pocket ID administrator can optionally generate and send email backup codes if a non-administrator account can't otherwise log in. And there's an option to allow users to request their own backup codes but please don't enable that as (again) it really decreases security.)

Enroll multiple passkeys.

Application configuration

Pocket ID offers a number of knobs ready to be tweaked under Administration -> Application configuration. You can change the color scheme and application branding, control whether users should be able to edit their own account information, restrict user sign-ups, and enable syncing account details from an LDAP server.

One thing that I thought was pretty important to set up is the email integration.

I'm using forwardemail.net↗ as my mail server which makes it really easy to create/manage email accounts across all my domains, but the setup should largely be the same with any other email provider that supports external SMTP connections.

Beyond just configuring the account that will be used for sending Pocket ID-related email, I also enabled these options:

Require Email Address so that each account must have an email associated with it (that's often required by the downstream OIDC client anyway)
Email Login Notification so that the user will get an email notification confirming their sign-in activity
Email Verification to have Pocket ID send an email to new users to verify their email address
Email Login Code from Admin so that the admin can trigger sending a login code to a user if they lose access to their account

I did not enable the Email Login Code Requested by User because I don't want to expose the option to request a login code in case an email account has been compromised.

Adding clients

So now I can log in to my Pocket ID instance with my passkey, and I can even get an email notification to let me know about it. That's cool, but not particularly useful one its own.

Let's add some OIDC client configurations so that I can log into other stuff with my passkey.

Regardless of what application I'm trying to connect, the setup in Pocket ID always starts the same: go to Administration -> OIDC Clients and click Add OIDC Client.

Name is the name to set for the app in Pocket ID.
Client Launch URL can be set to the main URL of the connected app.
Callback URLs tell Pocket ID what URLs to expect an authentication request to come from. The client documentation will probably tell you what to put here.
The Public Client option is useful if you can't trust the client to hold a secret on its own (such as a web or mobile app deployed on equipment you don't control). I've not needed to enable that for any of my stuff (yet, at least).
PKCE adds a bit more security and protection to the connection, but may not be supported by all clients. I generally enable it for all new apps and disable it if the client doesn't work.

I'll cover what settings I used for some clients in just a moment; I just wanted to show this screen once up front rather than needing to repeat it each time.

Once a client has been created, there's another thing that will need to be handled before it can actually be used. Further down the page, there will be a section labeled Allowed User Groups.

By default, no users are granted access to a newly configured application. You can create groups of users and control which groups have access to which applications (really handy if/when you start extending access to people outside your home), but for now let's keep it simple and just click the Unrestrict button so that anyone with access to our Pocket ID instance (which, realistically, is just me) can access the app. Remember, this will need to be repeated for each new app before you can log in.

Well Known

Some OIDC clients are really smart and can figure out how to talk a provider just based on the base URL (https://id.example.com), while others might need to be pointed to the well-known endpoint https://id.example.com/.well-known/openid-configuration.

Still others may give you a bunch of fields to fill out; you can generally find the answers you need for that by reviewing the JSON document returned by the /.well-known/openid-configuration endpoint. Give it a look if you get stuck.

Pocket ID has a bunch of detailed guides for configuring a number of OIDC clients↗, and basically every application which supports authenticating against an OIDC provider will include some amount of documentation for how to configure it as well. The point is that this is a standard auth method and there should be documentation to help figure out how to configure it for your use case.

Here are a few of the client apps I've configured to auth through my Pocket ID deployment.

Forgejo

Pocket ID docs↗

I still have the client creation page open in Pocket ID, but I haven't done anything with it yet. I open a new browser tab, log into my Forgejo instance, and navigate to Site administration -> Identity & access -> Authentication sources and click Add authentication source.

I click the Authentication type dropdown and set it to OAuth2. I set the name to Pocket, and then set the OAuth2 Provider option to OpenID Connect.

I won't be able to fill in the Client ID or secret until after I finish creating the client in Pocket ID, and I'll need some more info before I can do that.

Scrolling down near the bottom of the Forgejo page, there's a helpful Tips section which includes the following pointers:

OAuth2 authentication:

When registering a new OAuth2 authentication, the callback/redirect URL should be: https://git.example.com/user/oauth2/Pocket/callback

OpenID Connect

Use the OpenID Connect Discovery URL (/.well-known/openid-configuration) to specify the endpoints

So I can now complete the setup on the Pocket ID side of things:

Field	Value
Name	`Forgejo`
Client Launch URL	`https://git.example.com` (the address of my Forgejo instance)
Callback URL(s)	`https://git.example.com/user/oauth2/Pocket/callback`
PKCE	enabled

After clicking Save I am presented with the new client ID and client secret, which I can paste back into Forgejo.

And in Forgejo I set the OpenID Connect Auto Discovery URL to https://id.example.com/.well-known/openid-configuration.

I also enable Skip local 2FA, and set the Additional scopes to openid email profile so that Forgejo will be able to access user email address and profile information.

With everything filled out I can click the Add authentication source button to save and apply the setup.

I can then log out of Forgejo and try to log back in using the new Sign in with Pocket option.

Assuming that my username and email address match the local account I have in Forgejo, I get prompted to link that existing account by logging into it with my existing password.

Next time, my Pocket ID passkey will let me in right away.

OpenGist

Based on those docs, I'll use http://opengist.example.com/oauth/openid-connect/callback as the callback URL when I create the app config in Pocket ID.

Unlike Forgejo, OpenGist's OIDC configuration is done by setting environment variables in the compose file. Here's an example of what that might look like:

services:
  opengist:
    image: ghcr.io/thomiceli/opengist:1
    ports:
      - 6157:6157
    volumes:
    - ./data:/opengist
    environment:
      OG_OIDC_PROVIDER_NAME: Pocket-ID
      OG_OIDC_CLIENT_KEY: ${OG_OIDC_CLIENT_KEY:-}
      OG_OIDC_SECRET: ${OG_OIDC_SECRET:-}
      OG_OIDC_DISCOVERY_URL: "https://id.example.com/.well-known/openid-configuration"

Linkding

Same pattern: I look at the docs, see that the callback URL should be https://linkding.example.com/oidc/callback/, and create the new app in Pocket ID.

Linkding is also configured via environment variables:

services:
  linkding:
    image: sissbruecker/linkding:latest
    ports:
      - 9090:9090
    volumes:
    - ./data:/etc/linkding/data
    environment:
      LD_ENABLE_OIDC: "True"
      LD_HOST_PORT: 9090
      LD_SUPERUSER_NAME: ${LD_SUPERUSER_NAME:-admin}
      LD_SUPERUSER_PASSWORD: ${LD_SUPERUSER_PASSWORD:-}
      OIDC_RP_CLIENT_ID: ${OIDC_CLIENT_ID}
      OIDC_RP_CLIENT_SECRET: ${OIDC_CLIENT_SECRET}
      OIDC_OP_AUTHORIZATION_ENDPOINT: https://id.example.com/authorize
      OIDC_OP_TOKEN_ENDPOINT: https://id.example.com/api/oidc/token
      OIDC_OP_USER_ENDPOINT: https://id.example.com/api/oidc/userinfo
      OIDC_OP_JWKS_ENDPOINT: https://id.example.com/.well-known/jwks.json
      OIDC_USERNAME_CLAIM: preferred_username

Coder

Coder docs↗

The Coders docs tell me to set the callback URL to https://coder.example.com/api/v2/users/oidc/callback, so I do what when creating the application in Pocket ID.

Once again, I'll update the OIDC configuration in the Coder compose file. Coder is apparently smart enough to figure out all the endpoints with just Pocket ID's base URL.

services:
  coder:
    image: ghcr.io/coder/coder:latest
    ports:
      - "7080:7080"
    environment:
      CODER_PG_CONNECTION_URL: "postgresql://${POSTGRES_USER:-username}:${POSTGRES_PASSWORD:-password}@database/${POSTGRES_DB:-coder}?sslmode=disable"
      CODER_HTTP_ADDRESS: "0.0.0.0:7080"
      CODER_ACCESS_URL: "${CODER_ACCESS_URL}"
      CODER_WILDCARD_ACCESS_URL: "${CODER_WILDCARD_ACCESS_URL}"
      CODER_EXTERNAL_AUTH_0_ID: "${CODER_EXTERNAL_AUTH_0_ID}"
      CODER_EXTERNAL_AUTH_0_CLIENT_ID: "${CODER_EXTERNAL_AUTH_0_CLIENT_ID}"
      CODER_EXTERNAL_AUTH_0_CLIENT_SECRET: "${CODER_EXTERNAL_AUTH_0_CLIENT_SECRET}"
      CODER_EXTERNAL_AUTH_0_AUTH_URL: "${CODER_EXTERNAL_AUTH_0_AUTH_URL}"
      CODER_EXTERNAL_AUTH_0_TOKEN_URL: "${CODER_EXTERNAL_AUTH_0_TOKEN_URL}"
      CODER_EXTERNAL_AUTH_0_VALIDATE_URL: "${CODER_EXTERNAL_AUTH_0_VALIDATE_URL}"
      CODER_EXTERNAL_AUTH_0_REGEX: "${CODER_EXTERNAL_AUTH_0_REGEX}"
      CODER_OAUTH2_GITHUB_DEFAULT_PROVIDER_ENABLE: false
      CODER_OIDC_ISSUER_URL: "https://id.example.com"
      CODER_OIDC_EMAIL_DOMAIN: "example.com"
      CODER_OIDC_CLIENT_ID: "${CODER_OIDC_CLIENT_ID}"
      CODER_OIDC_CLIENT_SECRET: "${CODER_OIDC_CLIENT_SECRET}"
      CODER_DISABLE_PASSWORD_AUTH: true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      # Run "docker volume rm coder_coder_home" to reset the dev tunnel url (https://abc.xyz.try.coder.app).
      # This volume is not required in a production environment - you may safely remove it.
      # Coder can recreate all the files it needs on restart.
      - coder_home:/home/coder
    group_add:
      - 999
    depends_on:
      database:
        condition: service_healthy
  database:
    image: "postgres:17"
    environment:
      POSTGRES_USER: ${POSTGRES_USER:-username} # The PostgreSQL user (useful to connect to the database)
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-password} # The PostgreSQL password (useful to connect to the database)
      POSTGRES_DB: ${POSTGRES_DB:-coder} # The PostgreSQL default database (automatically created at first launch)
    volumes:
      - coder_data:/var/lib/postgresql/data # Use "docker volume rm coder_coder_data" to reset Coder
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "pg_isready -U ${POSTGRES_USER:-username} -d ${POSTGRES_DB:-coder}",
        ]
      interval: 5s
      timeout: 5s
      retries: 5
volumes:
  coder_data:
  coder_home:

Outro

This login flow isn't quite as effortless as what I get with my purely-internal systems via tsidp⁴, but it's still pretty smooth. It's nice to be able to use modern passkey-based authentication for my self-hosted apps, and I appreciate not having to rely on some Big Tech passkey implementation to make it work.

And I really like enforcing passwordless logins for the apps I expose to the internet.

Like the internet. ↩︎
Or at least not on a single-person tailnet. ↩︎
I talked about Coder a bit in my January update. I actually sat down today to write more details about how I set up and use Coder but I realized I hadn't written about Pocket ID yet and that seems like an important prereq for my setup. So I'll write more about Coder #soon (and maybe it won't take 8 months this time). ↩︎
It's hard to beat the login experience of being automatically waved through the gate just by being connected to Tailscale. ↩︎

January 2026 Check-in

2026-01-31T00:00:00+00:00

I've sat down about a dozen times over the past month to write a little something, and each time I've gotten distracted by doing other stuff instead. So here's a big(ger) post to stand in for all the little posts I failed to make, just touching over a few highlights of the month.

Cellular switch-up

I switched my cell service from Mint Mobile to US Mobile↗. Mint had been largely fine but US Mobile tempted me with more coverage (they operate across the big three national carriers rather than just one of them), more features (like the ability to switch between the backing carriers depending on your needs), and way more data for less than I'd been paying Mint.

Leaving Mint sucked. Not because it was sad or anything, but because they deliberately made it hard to leave. I had to call their support line to get my account number and transfer PIN so I could port my number to a new provider, and that (of course) meant repeated badgering about why I was leaving, begging me to stay in the form of offers for discounted service, and otherwise just dragging things out unnecessarily so that I'd give up and stay. At the end of the call, the representative even tried to transfer me to their "upstream carrier partner" to see if they could get me a better deal. It pissed me off enough that I couldn't do the whole thing online (if I can sign up for your service entirely online, I should also be able to cancel the service entirely online) but it was absolutely insulting to drag a five minute conversation into a full 30-minute phone call. So while I didn't have any problems with Mint while I was a customer, the frustrating process for becoming a not-customer ensures I won't be a customer of theirs again.

US Mobile has been pretty delightful though. I've got great coverage, a great set of features, gobs of mobile data, and I'm paying significantly less¹ than I was with Mint.

Crucial Tracks integration

For the past two years, I'd been using MusicThread↗ for tracking/sharing the music I was listening to. I had even hacked together some javascript to get my latest shared track to show up on my /now page↗ (and also on my blog).

Well for this year I've switched to using Crucial Tracks↗ for that purpose. Crucial Track's pitch is to share a track a day, and it suggest interesting prompts² to get you to think a bit more about your music. Responses can be (optionally) shared with the broader Crucial Tracks community, and it can be really cool to read about the connections that other members have with certain tracks. I've not done a great job of answering the prompts, but I try to at least include a brief blurb about why I'm feeling a particular song on a given day.

Unlike MusicThread, Crucial Tracks doesn't have a public API (or at least not one that I could find), but it does offer a JSON feed of each profile's page. So I put together a little Forgejo Actions workflow↗ to periodically scrape my feed, parse out the interesting info about the latest track, and post that to my omg.lol pastebin.

      - name: Fetch Crucial Track feed
        run: |
          curl -sL "https://app.crucialtracks.org/profile/${{ secrets.CT_USER }}/feed.json" \
          | jq '.items[0] | { url, artist: ._song_details.artist, song: ._song_details.song, artwork_url: ._song_details.artwork_url, content: ._song_details.content }' \
          > crucial-track.json
      - name: POST to paste.lol
        run: |
          request_body='{"title": "crucial-track.json", "content": '"$(jq -Rsa . crucial-track.json)"'}'
          curl --location --request POST --header "Authorization: Bearer ${{ secrets.OMG_TOKEN }}" \
            "https://api.omg.lol/address/${{ secrets.OMG_ADDR }}/pastebin/" \
            --data "$request_body"

I've then got a little JavaScript bit↗ that fetches the info from my pastebin to embed on a static page:

 // gets latest Crucial Track from pastebin
const crucialTrackScript = document.currentScript
const urlParams = new URLSearchParams(crucialTrackScript.src.split('.js')[1])
const params = Object.fromEntries(urlParams.entries())

const crucialFeed = `https://paste.jwq.lol/crucial-track.json/raw`
fetch(crucialFeed)
.then((response) => response.json())
.then((feed) => {
  let crucialTrack = feed
  console.log(crucialTrack)
  crucialTrackContainer = document.createElement('div')
  crucialTrackContainer.className = 'crucial-track'

  const plain = params.plain === 'true'
  let innerHTML = ''
  if (plain) {
    innerHTML = `<a href="${crucialTrack.url}">${crucialTrack.song}</a> by ${crucialTrack.artist}`
  } else {
    innerHTML = `<a href="${crucialTrack.url}"><img src="${crucialTrack.artwork_url}" alt="Album art for ${crucialTrack.song} by ${crucialTrack.artist}"></a><br><a href="${crucialTrack.url}"><strong>${crucialTrack.song}</strong></a><br>${crucialTrack.artist}`
  }

  crucialTrackContainer.innerHTML = innerHTML
  crucialTrackScript.parentNode.insertBefore(crucialTrackContainer, crucialTrackScript)
  })

It's not the most elegant approach, but it works. So that's something.

Turning 40

I turned 40 this month. That's wild. I vividly remember my dad's 40th birthday party, and it feels mega weird to be the same age now that he was then. I still feel like I'm making shit up as I go, and he seemed like he had everything figured out and under control. An interesting thing about being an adult is realizing that basically everyone else is also still in the "fake it til you make it" stage of life.

Anyhoo, it was shortly after my dad's 40th that he bought his first Porsche (an absolutely gorgeous 1995 911 - the last of the air-cooled generation). So I guess it's about time to start shopping for my own mid-life crisis car³.

Lord of the Rings

My partner and I spent my birthday weekend at the movie theater watching the extended editions of the Lord of the Rings trilogy. It was really great to see those films on the big screen for the first time in 20+ years⁴.

It also gave me a lot of big feels. We lost our Pippin last year, and I cried a bit during the bit of Two Towers where Merry and Pippin are saying their goodbyes as Pippin sets out for Minas Tirith with Gandalf. Saying goodbye fucking sucks.

Oof.

Anyhoo, the extended version of RotK has got to be at least seven hours on its own.

Coder

I've been playing a lot with a self-hosted deployment of Coder↗ this month. While all their marketing is leaning hard into "AI" agents and workflows, Coder's core is about providing reproducible development environments that can be spun up and down as needed. It's kind of like an on-prem alternative to GitHub Codespaces that can integrate with any git-based software forge.

I put together a few templates↗ which use Terraform and Docker to define the tools and features that will be present in the workspaces created from them. Once deployed, I can connect to the workspaces from a desktop IDE like VS Code, a web-based IDE built in to the workspace itself, SSH, or even an integrated web-based terminal. And then I can use the tooling built into the workspace to compile and run code, manage my infrastructure, or anything else I might do in a terminal or IDE. The workspaces can be set to automatically shut down when not in use, but my work gets saved in a persistent volume that gets automatically loaded the next time I connect.

This setup has been really great for working in a consistent way across multiple devices. It lets me switch from my Framework to my MNT Pocket Reform and pick up exactly where I left off on the other device. It also lets me easily build x64 apps and containers while working from an aarch64 system (like the Pocket).

I was previously struggling a bit to really accomplish development-type work on the Pocket due to the rather underwhelming performance, but Coder lets me offload all the heavy lifting onto a more capable virtual machine. It's pretty nifty, and I'm having a lot of fun tinkering with it (which is a large part of why I've been too busy/distracted to write anything else).

New Chatmail relay

I've been operating a Chatmail↗ relay at chat.vim.wtf↗ for a while now and it's been a great experience so far. I continue to be impressed by the Chatmail implementation and the Delta Chat clients, and I love being able to contribute to decentralized secure communications by hosting a small relay.

So anyway I deployed an additional relay at uninterest.ing↗. This one runs on a tiny (1 vCPU, 768MB RAM) VPS that will cost me less than a dollar a month to operate.

PS if you're already on Delta Chat, reach out and say hi↗! If you're not using Delta Chat yet, go get the app↗, set up a profile using one of my relays (or another one from the public relay list↗, and then say hi↗!

Upcoming blog merger

It's been fun running this here blog on Bear Blog, but I've always struggled a bit with whether a post should go here or over at my more-established runtimeterror.dev↗ site. When I started this side blog thing I told myself that I'd post personal stuff here and tech stuff over there, but I don't always know where to draw that line. So much of my personal life does involve technology so it seems a bit daft to try to separate these parts of me.

So I think I'm going to consolidate my two-pronged blogging strategy back into a single prong over at runtimeterror. I've started migrating older posts from here over there, and I figure I'll do some minor reorganization along the way to help things make sense. Once I'm ready, I'll repoint this domain so that existing links should continue to work. Or at least that's my current plan.

We'll see if I actually follow through.

My spend with Mint was $420 annually for 15GB/month; I'm now spending $270 annually for 30GB/month. ↩︎
Like What artist or band changed your music taste forever? Pick your favorite song of theirs. or Share a song that got you through a difficult time. ↩︎
Just kidding, probably. There still really isn't much on the road that I'd rather drive than my BRZ. ↩︎
The event was celebrating the 25th anniversary of The Fellowship of the Ring, and I guess the 24th of The Two Towers and the 23rd of Return of the King. ↩︎

Tech Refresh 2025

2025-12-25T00:00:00+00:00

I didn't really plan it, but I've recently done a bit of a personal tech refresh. I got some new hardware, upgraded another device, and also switched up several of the software and services that I use.

This post will go over some of the big changes.

I started writing this post on December 6, but then I decided to change my tech stack again↗ and I've been trying to catch up ever since. At this point I'm just trying to wrap up this post before it is out of date again.

Hardware

Framework Chromebook -> Framework 13

I'd been happily using a Framework Laptop Chromebook Edition↗ as my primary computing device since early 2023. It was cool to get all the security and stability attributes of ChromeOS combined with plenty of processing oomph for actually Doing Work in the ChromeOS Linux Development Environment↗. At the time, I was still pretty active in the Google Product Experts community and enjoyed helping other Chromebook users get the most out of their devices. I especially loved helping users explore that Linux environment.

Things have changed in the almost three years since then though; technology has generally turned to shit as corporations raced to shove "AI" into every crevice and orifice, destroying jobs, user experience, intellectual property rights, and the planet in the process. I used to be excited about new tech and new features, but I've become increasingly discouraged¹ as every "new feature" turns out to be "old feature but now with AI a predictive word extruder bolted onto it". Corpo innovation is dead, and it's time to for me to move on.

To that end, I started looking for options to move away from ChromeOS and back to a "real" computer. The Framework hardware is pretty nice, though, and the whole point of it is that it can be repaired and upgraded. Of course, this was around the time that Framework decided that they wanted to welcome (and financially support!) far-right assholes in their big tent↗. It didn't feel right to send them more of my money... but I didn't want to just waste my existing hardware.

I did some looking around on eBay and managed to find the bits I needed to convert my Framework Chromebook into the more traditional Framework Laptop 13: a mainboard with a 12th-gen i7 (i7-1280P) and a US-layout input panel to replace the Chromebook-specific keyboard. Purchasing the parts secondhand meant that I could extend the useful life of my current laptop without directly supporting Framework.

The process of replacing the laptop's mainboard was pretty simple² thanks to the maintenance-friendly design. I think it took me about half an hour, and that includes the time spent finessing the wires for the wifi antenna back into their appropriate channels.

Even now, ~6 weeks on, I'm still struggling a bit with the Chromebook keyboard muscle memory³, but I'm otherwise enjoying the new setup. More on that in a moment.

MNT Pocket Reform

Sharp-eyed readers may have noticed another laptop chilling out in the photo⁴ showing the Framework surgery. That's the tiny-but-thicc MNT Pocket Reform↗, an open-source open-hardware mini-laptop that's designed to be modular, upgradable, and repairable. I opted for the first-generation Pocket Reform (equipped with the NXP i.MX8M Plus processor module) rather than the newer RK3588-equipped version primarily because it was available in-stock in the US↗ without having to worry about our dumb tariff chaos or international shipping delays.

The Pocket Reform has a low-powered ARM64 processor, a small 7-inch display, a delightfully-clicky ultra-compact keyboard (with RGB lighting!), a cool optical trackball, and comes with a remarkably detailed Operator Handbook↗ detailing how to use the thing. The handbook even includes schematics↗ for basically every component in the device, and there are also details on how to interact with some of the components⁵. This is definitely a laptop made by hackers for hackers.

It runs Debian (unstable) with a good bit of customization for supporting the Pocket Reform's hardware, and ships with a choice of graphical desktops↗, either Sway or GNOME. I started with Sway which was pretty cool, but honestly the tiling is a bit wasted on this tiny display; there's just not much room for activities so I eventually decided that just sticking with GNOME (for familiarity and broader ecosystem support) and multitasking via workspaces fit my use case a bit better.

The Pocket Reform been a ton of fun for little bursts of computing while on the go⁶, and it was pretty perfect for use during some breakout sessions at KubeCon. While it doesn't have a ton of computing power on its own, I was able connect back to my homelab (through the magic of Tailscale!) for running heavier workloads.

I may even eventually upgrade to the faster RK3588 chipset↗ but for now the Pocket makes for a pretty great go-anywhere computing sidekick.

Software

ChromeOS -> NixOS

I had already been using Nix (the package manager) and Home Manager↗ to maintain the user configuration within my Chromebook's Linux environment, and I'd gotten pretty comfortable with that approach. So I decided to go all-in and load NixOS on the recently-transitioned Framework. The beauty of managing my dotfiles↗ with Nix is that I was able to get most of my apps and preferences set up on the new system very quickly. I love having that kind of portability!

I spent weeks tinkering with my setup, slowly learning how to configure (and use) Sway more effectively. I added a bunch of plugins and utilities to really customize things, and slowly made it into a system that felt like home.

Of course, NixOS can be rather finicky. After a few weeks of daily-driving (and breaking) NixOS/Sway I started to realize that maybe I wanted an underlying OS with a bit more stability (and less prone to typo-induced breakage). ChromeOS's immutable system and image-based updates had really spoiled me!

NixOS -> Bluefin

A friend had been telling me for years about their experience with Bluefin↗, an OS experience based on Fedora Silverblue↗ (an "atomic" desktop OS where the system is updated as a single unit instead of a bunch of independent packages) and built via Universal Blue↗ (a framework for building custom Silverblue images in a modern, repeatable way).

Bluefin comes with the GNOME desktop environment, a curated set of essential applications and features, an integrated app store for discovering and installing graphical apps, and Homebrew↗ for installing tools you might use on the command line. It's basically maintenance free in its standard configuration↗: the OS (and baked-in packages) gets automatically updated each week (but only after going through rigorous testing to make sure it will be a great upgrade experience) and your installed applications get automatically updated twice a day, completely transparently.

It's kind of the perfect⁷ Linux workstation for normal people. You don't have to even think about what operating system you're using; you could treat it like an open-source Chromebook and just have a reliable, self-updating way to access your favorite (non-Google) web browser.

But while it's easy enough for normal people to use, Bluefin easily adapts to fit more advanced developer-focused use cases. Enabling Developer Mode↗ (by simply typing ujust devmode in the terminal) switches to a different OS image that has Docker, Podman, VSCode, and support for devcontainers↗ baked in. It also includes support for "pet containers" which let you easily install and run packages and tools from other Linux distributions within the same workspace. It's kind of nuts how cool that is.

I'm really impressed by how well this modern approach to a Linux workstation actually works.

Nix Home Manager -> Chezmoi

Of course, once I made the decision to abandon NixOS for Bluefin I needed to find another way to manage my dotfiles⁸⁹. Bluefin recommends Chezmoi↗¹⁰ for this purpose so I decided to check it out.

Whereas the Nix Home Manager approach was to forcibly replace (and subsequently prevent modifications to) the designated config files, Chezmoi takes a more measured approach. When you initially tell Chezmoi to start managing a file, it basically just copies it into a local git repository (version control is neat!) while leaving the original in place. You can then chezmoi edit the managed file, and chezmoi apply to apply the changes. If Chezmoi detects a difference between the source (in Chezmoi's local repo) and the target (the original file, likely under ~/.config/ or similar), it will ask how you'd like to handle the conflict. You can forcibly overwrite the file, abandon the changes, or merge the files to keep things in sync. Being able to merge rather than just blindly overwrite is pretty cool, particularly if an application wants to make changes to its own config file.

Chezmoi is packed with a bunch of other capabilities too, like using scripts to perform actions↗ (including installing and updating Homebrew packages↗), templating config files to make them more portable↗, integrating with a bunch of password managers↗, and encrypting sensitive data directly in your Chezmoi repo↗.

It took me a few days to figure it out but I've now migrated the configs from my antique Nix dotfiles↗ to a shiny new Chezmoi-managed home↗. And thanks to a few well-placed scripts, I can copy my standard configs to any new system with a single command. It's neato.

Chrome/Firefox -> Zen Browser

I had continued using Chrome long past when I should have stopped simply because I was using a Chromebook and didn't really have much choice¹¹. Well, now I do have a choice - and I chose to try out Zen Browser↗. Zen is based on Firefox (which means excellent extension support), loaded with thoughtful features (and free of "AI"), and quite lovely to use. It does a great job of retreating into the background to let you focus on the content being rendered rather than the browser doing the rendering.

I really appreciate the way it handles grouping and pinning tabs, opening external links in floating windows (which can be easily dismissed or maximized after previewing the linked content), and the thoughtful and intentionally unobtrusive design decisions throughout.

Zen is appropriately chill.

Immich -> Ente

I haven't completely ditched Google Photos since it makes it easy to automatically share pictures of our boys¹² with my spouse, but it hasn't been my primary photo management solution for several years. I had been backing up my photos and videos to a self-hosted Immich↗ instance running on a virtual machine on the Proxmox cluster at my house. This was largely fine, but the updates often introduced breaking changes that I had to navigate, and the media took up a lot of storage space (something I don't have a ton of in my homelab).

I switched to Ente↗, deployed on a virtual server I rent from Hetzner. Ente's development process seems to be a bit more deliberate so updates are far less scary. The biggest reason¹³ I made the switch though is that Ente supports storing media in remote S3-compatible object storage. This lets it maintain a much smaller footprint on the server itself while offloading the heavy media files to a cost-effective storage provider like Backblaze B2 or (in my case) Mega S4. And it gets my photo library out of my house, which is nice considering that I've had to repair my Immich deployment multiple times due to storage-related problems.

Ente does all the cool things that you'd expect from a modern photo library tool, like grouping matching faces, searching in natural language, and providing easy album sharing. Ente also encrypts all the media files and metadata, both in transit and at rest, and does all of the ML-related processing solely on your local device.

As a neat side effect, I've also started using Ente Auth↗ for managing and syncing some of my MFA secrets. Ente Auth is essentially built in to the Ente server itself, leveraging the same encryption and storage. And it lets me securely keep track of my MFA secrets on multiple devices without relying on a third-party syncing service or servers outside of my control.

Neovim -> Helix

After years of using (and tinkering with) a rather complicated Neovim↗ setup as my primary text editor, I decided to try out a more modern editor with all the cool features already baked in. That editor is Helix↗, and I quickly fell in love. I don't need to import (and configure) a dozen different plugins in order to get a full-featured terminal-based IDE -- Helix does it all right out of the box. It unburdens itself from Vi's legacy design decisions and implements a modal text editor in a more polished, more intuitive way.

There was a little bit of a learning curve as I had to adjust to the Helix way of doing things and the Helix key mappings¹⁴, but I'm really happy with the move.

Services

Kagi Search -> SearXNG

I had been using Kagi as my primary search engine off and on for about two years. The quality of the search results really impressed me, but I was somewhat less excited about the founder↗. I stuck around longer than I should have just because the search results were that much better than what I was able to get on most other search providers.

But wait. Kagi doesn't do its own crawling or indexing. It just fetches results from other engines (including Google, Bing, and Brave) and mashes them together (along with some magic for weighting the results).

And it turns out that I can do that on my own, without paying a subscription which includes "AI" products I don't want or supporting yet another tech CEO who seems to be a bit of an asshole. So I did.

I deployed a fresh¹⁵ instance of SearXNG↗, a self-hostable metasearch engine which, like Kagi, passes your search query on to other engines on the backend and then presents the aggregated results. As an instance administrator, I get a lot of control over which engines are used for what queries and how their responses will be weighted by default, but any user can also set their own preferences¹⁶ to override most of those defaults.

With a bit of fiddling I'm getting pretty decent results from my personal metasearch engine - maybe not quite as good as what I got from Kagi but still much better than I've gotten from any other single engine.

And while I initially deployed SearXNG solely for my personal use, I eventually decided to submit it to the list of public instances↗ so that users who aren't able to run their own can still benefit from it. You're welcome to check it out at grep.vim.wtf↗, but you'll probably want to jump into the preferences↗ to select the engines you'd like to handle your query; I opted to disable a few big ones by default to help avoid my engine getting blocked or rate limited¹⁷.

Cloaked -> Bitwarden + Forward Email + Fastmail + Privacy

Keeping on the trend of breaking up with big tech (and smaller tech that wants to be big), I also decided to cancel the Cloaked↗ subscription that I'd been using to generate unique identities for all of my online accounts. I liked how easy Cloaked made it to create fully functional email addresses, usernames, passwords, phone numbers, and credit card numbers and tightly associate them with the sites or retailers where they were used. I didn't like how Cloaked was still missing basic password manager features (like tying credentials to a specific subdomain or enabling login MFA options other than email or SMS), how clumsy it was to send and receive email from those identities, or how the virtual credit card feature often just wouldn't load¹⁸. These are issues that I could overlook immediately after Cloaked's public launch, but they became gradually more frustrating as time went on. Add to that the increasingly unresponsive customer support, overall lack of focus on improving the core features, and my growing concerns about being so tightly dependent upon a single service and I decided it was time to part ways.

I opted to switch back to Bitwardden↗ for managing my credentials. I was able to export my data¹⁹ from Cloaked, but it did take some massaging to get the data formatted correctly to import into Bitwarden. A big task was handling the distinction between usernames and email addresses; many of my Cloaked records only had one or the other, while Bitwarden often expected the email address to be the username. It was a rather tedious, largely manual process to get all the identities set up with the appropriate field mappings.

I had been a heavy user of Cloaked's support for using your own custom domains for the generated email addresses so the first step of my migration was to simply repoint the mail records for those domains from Cloaked to Forward Email↗ and enable "catch all" email forwarding to an address I have with Fastmail↗. That would allow me to continue to receive new emails sent to those existing identities (and avoid me needing to change the email addresses I had registered with some 400ish websites).

In addition to handling incoming mail, Forward Email also supports outbound messaging. It even allows you to configure an outbound catch-all address, which lets you send email from any handle on your domain without needing to first create a mailbox or anything. Fastmail also supports sending mail through such wildcard addresses, which means I can very easily reply to messages sent to my email aliases without having to jump through any hoops. That's already a much more convenient setup than I was getting with Cloaked.

Bitwarden has a built-in username generator, and it can also be connected to external services to generate email aliases. So I set that up to talk to the Forward Email API and I can generate functional email aliases right from my password manager, just like I did with Cloaked. I can even change the domain used with the generator on a per-identity basis, allowing me to distribute my aliases across multiple domains (another improvement over Cloaked, which only supported changing domains on an account-wide basis).

I couldn't find another cost-effective solution for generating a lot of functional phone numbers similar to what Cloaked provided me, but I didn't want to give all these random sites my actual phone number either. I compromised by getting a secondary eSIM line through Tello↗ with no data and 100 minutes for $5 per month. I use that number for when I'm required to give one but don't want to use my personal number, and I can periodically dump it for a new number with little impact as needed. Having one throw-away number isn't nearly as useful as generating dozens of unique ones on an as-needed basis but it still provides a little better privacy and control than I would get without such a solution.

And, finally, for protecting my payment information I switched back to Privacy.com↗, another service I relied upon in the pre-Cloaked days. While it was handy to be able to generate and manage virtual cards alongside Cloaked identities, the payment service was perhaps the most unreliable of their offerings. I frequently had transactions decline for no apparent reason, cards would fail to generate when I needed them, and trying to search for existing cards or transactions was a frequently frustrating experience. By contrast, Privacy was rock solid for years before I tried Cloaked and it has continued to be smooth and reliable in the months since I switched back. About the only negative about Privacy is that it doesn't support funding virtual cards with credit cards; you have to use a debit card or checking account connection.

Ditching Cloaked wasn't easy, but I'm glad to have done it and regained a bit more control in the process.

Conclusion

Looking back, I guess I'm just continuing my recent trend of looking for ways to decrease my dependence on giant corporations . I want to avoid putting all my eggs in a single basket wherever I can, and to maintain the ability to switch between different solutions without having to lose anything significant in the process.

I want to be interested in and excited by technology again, and these recent changes have helped me reignite that passion.

I'd like to eventually write up more details on some of these components (especially Chezmoi) on the blog... but it took me a month to write this post so we'll see if I follow through on that.

In the words of Ed Zitron↗, "I will never forgive these people for what they’ve done to the computer." ↩︎
Maybe technology isn't all going to shit. ↩︎
I KEEP ACTIVATING CAPS LOCK (Chromebooks don't believe in caps lock). ↩︎
And mess. ↩︎
For instance, you can change the keyboard backlighting by writing hex color values to /dev/hidraw0 - or use a python script↗ to enable a matrix-style animation that looks seriously crispy in the dark. ↩︎
And I even typed out substantial portions of this very post on the Pocket's compact keyboard. ↩︎
If rather opinionated. ↩︎
The config files and settings and whatnot that I use to tailor my workspace to me, so called because the names of these files (or the directories in which they live) are typically prefixed with a . to mark them as "hidden" on a Linux system. ↩︎
Nix doesn't play nice with an immutable system, where it isn't able to write to the /nix/ directory path. I explored some hacks and workarounds for making it work (such as symlinking /nix to /var/nix/) but ultimately it was a hack that detracted from the elegance of Bluefin. ↩︎
Which I pronounce (very incorrectly) like "sham-wow." ↩︎
Okay, I could (and did) run various other browsers within the Linux environment, but those were hindered by a lack of system integration and a bit of a performance penalty. ↩︎
A rowdy pair of Boston terriers. ↩︎
Also Ente's mascot is a cute duck, and "Ente" is the German word for "duck". So that's another pretty big reason. ↩︎
It is possible to remap the keys to make Helix more closely match (Neo)Vi(m) but that kind of defeats the purpose. ↩︎
Yes, dear astute reader, I did experiment a bit with SearXNG back in 2024, too. ↩︎
Those preferences are only stored locally, in the user's browser. There are no accounts, logins, or other identifiers on the server side. ↩︎
I realized that maybe I goofed in adding mine to the public instances list when all of a sudden all of my configured engines started returning a middle finger instead of the results I sought. The sudden increase in traffic definitely seems to have stepped over the abuse detection thresholds. Switching to less-good engines by default and only enabling the better ones in my user preferences seems to have helped find a better balance. ↩︎
There was also that time when changing the funding source for the virtual cards caused a $1,000 pre-auth for each card and wound up maxing out my credit line until the authorizations finally cleared several days later. ↩︎
Of course, the Cloaked export only included the username, email address, and password for each identity. MFA codes, phone numbers, notes, custom fields, email messages, text messages, call histories, or virtual credit card transaction records. Cloaked provides no way to take that data with you, which is a little insane. I was pretty bitter about having to leave behind two years of email receipts and order confirmations, but ultimately this just reaffirmed my decision to move to a solution where I had a bit more ownership of my data. ↩︎

Turning an Android Tablet Into a TRMNL Mirror

2025-06-29T00:00:00+00:00

I've been really enjoying my TRMNL e-ink display, and have been thinking seriously about getting another one (or two!) to have those glanceable displays in more locations in my house. While I wait for my little referral link to get enough clicks to cover another TRMNL, I did find a way to turn an unused Android tablet into a pretty decent TRMNL impersonator.

A recent article in the TRMNL Help Center↗ described how to mirror a TRMNL display to an iPad, and I quickly realized that I could point any browser to usetrmnl.com/mirror/↗, enter my TRMNL device's API token, and mirror the screen that way - though the tablet stubbornly refused to put the browser into a full-screen mode.

I found a solution for that in the open-source Native Alpha↗ app, which makes it easy to install any website as a progressive web app and offers a number of other handy-for-this-purpose features like keeping the screen from going to sleep.

I'm pretty pleased with how well it works, and getting to breathe new purpose into a discarded device is always a plus.

Forget GitHub, Git Forgejo

2025-04-05T00:00:00+00:00

I've been running my own personal git server for a few years now, starting with Gitea¹ and then moving to Forgejo↗ ("for-jay-oh"). Until recently, though, that was primarily a mirror of the code I was maintaining on GitHub. And then, well, 2025 happened and I had a sudden urge to reduce or remove my reliance on US-based companies and services while taking more ownership over my stuff.

So I scrapped my old and barely-maintained instance in favor of a shiny new one, hosted in Germany with Hetzner↗ at git.vim.wtf↗. It sits behind Anubis↗ to shield it from unscrupulous AI crawlers² that want to suck up my code (and use up my limited resources³). I (of course) have it connected to my tailscale network and use Tailscale SSH for my SSH-based git interactions - which means I don't have to expose the server's SSH interface to the world. My setup also leverages Tailscale's handy OIDC provider, tsidp↗ for quick-and-easy authentication when accessed from my tailnet (while not exposing a standard login form for bots to hammer).

I spent a few weeks living in the new environment, and I have now migrated all of my current projects over to the new spot (and archived the sources on GitHub). It took a little bit of fiddling to get all the GitHub Actions workflows converted to Forgejo Actions⁴ , but that's all sorted now.

A few project highlights:

runtimeterror↗, which powers my other blog↗, including deploying it to Bunny CDN.
lolz↗, which manages my omg.lol↗ profile↗ and /now↗ pages (and fetches near-realtime weather data for the profile page).
notes↗, which publishes selected SilverBullet notes from a private repo to notes.runtimeterror.dev↗.
packer-proxmox-templates↗, which builds fresh VM templates for my homelab each week.
compositions↗, where I track the Docker Compose configs for my container workloads.

I'll still hang on to my GitHub account for collaborating with other open source projects, but all of my personal work will be on git.vim.wtf↗ going forward.

Forgejo forked from Gitea↗ after the former project was taken over by a for-profit company. That seems to have been the right move, as that project is now leaning into AI bullshit↗. ↩︎
Are there scrupulous AI crawlers? It sure doesn't seem like it. ↩︎
In addition to just consuming bandwidth, aggressive crawlers can quickly use up a smaller Forgejo server's disk space↗ as archive downloads get created on access. That burned me a few times on the previous deployment. ↩︎
I'm writing another post on those details for the other blog↗, hopefully I'll finish that up soonish. ↩︎

Github Powered Feed Aggregator With Tinyfeed

2025-01-15T00:00:00+00:00

I recently learned about tinyfeed↗, a command-line RSS/Atom/JSON feed fetcher written in Go. It's able to quickly fetch a list of feeds and display them on a single static HTML page. That's exactly the sort of feed aggregator I want - a simple and clean list of links to recent posts so I can read the ones I want in their original format and styling.

I did some tinkering and set up a GitHub repo↗ with an Actions workflow to run tinyfeed on a schedule and serve the resulting index.html with GitHub Pages.

I'm pretty happy with my new feed aggregator!

A Ghostty in My Machine

2024-12-26T00:00:00+00:00

Remember earlier this week when I excitedly shared about how I had changed changed what terminal emulator I was using?

Right, well, I just swapped to a different terminal emulator, again.

I'm now using Ghostty↗, "a fast, feature-rich, and cross-platform terminal emulator that uses platform-native UI and GPU acceleration" from Mitchell Hashimoto↗. I've followed his sneak-peeks and updates↗ over the last couple of years, and was thrilled to see the first public release went live earlier today.

A few things really drew me to Ghostty:

It's written in Zig↗ which sounds pretty fancy.
It uses platform-native GUI bits so it looks pretty (and fits in with other apps) on MacOS and Linux.
It uses Nix for the build environment which is very up my alley.
It was developed with a Zero Configuration Philosophy↗:

Ghostty is designed to work out of the box with no configuration for most users. Ghostty has sensible defaults, embeds a default font (JetBrains Mono), has built-in nerd fonts, and more. We are constantly challenging ourself as a project to eliminate any necessary configuration to use Ghostty.

I think that's a really cool approach, particularly the bit about embedding nerd fonts so you don't actually have to be a nerd to get stylish icons and indicators in your shell.

I've spent a few hours with Ghostty now and I'm quite happy with it. It's fast, responsive, and looks great. It doesn't need to be configured but it's easy to configure, with a simple key = value syntax.

Right now, the only official Ghostty installer is for MacOS↗, but it was easy to install on my Nix-powered Linux system thanks to the Nix Flake↗. And while there isn't direct Home Manager support for Ghostty (yet), I'm able to manage its (minimal) config with the xdg.configFile directive↗.

A Software Stack Shakeup

2024-12-22T00:00:00+00:00

I've been using Nix↗ and Home Manager↗ to manage (most of) the software I use on my computers for about a year and a half now. Nix's declarative approach to package and configuration management lets me create a single base configuration and then selectively apply the relevant pieces to my different devices, whether it's my daily-driver Chromebook, the Pixelbook I converted to NixOS, a VM running in my homelab or The Cloud, or the WSL environment of my work laptop (where I also overlay work-specific configurations).

I track those configurations in my public 'dotfiles' repo↗, and I've done a lot of tinkering with these Nix-based configs in that time as I've gotten more comfortable with the Nix language and discovered new useful utilities, but that tinkering really ramped up this month:

These updates included a lot of small tweaks and fixes, but there were some larger transitions included along the way.

Ditching VSCode for Neovim

VSCode has been my go-to text/code editor for years, and it's served me well. But I've been frustrated that I couldn't use Nix to manage the configuration and plugins of the VSCode install on my Windows work laptop; trying to manually keep all those settings in sync with my Linux machines has been a bit of a fight.

I started doing more and more of my text editing in Vim since I knew that experience would be consistent. And then I tried out Neovim↗ and realized I could use its extensive plugins to completely replace VSCode. The result is an editor that is lighter and more configurable while still providing all the IDE-esque niceties like syntax highlighting and validation and code completion suggestions with a more keyboard-oriented workflow. And my Nix setup ensures I'll have a familiar development environment on any of my systems.

Ditching Tabby for Kitty

I started using Tabby↗ as my terminal emulator of choice back in April. It's been pretty great, but it hasn't yet been packaged for Nix↗, which can make configuration management a little messy. I had seen a lot of other Nix configs referencing a different terminal app called Kitty↗ so decided to give it a try.

It took a bit of fiddling (and wrapping it with NixGL↗ to get it running, but once I did I was able to completely manage the terminal's configuration with Home Manager (the dream!). Kitty is fast, configurable, and packed with features (many of which I'll never use because tmux).

Catppuccin all the things!

Another recent discovery has been the lovely pastel-based catppuccin↗ color scheme. I fell in love with the soothing colors and quickly set about applying it to Kitty, Neovim, and tmux.

I think the result is pretty nice!

Now to see if I can get back to building things and writing about the things I build rather than just endlessly tinkering with my tools...

Opening Up Opengist

2024-11-27T00:00:00+00:00

A recent toot from Jcrabapple↗ introduced me to Opengist↗, an open-source, self-hosted, git-powered pastebin alternative to GitHub Gist. I like all of those things and I thought the live demo↗ looked neat so I decided to take it for a spin.

I deployed Opengist on a Docker host in my homelab, and I was able to serve it publicly via my slick Caddy + Tailscale reverse proxy setup. This was really easy to set up and I'm quite happy with the result - and how easy it is to embed the resulting gists.

Like these files detailing the Docker Compose and Tailscale Serve configurations I'm using for Opengist:

I should tweak the styling a little bit but I'm (1) lazy, (2) tired, and (3) kind of inept so that will have to wait for a bit.

I don't know for sure if/how I will use this long-term (or how the use case might compare with notes.runtimeterror.dev↗) but for now I think it's pretty nifty.

Apps on runtimeterror

Gokapi for self-hosted secure file sharing

Deployment

Usage

Reconfiguration

Conclusion

Pocket ID: Easy Passkey Authentication

Deployment

DNS

Docker Compose

Caddy reverse proxy

Initial start

Settling in

Initial login

Application configuration

Adding clients

Forgejo

OpenGist

Linkding

Coder

Outro

January 2026 Check-in

Cellular switch-up

Crucial Tracks integration

Turning 40

Lord of the Rings

Coder

New Chatmail relay

Upcoming blog merger

Tech Refresh 2025

Hardware

Framework Chromebook -> Framework 13

MNT Pocket Reform

Software

ChromeOS -> NixOS

NixOS -> Bluefin

Nix Home Manager -> Chezmoi

Chrome/Firefox -> Zen Browser

Immich -> Ente

Neovim -> Helix

Services

Kagi Search -> SearXNG

Cloaked -> Bitwarden + Forward Email + Fastmail + Privacy

Conclusion

Turning an Android Tablet Into a TRMNL Mirror

Forget GitHub, Git Forgejo

Github Powered Feed Aggregator With Tinyfeed

A Ghostty in My Machine

A Software Stack Shakeup

Ditching VSCode for Neovim

Ditching Tabby for Kitty

Catppuccin all the things!

Opening Up Opengist