I’ve built it so that a user simply has to authorize omarchyguild.com to access their GitHub account. From there it can see what they’ve done related to Omarchy, and any work they’ve done on pull requests, themes, or plugins gets automatically pulled into their profile. Pull requests are imported and updated automatically as new work comes in while users manually add plugins and themes.

The stack

• Rails 8, SQLite + Solid Queue/Cache/Cable, Hotwire, Propshaft + import maps, Minitest.
• Auth via email magic link with long-lived sessions.
• Deployed via Hatchbox, Cloudflare in front, MailerSend for transactional emails. Solid Queue runs as its own Hatchbox process (bin/jobs) next to the web server.

The leaderboard

The first of my favorite features is the leaderboard, which shows a ranking of people who have contributed PRs, themes, and plugins. You can break that down into all contributions combined (pull requests, themes, and plugins), or you can see separate views for just pull request rankings, theme rankings, and plugin rankings. That way you can see how the members of the guild rank based on those subcategories.

The globe

Another great feature that I really enjoy is the globe, which is a visualization of the Earth with all the Omarchs on it. Users can choose to drop a dot on the globe where they’re located. They don’t have to, but they can, and then their name and their dot will appear on the globe. This way we can see where everybody in the Guild is and what the world looks like with contributors to Omarchy all over it.

You don’t have to be a contributor

On that note, you don’t actually have to be a contributor to sign up for the site. You can simply be somebody who’s interested. You can show off your setups as well, post images of your desktop, your cool computer, your cool setups, very similar to what we have going on in the Discord. You can post all of that here on the Omarchy Guild too.

Where this fits with Discord

Discord is obviously THE place to chat and converse, and I don’t currently have any features built on omarchyguild.com that allow communication. No like buttons, no chats, no communication. It’s all just presentation. It brings all of these things together into one spot, because I didn’t feel that the Discord group had a place to showcase a person’s work in one single location.

Check it out at omarchyguild.com.

So, I did what anyone using Omarchy these days would do, and I built a plugin.

I call it Omarchy Plain English.

It’s a plugin that reads your system stats and translates what’s going on there into plain English. It doesn’t use any AI. It just has prescribed verbiage for different scenarios. It lives in your top bar and you can click it and see, in plain English, what’s happening in your system. If anything is going wonky, it’ll tell you. If everything is cool, it’ll tell you. That’s simple.

Sure, I could learn btop better, but sometimes I just want a quick answer to “why is my laptop running hot?” The laptop has all the data, and now it can easily tell me why.

Check it out here: https://github.com/joelgaff/omarchy-plain-english

P.S. - my Framework was running hot because the Bluetooth service was stuck on something and using an entire core. Claude helped me debug and fix it. What a time to be alive.

The pass is apparently bound to whichever device you activate it on. Icelandair’s portal has a “Swap Device” option, but it only works if you paid with a credit card and gave them an email at checkout. Points purchases don’t create a lookup record, so the swap silently fails with “no device associated with this email.” Poor error message, but Claude helped me figure it out.

I still wanted to use my laptop. I needed to install Omarchy Quattro, after all.

Claude said that the wifi pass follows the MAC address of the device, and the fix is to make the laptop present the iPhone’s MAC.

Framework 13 running Omarchy 3.8.5, iwd for wifi set up. Here is what Claude cooked up that worked.

On the iPhone:

• Find the Wi-Fi address (not IP address)
• Toggle Wi-Fi off entirely so the AP can age out the association.

On the laptop, save your real MAC first:

cat /sys/class/net/wlan0/address

Then clone the iPhone’s MAC and reconnect:

iwctl station wlan0 disconnect
sudo ip link set wlan0 down
sudo ip link set wlan0 address <iphone-mac>
sudo ip link set wlan0 up
ip link show wlan0 | grep link/ether
iwctl station wlan0 connect "Icelandair Internet Access"

Confirm the grep echoes the iPhone MAC and not your real one. If iwd overwrote it, check /etc/iwd/main.conf for AddressRandomization=network or once and comment it out.

Then re-point DNS at the portal gateway:

sudo resolvectl dns wlan0 172.19.0.1
sudo resolvectl domain wlan0 '~.'

That last part was needed because my resolved.conf had Cloudflare hardcoded in DNS=, which was overriding the network’s own DNS and swallowing the portal redirect. Moving Cloudflare to FallbackDNS= is the real long-term fix for captive portals.

Before landing, restore everything:

sudo ip link set wlan0 down
sudo ip link set wlan0 address <your-real-mac>
sudo ip link set wlan0 up
sudo resolvectl revert wlan0

That revert matters. Skip it and the next network I try to join will look mysteriously broken, because wlan0 is still trying to reach a gateway at 35,000 feet.

The gotchas that cost me the most time

• I typed the phone’s IP where its MAC belonged. ip complained “must be 6 bytes.” Bytes, not octets. IP is 4, MAC is 6.
• I dropped the address keyword a couple times. Without it, ip link set wlan0 F6:4F:... reads the MAC as a device name and returns “garbage.” Always ip link set dev wlan0 address <mac>.
• iwd can silently rewrite your MAC back to the hardware one on connect if AddressRandomization is set. If your first clone succeeds and then the change disappears, that is why.

This kind of stuff is just magical. I wouldn’t feel as confident messing with my Mac, but I feel a closer connection to my Linux machine, and know my way around the CLI much more comfortably (with plenty of help from Claude). I felt like a true hacker, doing something that I wasn’t technically supposed to be able to do. Big win for us nerds.

Now off to explore Quattro.

It’s the kind of thing that only matters to me now when the product is small. If the app takes off, I’ll likely turn these notifications off. But at the moment the emotional payoff of these pings is high.

Why I wanted this

Between publish and check-stats-a-week-later, there’s a long fuzzy void where I have no idea if anything is landing.

A signup is a real signal. Someone read something, tried the product, gave me their email, and made an account. That’s not a stat, that’s a person.

I want the ping the moment it happens. Not tomorrow morning in a digest email. Now.

How it works

Under the hood: a small background job on the Rails side that fires whenever a new user is created, packages up a short summary, and sends it to Telegram over their bot API. Around sixty lines of code, plus tests.

A few details worth naming:

• The job only fires in production. Dev signups, test signups, seeded data. None of them buzz my phone. Local iteration is already noisy enough.
• It only fires after the database commit. If a signup gets rolled back for any reason, no ghost ping.
• If Telegram is having a bad day, the job retries a few times, then quietly gives up and logs it. A failed notification should never block or retry a real user’s signup.

Nothing exotic. Just quiet, defensive plumbing.

The nice surprise

Setting up the Telegram bot was faster than I expected. Two minutes with @BotFather, one HTTP call to test, done. Bot tokens are just strings, chat IDs are just numbers. There’s nothing you need to configure on Telegram’s side beyond creating the bot itself.

Compared to setting up transactional email (deliverability, SPF/DKIM/DMARC, verified domains), Telegram bots are a shockingly easy notification channel for solo-builder use cases. Not for user-facing notifications. I’m not asking Cucamonga users to install Telegram. But for the “ping me, the operator” use case, it’s ideal.

Onwards.

Here is the whole thing, in the order it happened, because I think this is what modern Rails deployment can look like now, and it’s worth writing down.

The setup

The trips app has lived at trips.joelgaff.com for a while. It’s a subdomain on my personal domain. It’s fine, but the app has outgrown it. I rebranded the app to be called Cucamonga, and cucamonga.app is its new home. Time to move it over.

But I’m in London. On vacation. In bed. On my phone.

I only need three tools:

1. Cloudflare: where my DNS lives
2. Hatchbox: where the app runs
3. GitHub Mobile App: where the code lives

That’s essentially the entire deploy pipeline. Rails 8, SQLite, Hotwire, one Hetzner box behind Caddy, auto-deploy on push to master. It’s boring in the best way.

Step 1: DNS

Open Cloudflare. Add two records:

• A cucamonga.app → server IP
• CNAME www.cucamonga.app → cucamonga.app

Grey cloud, not orange. Caddy needs to see real origin traffic to provision certs, so the Cloudflare proxy stays off. Save. DNS propagates in about ten seconds because Cloudflare doesn’t mess around.

Step 2: Hatchbox

Open Hatchbox on my phone. Trips app → Domains → Add Domain → cucamonga.app. Repeat with www.cucamonga.app. Save.

Caddy on the server immediately went and provisioned a Let’s Encrypt cert for the new hostnames. This is normally the part where you’d go get a coffee. I’m lying in bed, so I scroll on X for a few minutes. On modern Rails hosting, it’s a background job you notice by accident when it finishes.

Step 3: The 403

I hit https://cucamonga.app expecting the app.

I got a 403.

DNS was correct. The cert was valid. The app was running. And it was refusing me.

Took me a minute to recall what was happening. Didn’t even need to ask Claude.

Rails 8 is paranoid about host headers by default. ActionDispatch::HostAuthorization checks every request’s Host header against your allowlist in config/environments/production.rb, and if it’s not on the list, you get a 403. This is the correct behavior. DNS rebinding attacks are real. But it also means adding a new domain requires a code change.

Step 4: The one-file patch

Open the GitHub app on my phone. Navigate to config/environments/production.rb. Tap the pencil icon. Find the config.hosts block:

config.hosts = [
  "trips.joelgaff.com",
  /.*\.joelgaff\.com/,
  "cucamonga.io",
  "www.cucamonga.io",
  /.*\.hatchboxapp\.com/
]

Add two lines:

"cucamonga.app",
"www.cucamonga.app",

Save. Commit to master.

Step 5: Hatchbox again

Push to master triggers auto-deploy. Hatchbox pulls, builds, restarts. About 90 seconds. Refresh cucamonga.app.

200.

Whole thing, phone in hand: about 15 minutes.

The point

It’s not that I did anything clever. It’s that the tools are good enough now that this is what shipping a rebrand looks like. One config file. No rebuild. No downtime. One commit. Thumb typing.

I’m not saying you should ship from vacation. I am saying this. On a mature Rails 8 + Hatchbox stack, the friction between “I want to do a thing” and “the thing is live in production” has collapsed to almost nothing. On a phone. In bed. In a foreign country.

Small ship. Now back to my tea.

Ruby is the language, Rails is a framework.

Think of Ruby as the raw materials needed to build a house.  Rails is a template or blueprint that *automatically builds* many of the common parts of the house that all houses need, without you having to do all the planning or building. 

You’re gonna need windows, so Rails makes spaces in your walls for windows. 

You’re gonna need a furnace, hot water heater, electrical wiring, and a roof over the house, so Rails takes care of all of that.  Every house needs those things. There’s no need to waste time building it all on your own.

You get to design and build all the fun stuff on top of the framework Rails has created for you.

The layout of the rooms, the shape of the house, the kinds of windows, the bathroom fixtures, type of flooring, lights and lamps, kitchen cabinets and so on. That’s your part.

In summary: Rails builds a scaffold (framework), upon which you can flesh out your house…er…project.

All the boring, monotonous steps have been taken care of for you.

More at world.hey.com/joelga

Before getting started

First, make sure you have Ruby and Ruby on Rails installed on your computer.

Second, make sure your command prompt is showing the location on your computer where you want this new Rails app to be created.

Take a look at the command line below:

joel@Joels-MacBook-Pro-16 projects %

The command line is showing that Terminal (the command line app I’m using on my MacBook) is currently in the ‘projects’ folder.  If I run the rails new command right now, a new Rails app (a folder with a bunch of files in it) will be created in the projects folder.

Create the project

Now we’re ready to create this project. In the command line run the `‌rails new` command. Swap out ‘grand-prix’ below for the title of your new project. Call it what you want, but make sure it’s either one word, or uses underscores or hyphens between words. Otherwise the first word will be used to create the project name (ie.’my new app’ would end up being called ‘my’. Use ‘my-new-app’ instead)

joel@Joels-MacBook-Pro-16 projects % rails new grand-prix

That’s it. When you run this command, a new directory (folder) titled ‘grand-prix’ will be created with the following directories and files (folders below are noted with the ‘/‘ at the end of the name):

- app/
- bin/
- config/
- config.ru
- db/
- Dockerfile
- Gemfile
- Gemfile.lock
- lib/
- log/
- public/
- Rakefile
- README.md
- storage/
- test/
- tmp/
- vendor/
- .dockerignore
- .gitattrubutes
- .gitignore
- .ruby-version

This set of files and folders has created a (very) basic rails app, and you can run it immediately.

Viewing the project

Next you’ll need to navigate into the project folder you just created.  A quick way to do this is to enter the command

cd <the name of the project you just created>

This will move your command prompt into the directory/folder (cd means change directory) of the project you just created. In my case I’d enter `cd grand-prix`.

Now, in the command line type `rails server`

joel@Joels-MacBook-Pro-16 gand-prix % rails server

The command line will output something similar to this (depending on the exact version of Rails you’re running):

joel@Joels-MacBook-Pro-16 grand-prix % rails server
=> Booting Puma
=> Rails 7.1.3.2 application starting in development 
=> Run `bin/rails server --help` for more startup options
Puma starting in single mode...
* Puma version: 6.4.2 (ruby 3.3.0-p0) ("The Eagle of Durango")
*  Min threads: 5
*  Max threads: 5
*  Environment: development
*          PID: 48667
* Listening on http://127.0.0.1:3000
* Listening on http://[::1]:3000
Use Ctrl-C to stop

To see your app running, visit that link `https://127.0.0.1:3000`.  This will open a web browser and display the following image (or similar, again, depending on the exact version of Rails you are running):

Bam.  You’ve created a Ruby on Rails app.

—
More at world.hey.com/joelga

I’ve started out as a complete newbie computer programmer, and am sharing my journey toward becoming a software developer (as in, getting a paid job as a software developer). I’m obviously no expert at this point, and will make tons of mistakes, so if you catch an error in any of my videos, let me know!

Likewise, if you know of a more efficient or a more preferred method to solving a coding problem I share here, I’d love to know - you can connect with me at joelga @ hey . com.

Links!:

Deep Work by Cal Newport: https://amzn.to/3EpU5NA

CS50 Course: https://cs50.harvard.edu/x

Basecamp: https://basecamp.com/

HEY: https://www.hey.com

My Newsletter: http://world.hey.com/joelga

My Home: http://joelgaff.com

The company was built slowly. We started small and grew organically. We only undertook debt once to buy some timing equipment (a 0% interest loan).

For various reasons, which you can listen to here, the time was right to let the events and timing services go and grow.

I knew the time was right, but I also knew it may be difficult to let go of something that had been such a big part of my life. It was more that a job, it really felt like an identity. I put my heart, soul, a little blood, and a lot of sweat into everything I did. 

I’m in the midst of the transition now, transferring files and knowledge over to the very capable team at Race Day Events. It feels really good. Good because I know that Race Day Events is a first-class operation, and good because it feels like the events and timing operation have finally grown up, and are leaving the nest - off to grow even more. 

I imagine this feeling is a little like what it’ll feel like when my little girls are ready to go off to college. A bittersweet moment. Ready to watch them grow and mature, but sad not to have them at the dinner table every night. 

I’m learning what my new role is, and learning to let go. It’s a challenge. But it’s a challenge that comes with new opportunity. 

This post was originally published at hey.world.com/joelga

This post originally appeared at world.hey.com/joelga.