caleb's website

Deployment Updates: Nix

me@calebsharp.dev (Caleb Sharp) — Fri, 24 Apr 2026 16:45:30 -0700

I’ve updated the build process for my site to use Nix.

If I stop working on it for a year, I want it to work still when I come back to it.
Faster build times because of caching
I wanted to learn more about Nix

I originally did this the “regular” Nix way, but it turns out this is kind of the “old” way? Apparently the more popular thing to use recently is “flakes” (which I have seen mentioned in passing a couple times prior). From what I’ve picked up on, this takes away some of the common impure footguns that usually come with Nix, the biggest of which is adding a lockfile for every dependency.

So of course I immediately reimplemented it as a flake.

I found this blog post which helped me get most of the way there, and I only had to learn a little bit more about how flakes work to finish (because I also need to install PostCSS via pnpm). I think I do like the flake approach a little bit better. For one, I can just stick everything in one file instead of having separate build.nix, shell.nix, default.nix and whatever else files. I think it’s also provides a bit more standardization, which felt like one of the most confusing things about Nix when I first started learning about it.

I found this documentation helpful for setting up pnpm: https://nixos.org/manual/nixpkgs/stable/#javascript-pnpm

Here’s my flake.nix as of writing this:

{
 description = "caleb's website";

 inputs = {
 nixpkgs.url = "github:nixos/nixpkgs?ref=10e7ad5bbcb421fe07e3a4ad53a634b0cd57ffac";
 utils.url = "github:numtide/flake-utils";
 };

 outputs = { self, nixpkgs, utils }:
 utils.lib.eachDefaultSystem (system:
 let pkgs = import nixpkgs { inherit system; }; in
 {
 packages = rec {
 calebsharp-dev = pkgs.stdenv.mkDerivation (finalAttrs: {
 name = "calebsharp.dev";
 src = self;

 nativeBuildInputs = with pkgs; [
 git
 hugo
 pnpmConfigHook
 pnpm_10
 nodejs_24
 ];

 pnpmDeps = with pkgs; fetchPnpmDeps {
 pname = finalAttrs.name;
 src = finalAttrs.src;
 fetcherVersion = 3;
 pnpm = pnpm_10;
 hash = "sha256-k/2/Yjcs5h6P2Z6UMzkhMMDHXhTUPlMvMWtorhLLM94=";
 };

 buildPhase = ''
 hugo --minify
 '';
 installPhase = "cp -r public $out";
 });
 default = calebsharp-dev;
 };

 apps = rec {
 build = utils.lib.mkApp { drv = pkgs.hugo; };
 serve = utils.lib.mkApp {
 drv = pkgs.writeShellScriptBin "hugo-serve" ''
 ${pkgs.hugo}/bin/hugo server -D
 '';
 };
 newcontent = utils.lib.mkApp {
 drv = pkgs.writeShellScriptBin "new-post" ''
 ${pkgs.hugo}/bin/hugo new content "$1"
 '';
 };
 default = serve;
 };

 devShells.default = with pkgs; mkShellNoCC {
 nativeBuildInputs = [hugo go rsync openssh pnpm_10];
 };
 }
 );
}

I’m sure there’s improvements to make and I know there’s still lots to learn. I’m also starting to pick up on the idea that there’s probably many different ways of accomplishing the same thing, which tends to make learning a tad bit slower.

Local dev is super easy, since I can just run nix run (which is an alias of nix run .#serve) and automatically bring along the dependencies I need (just hugo in this case).

I also have noticed some improvements in CI performance. I have my self-hosted Forgejo runner, which is great, but the runner image I use doesn’t include all the tools I need, so I’ve been running apt from within the runner to add dependencies I need. I never love doing this because it’s both slower and less reproducible. I considered building my own custom runner image with the tools I needed, but that’s an extra maintenance burden that I don’t want, and it doesn’t help me if I need different versions of tools between projects. Nix has basically solved all these problems, because it’s fully deterministic, and I can cache the entire Nix store folder to speed up subsequent builds if dependencies don’t change. I don’t know if this is totally the right solution (I think a big problem is the size of the folder can grow indefinitely, so I’ll need some kind of cron job to periodically prune it), but it seems to be working.

My new deployment workflow:

name: Build and Deploy Website

on:
 push:
 branches: ["main"]

jobs:
 build:
 # A custom runner image that includes basically just Nix and node
 runs-on: nix-latest
 container:
 volumes:
 - nix-store:/nix
 - nix-cache:/root/.cache/nix
 defaults:
 run:
 # Run all commands in the same dev shell environment I run locally. Tools have the _exact_ same version in CI, which is pretty cool
 shell: nix develop --command bash -c "{0}"

 steps:
 - uses: actions/checkout@v6
 with:
 submodules: recursive
 - name: Add SSH key
 env:
 SSH_AUTH_SOCK: /tmp/ssh_agent.sock
 run: |
 mkdir -p /root/.ssh
 which ssh-keyscan
 ssh-keyscan x.x.x.x >> /root/.ssh/known_hosts
 echo "${{ secrets.SSH_KEY }}" > /root/.ssh/github_actions
 chmod 600 /root/.ssh/github_actions
 ssh-agent -a $SSH_AUTH_SOCK > /dev/null	
 ssh-add /root/.ssh/github_actions
 - name: nix build
 run: nix build
 - name: Deploy
 env:
 SSH_AUTH_SOCK: /tmp/ssh_agent.sock
 run: |
 # Just need to copy hugo build artifacts to deploy
 rsync -avz --delete result/ caleb@x.x.x.x:/srv/calebsharp.dev

On Rental Scooters

me@calebsharp.dev (Caleb Sharp) — Mon, 20 Apr 2026 09:56:57 -0700

We took the new Bird e-things they’ve deployed to Kamloops yesterday. We’d ridden them once before, for a shorter one-way trip. This time, we wanted to head across the river to grab some ice cream, and I also wanted to try the new e-bikes they’ve started putting out. I was able to find one, but my partner had to take a scooter, because only I have a helmet and only the scooters come with one you can rent.

Unlocking

To actually rent one of these things is relatively straightforward. All of the “vehicles” have a little QR code that you’re meant to scan in the app to unlock. After some waiting around for what I assume is some bluetooth negotiation, an apple pay prompt will appear, to charge you with an “amount pending”. They take a $3 hold while you are renting, so I assume that’s related. Then, once you’ve unlocked it, you’re basically ready to go.

As with anything wireless and probably shitty-react-native, don’t expect this to go very smoothly. The first time I attempted to rent a scooter, I got stuck in the helmet rental screen, which presented me with instructions that were clearly for a completely different type of scooter. I also made the mistake of reserving that scooter (since it was a 10 minute walk away). Turns out you get charged at the same rate as riding it, so I paid like $7 for nothing.

The ride

The ride sucks. I’ve not tried many e-bikes before and this was actually my first time trying an e-scooter, but they both had incredible rigid suspension. Actually, I think the bike has no suspension. They’re also super heavy. I don’t think this is necessarily a surprise to people who are more familiar with this type of thing (after all, they have to put up with a lot of abuse. More on that in a sec), but it was definitely a different experience than the “regular” e-bikes I’ve ridden before.

They’ve also been totally trashed. The bikes have only been out for a week and they’re already covered in graffiti and scuffed to hell. That said, after mentioning it to a friend, he said it’s probably just because they’ve come from another city and we’re not getting brand new stuff. Fair enough, my faith in people is slightly restored.

Anyway, we were able to ride across the bridge and grab some ice cream (I got spumoni; very good) and hang out for a bit. We decided to book it back after we saw the huge rain cloud that had been looming in the distance shift over to us. We both took scooters on the way back.

Parking

You have to park the scooters in designated areas. This is pretty annoying, especially because they can be relatively spread out, depending on the part of town. This means you have to basically plan where you’re going to park before you start the ride. If you don’t check ahead of time, you have to stop and pull out your phone, since the parking spots are only indicated by map icons in the app. If you’re lucky, there’s another scooter already there you can use as a landmark. Once we ran into an issue where the app just wouldn’t recognize that we were in a parking spot, which is pretty lame especially when the ride time continues to tick up.

Pricing

We took about 15 minutes each way (about 4km). The total cost for both of use was probably around $25-$30 (one of us had to rent a helmet). The pricing is pretty clear before you unlock the scooter ($1.15 fixed unlock fee + $0.35/min), but I was still pretty surprised at how expensive it was to take such a short trip. They have some monthly pass options that I had initially scoffed at for how expensive they seemed, but in comparison they’re a pretty good deal. Not sure if that’s a good thing.

Update: I’ve taken out a scooter a couple more times since writing this. I ended up getting the $4/mo “unlimited rides” pass, which basically caps ride fares to $3 (+ tax!) for 20 minute-and-under rides (I think you get charged at the regular fare for time after). Not sure of the exact math, but I only had to do two 15 minute rides to make that worth it. $3 rides makes it significantly more competitive with other modes of transport IMO. If you need to do lots of trips in a day though, it’s still hard to beat the $4.50 day pass for the bus.

Conclusion

The larger problem was just the lack of infrastructure for most of the way there. Unfortunately, when we don’t have the ability to use a dedicated bike lane (which is more often than not), we’re required by law to ride on the road. I don’t mind this on a bike (not to say I like it; it’s still a horrible experience cycling here most of the time), but the scooter was a new level of fear. Compared to a bike, I feel quite a bit more vulnerable and unstable. Riding down a busy road with trucks passing by within an arms-length at 60km/h is not a pleasant experience (not to mention by law they’re supposed to give us 1.5m. Oh well). I can’t recall who said this, but I saw somewhere scooters described as being in the “uncanny valley” of transportation options. That feels apt. If we had great cycling infrastructure, I wouldn’t foresee much adoption of these, since most people would already have a bike, or at least would prefer the experience of renting a bike/e-bike. With how spread out everything is here, it’s hard to think of a trip where taking a scooter makes much sense. If I just need to get around downtown, I would prefer to walk, especially because I would have to ride on the road. On the other hand, if I want to take it on a longer trip, it also doesn’t make sense, primarily due to the steep price. At that point, it’s more competitive to take rideshare, which I think is crazy. Even the bus is a better deal, and depending on the trip, also more convenient.

Update: With the monthly pass, I don’t think the scooters are quite as bad a deal as I made it out to be here. It’s still almost always more expensive than the bus, but especially on weekends when bus frequencies are lower, it can be a lot more convenient. I don’t think this changes any of my thoughts on the ride experience and lack of infrastructure though.

Overall, I don’t think we’ll see much uptake, and unfortunately I think most people will interpret this as a lack of wanting alternatives to driving. It’s nothing new when it comes to cycling infrastructure, and more generally to any transportation options other than the private automobile, but it’s a bit frustrating that people can’t understand that it doesn’t work because we aren’t making the systemic changes to our city that would let them work.

My most optimistic take is that people will try the e-bikes once, and realize that it sucks to ride in Kamloops in most places, and they’ll be radicalized to advocate for change. I think the more realistic outcome is that people will try it, they won’t like it, and it’ll just reinforce their belief that driving is the only way.

How My Site Is Deployed

me@calebsharp.dev (Caleb Sharp) — Wed, 15 Apr 2026 09:19:03 -0700

tl;dr

Changes are pushed to a self-hosted forgejo instances
Pushes to main trigger an action that builds the site with hugo and copies it with rsync to another server.
Caddy serves the static files at /srv/calebsharp.dev

Hugo

This is pretty self-explanatory, but this site is built with Hugo. This is actually my first time trying it, and I’m still getting used to it. For that reason, I decided to start with a theme and ended up choosing this neat terminal theme by panr. I’ve started to rip it apart and customize it to my liking and I expect to eventually change most everything. At this point, I’m still trying to decide if it makes more sense to treat my custom stuff as a “theme”, or just inline everything into the main project. I get the feeling it only matters if I want to re-use the theme on another site, and/or share it. Guess we’ll see!

Other than that, I’ve been appreciating the authorship experience of Hugo. I feel like I can focus on writing when I want to write, and focus on everything but the posts when I want to tinker. It’s a nice separation of concerns that I think stops me from getting too distracted.

Forgejo

I host my own Forgejo instance on an old PC I have at home. I use Tailscale to connect to it (and holy crap what a useful tool that is). I have a cheap Hetzner instance somewhere in Germany that I use as an actions runner (I’ll have to write about that soon, it’s a bit finicky to set up, especially in my case where I wanted to run the runner in podman and run workflows in “nested” containers). Other than that, it’s pretty stock.

To have a nice domain/SSL, I don’t use Tailscale’s MagicDNS feature (I think the domains are ugly!). Instead, I just have a public DNS record that resolves to the internal Tailscale IP of the machine (dig forgejo.ts.calebsharp.dev). If you’re not on the tailnet, you can’t connect. I proxy Forgejo (+ all the other things I run) through Caddy for automatic HTTPS.

When I push new changes to the upstream repo, the runner kicks off a build job that basically just installs some tools (TODO for myself: add tools to the runner image) and runs hugo build --minify. I’m using mise to manage the versions of the tools I need, both for local dev and in CI/CD (although I can’t get it to install hugo; there seems to be some problem with the URL it tries to access for macOS builds). It then copies the built static files with rsync to my Hetzner VPS that’s actually hosting the site. Since both the runner and server are both in my tailnet, it’s trivial to let them connect via SSH without having to worry about exposing SSH to the world. That’s it for deployment! It’s a little refreshing to not have a stupidly complex build step with containers and linters and all that crap.

Caddy

The static files deployed to the server are ultimately served by Caddy. Pretty basic config, along with some automatic HTTPS and basic cache-control headers:

calebsharp.dev {
 root /srv/calebsharp.dev
 encode zstd gzip
 file_server

 header /css/* {
 Cache-Control "public, max-age=3600, must-revalidate"
 }

 header /fonts/* {
 Cache-Control "public, max-age=604800, must-revalidate"
 }

 # API credentials for ACME DNS challenges
 import porkbun
}

And that’s it! I mentioned this in my first post, but it’s nice to have something architecturally simple to let myself focus on writing when I want to. On the other hand, I feel like I have quite a bit of flexibility to do whatever cool stuff I want to try out. I think it strikes a nice balance.

Thanks for reading! If you’re trying to do something similar and want to chat about it, feel free to send me an email (info on the about page).

Hello World

me@calebsharp.dev (Caleb Sharp) — Mon, 13 Apr 2026 12:26:25 -0700

Hello world!

This is my first post, finally. After a long time (easily years at this point), I’ve finally moved past the stage of “building a blog”, to “writing a blog”. Who knew that it could take so long to do myself what others have done bajillions of times.

I’ve decided to just use Hugo. Hopefully it’s going to protect me from my own urge to endlessly tinker with the tech ¹. Ironically, I feel much less of a desire to iterate on my words. I think I will be mostly happy to just publish whatever stream-of-consciousness garbage comes out.

Here’s to at least one more post!

IIRC my last attempt was a from-scratch HTTP server in Rust, along with htmx. Why I added frontend interactivity before building any frontend: for fun. Did I ever finish: no. ↩︎

About

me@calebsharp.dev (Caleb Sharp) — Mon, 01 Jan 0001 00:00:00 +0000

caleb’s website

Hi, my name is Caleb. I’m a profesional software developer. Mostly, I find myself these days building wildfire modelling tools.

I enjoy working with Rust, and recently have had a lot of fun building tools with Elixir/Phoenix LiveView.

Other hobbies include: urbanism, trains, biking, cooking

GitHub

me at this domain