DEV Community: Ujwal NK

One Shortcut, Not One Hundred for Tiling your Windows

Ujwal NK — Thu, 10 Sep 2026 03:25:50 +0000

TL;DR

Rectangle & Magnet gives you 100 different window tiling options, but you need to remember 100 different shortcuts.
Raycast gives you a 100 different window tiling options, but it's no more a shortcut but a phrase away.
GridTile gives you a 100 different window tiling options, and you need to remember one shortcut. Using Claude and your (not-main) project itself as a tutorial, is an amazing way to get started with learning a new language

Window management is an essential requirement. Moving to macOS made me realise just how much I relied on it. On Linux, I used the amazing Tactile extension for grid-based tiling.

Coming to MacOS, I tried a few options - Raycast, Magnet, Rectangle. That's when I ran into a problem.

Keyboard shortcuts - They're fast, they keep my hands on the keyboard, and once something becomes muscle memory, they are hard to beat.

So the first window-management tools I tried made perfect sense to me. Give every action a shortcut.

Left half. Right half. Top-left. Top-right. Bottom-left. Bottom-right. Maximize. Center. Move to another display. One-third. Two-thirds. And so on.

The problem is that window layouts don't stop at the layouts someone thought of when building the application.

I might want a window to take up the left 40% of my screen and another 60%. Or I might want a particular arrangement across two monitors. The moment I want something slightly different, I either need another shortcut or I need to start interacting with the application in some other way.
The shortcut problem

Keyboard shortcuts aren't free. (cue conflicts)

Utilities like Magnet, Rectange give you keyboard shortcuts to tile your windows and my keyboard has a finite number of combinations that I'm comfortable using. Other applications have their own shortcuts. The operating system has its own shortcuts. Other utilities are competing for the same combinations.

Everything is competing for the same pool of keyboard shortcuts. Imagine being a developer and discovering that the shortcut you use every day conflicts with your window manager.

Raycast solves this problem from another direction, if you want. Tiling is no more a few keys away, it's an entire phrase away.

Tiling is no more a few keys away, it's an entire phrase away

Bring tactile to MacOS 

Having gotten used to grid-based tiling, I thought: why not bring the same interaction to macOS? I could implement the whole thing as a simple script.

I would have one shortcut.

Not one shortcut for the left half, another for the right half, another for the top-left, another for the second monitor, and another for some obscure 37% layout I might use once a month.

Just one. Press it, and a grid appears. (I mapped it to the Stage Manager key, since I don't use Stage Manager anyway.)

Then use the keyboard to select two tiles on that grid.

Those two points describe the rectangle where the current window should go. That's it.

It started as a Hammerspoon experiment

The first version wasn't a Mac application. It was a Hammerspoon Spoon that I built for myself.

I was mainly trying to answer one question: Could I bring Tactile's interaction model to macOS, and would it actually solve my problem?

The prototype put a keyboard-addressable grid over the screen. One key selected a cell, and a second key defined the opposite corner. The focused window would then be moved to the resulting region.

The important part wasn't the implementation. It was the interaction.

Two keypresses could describe a huge number of possible window positions without requiring a huge number of shortcuts.

The original Hammerspoon project was deliberately small and configurable. The grid itself was defined in Lua, with configurable rows, columns, weights, and key assignments.

You can download the spoon for your hammerspoon configuration here

And, to my surprise, I wasn't the only person who liked it. I put it on GitHub. People starred it. People forked it. People started using it.

Someone even specifically requested for the spoon after I built the native version. even specifically requested for the spoon after I built the native version.

Then there were responses on Reddit from people who understood exactly why I had built it. That was the point where the project stopped feeling like a weird little script that solved a problem on my laptop.

Maybe it was worth turning into an actual application.

The reason for a native version

I wasn't a Swift developer, so Hammerspoon was the natural choice for the first version. It became my primary — and eventually my only — tool for managing windows.

But over time, I started noticing the limitations. Occasionally, it would lag or feel sluggish. I tried fixing it several times, but whenever Hammerspoon got into that state, restarting hammerspoon was often the easiest solution.

At the same time, I wanted to add more layouts and make the experience feel faster and more responsive. Those two things pushed me towards building a native version.

I wasn't particularly interested in spending six months first learning Swift and then eventually getting around to rebuilding GridTile.

And this was 2026. So I did something that would have felt almost absurd a few years ago.

I asked Claude to help me build it. Actually, "help me build it" is understating it.

Claude wrote a lot of the code.

The current application is a native Swift/SwiftUI/AppKit implementation, with macOS Accessibility APIs handling the actual window movement. It is a proper menu-bar application rather than a Hammerspoon script.

But there is an important distinction in how I approached this. I wasn't trying to get Claude to produce an application that I didn't understand. I was trying to learn Swift while Claude wrote the code.

You can download the native version here

Let Claude write the code. Make myself understand it.

So whenever Claude introduced something I didn't understand, I stopped and asked. When something broke, I tried to understand why before asking it to fix it. The goal wasn't to write every line myself, but to make sure I could follow the code I was shipping.

That turned out to be a surprisingly effective way to learn. I was learning Swift, AppKit, SwiftUI, and macOS APIs because I had a real problem in front of me—not because I was working my way through a textbook.

And that became the part of the project I found most interesting.

My Insights

Looking back, this changed how I think about learning to program.

Whenever I've thought about teaching someone programming, I've always felt that it would be more interesting to start with a small project they actually want to build, rather than making them learn the basics first, then the language, then the framework, and only eventually letting them build what they wanted in the first place.

I've been taught both ways, and more often than not, it is the latter. You spend your time learning syntax, concepts, and frameworks without always knowing why you need them. For me, that can make learning feel unnecessarily boring.

Building GridTile was the opposite. I was learning Swift because I needed Swift. I was learning macOS APIs because I needed them. Every new concept had an immediate purpose.

I probably learned less breadth than I would have through a traditional, textbook approach. But I had much more fun learning, and what I did learn felt much more relevant because I had a reason to remember it.

That, for me, was the most interesting part of building GridTile with AI.

Claude helped me write the application. But more importantly, it gave me a way to learn a language by building something I actually wanted to use.

Keeping Caddy and Docker in Sync

Ujwal NK — Tue, 04 Aug 2026 16:51:42 +0000

If you've been self-hosting for a while, you've probably run into this at least once.

You spin up a new Docker service, publish a port in docker-compose.yml, add a route to your reverse proxy, and move on. A few weeks later, you remove the service—but forget to remove the published port. Repeat that enough times, and you end up with a collection of stale port mappings that no longer serve any purpose.

ports:
  - "80:80"
  - "443:443"

  - "50000:50000"
  - "30000:30000"
  - "50001:50001"
  - "30001:30001"
  - "50002:50002"
  - "50003:50003"
  - "30003:30003"
  - "50010:50010"
  - "30010:30010"
  - "50014:50014"
  - "50021:50021"
  - "30026:30026"
  - "50034:50034"

That was exactly the problem I found myself facing. I had no clue, which one of these was the experiments that I had long ago abandoned, which were old services that I had removed, and which ones were actually still in service.

I run my homelab on a Raspberry Pi 5, and while it's surprisingly capable, I still prefer to keep my stack as lean as possible. I also wanted a workflow that was predictable. Every exposed service should exist because I explicitly declared it, not because a container happened to have the right labels.

I looked at solutions like Traefik and Caddy Docker Proxy, but they solved a different problem than the one I had. They optimize for automatic discovery. I was looking for control, and multi routing (LAN + Tailscale)

So I built a small workflow around Caddy that solved four problems for me:

A single source of truth for every exposed service.
Clean docker-compose.yml files that know nothing about reverse proxy configuration.
Multiple routes for the same service (local, Tailscale, and potentially more in the future).
Automatic synchronization of published Docker ports.

Maybe it'll fit your homelab too.

The Design Goals

Before writing a single line of code, I wrote down what I actually wanted from the system.

Keep the stack lightweight

This entire setup runs on a Raspberry Pi 5. While the hardware is more than capable of running Docker and Caddy, I didn't want to introduce additional services unless they provided significant value.

Caddy should remain exactly what it is—a reverse proxy.

No extra management containers. No background watchers.

Just configuration files and a couple of lightweight scripts.

Separate application deployment from networking

I wanted my application Compose files to describe applications—and nothing else.

Things like:

reverse proxy routes,
authentication,
published ports,
and networking policies

shouldn't live alongside the application itself.

That separation makes moving services between hosts much easier, and I don't need to touch ten different Compose files when changing how traffic reaches a service.

Support multiple routes per service

Some of my services are only accessible over Tailscale.

Others should also be available locally.

Some available over both.

Having a local endpoint isn't just about convenience—it also means that if my ISP or Tailscale is unavailable, I can still access my services from inside my home network (at least). External connectivity shouldn't become a single point of failure for services that never leave my LAN.

Tomorrow I might decide to expose services another way (CloudFlare, NetBird, etc...). I wanted a workflow that could grow without needing to redesign everything.

Keep everything explicit

I wanted one file that answered a simple question:

What services are exposed? How & Where?

If a service exists there, it's available with details. If it doesn't, it isn't.

Simple.

The Workflow

The entire workflow revolves around three small pieces.

Everything starts with a single master Caddyfile.

From that file, everything else is generated automatically.

The Master Caddyfile

Instead of treating my Caddyfile as just another configuration file, I made it the source of truth for the rest of the workflow.

A few simple comment markers tell my scripts whether a service should: (to be placed right after the row of # characters, placed on the next line for readability)

generate a local route - !
generate a local route protected with Basic Authentication - : (last 4 digits of the port is the password used in this example)
or remain Tailscale-only - ;

That means I only ever edit one file.

Example

############################################################################################# 
AudiobookShelf: 50030
https://my.tailscale.ts.net:50030 {...} # Generates local route with authentication

############################################################################################# 
PgAdmin; 50031
https://my.tailscale.ts.net:50031 {...} # Tailscale only route

############################################################################################# 
CalibreWeb! 50032
https://my.tailscale.ts.net:50032 {...} # Generates local route without authentication

Generating Local Routes

The first script, make-routes.sh, reads the master Caddyfile and generates a second one dedicated to local access.

Github Gist

During that process it:

converts external ports into local ports
removes TLS directives where required
injects Basic Authentication when required
and skips services that should remain Tailscale-only

The result is a second Caddyfile that never needs to be edited manually.

Generated Output

#############################################################################################
AudiobookShelf : 30030
http://:30030 {
    basicauth {
        admin $2a$...
    } 
    ...
}

#############################################################################################
CalibreWeb : 30032
http://:30032 {...}

Notice that:

AudiobookShelf has basic auth in the second file (Will be exposed on the local network with HTTP Authentication)
PgAdmin is not present in the second file (Will not be exposed on the local network)
CalibreWeb is present in the second file, but lacks auth (Will be exposed on the local network)
The ports have been changed from 50000 series 30000 series, to avoid port conflicts

Keeping Docker Ports in Sync

The second script, portmap.sh, solves the problem that started this entire project.

Github Gist

Instead of manually publishing ports inside docker-compose.yml, it scans every generated Caddy route, collects the ports that are actually in use, and updates a dedicated section inside my Compose file.

If I remove a route, the published port disappears automatically.
No stale configuration.
No forgotten ports.
No manual cleanup.

services:
  caddy:
    image: caddy:latest

    # ...

    ports:
    - 80:80
    - 443:443

    # ===== AUTO-GENERATED PORTS (DO NOT EDIT MANUALLY) =====
    # ===== END AUTO-GENERATED PORTS =====

    stop_grace_period: 10s

services:
  caddy:
    image: caddy:latest

    # ...

    ports:
    - 80:80
    - 443:443

    # ===== AUTO-GENERATED PORTS (DO NOT EDIT MANUALLY) =====
    - 50030:50030 # AudiobookShelf
    - 30030:30030 # AudiobookShelf
    - 30032:30032 # CalibreWeb
    - 50032:50032 # CalibreWeb
    - 50031:50031 # PgAdmin
    # ===== END AUTO-GENERATED PORTS =====

    stop_grace_period: 10s

A Couple of Handy Flags

Now here's the thing — once you've got a dozen-odd services running, you'll eventually forget which port you gave to what. Was AdventureLog on 50021 or 50012? Happens to me all the time, honestly.

So portmap.sh isn't just a sync-and-forget script. I threw in a query mode for exactly this situation.

./portmap.sh -q calibre

This does a case-insensitive, partial match search across all your route-*.caddy files and just tells you straight up:

CalibreWeb → 50032 (route-tailscale.caddy)
CalibreWeb → 30032 (route-local.caddy)

No need to grep through files or scroll up and down the Caddyfile trying to remember your own naming. You just ask, and it answers. Pretty neat for something so small.

There's also a -r flag, which is basically the "I trust this, just do it" option:

./portmap.sh -r

Instead of syncing the ports and leaving you to restart Caddy yourself, this one goes ahead and recreates the container right after — docker compose up -d --force-recreate under the hood. Good for when you're actively adding a service and don't want the extra step of remembering to reload things after.

One small catch — you can't use -q and -r together, and that's on purpose. One's for looking things up, the other's for actually changing your running setup. Mixing the two felt like asking for trouble, so the script just refuses and tells you to pick one.

Adding a New Service

Once everything is in place, adding a service becomes surprisingly simple.

Every new service follows exactly the same process.

Likewise, removing one is just the reverse: delete the route, rerun the scripts, and the configuration cleans itself up.

Is This Better Than Traefik or Caddy Docker Proxy?

Probably not.

It's simply solving a different problem.

If you like automatic service discovery, Docker labels, and infrastructure that configures itself, those tools are excellent choices. I just wanted something different.

My priority wasn't maximum automation—it was having a workflow that's easy to understand six months later. Every exposed service is explicitly declared.

My application Compose files stay focused on applications. The reverse proxy stays focused on routing. And I only ever edit one file when exposing something new.

For me, that's a trade-off worth making.

Source Code

The complete implementation, including both helper scripts, is available on GitHub.

GitHub Gists: https://gist.github.com/ujwalnk/5a9724ac80036452a2178db4f41c9933, https://gist.github.com/ujwalnk/f04d34417bc8b77f587fe6a5ebacaa95

Closing Thoughts

One of my favorite things about self-hosting is that there isn't a single "right" way to build a homelab. The best solution is often the one that fits the way you think.

This workflow probably isn't for everyone. If you're managing dozens of servers where automatic service discovery is a necessity, tools like Traefik or Caddy Docker Proxy make perfect sense.

But if you enjoy explicit configuration, prefer keeping your Compose files clean, and like having a single place that defines everything your reverse proxy exposes, this approach might give you a few ideas.

Even if you don't adopt it exactly, I hope it encourages you to build workflows that match your own priorities instead of defaulting to the most automated option available.