One Year of Dorsal

October, 2025

A few weeks ago, my credit card statement let me know that I had officially renewed dorsal.ca for another year. Hard to believe... considering the site only went live a few months ago.

Even harder to believe when all that lives there is a single index.html file with a link to the Dorsal Console.

Either way, it is what it is: a year of work, and I want to start documenting progress before it's too late to capture "the early days."

Where We're At

I have an endless supply of ideas for what Dorsal could be, but let me take a few minutes to lay out where we're at today.

The Landing Page

It ain't much, but it's honest work. Just a link to the console. What more could one want?

The Dashboard

After authenticating via the AWS Cognito Hosted Login UI, you'll land on the dashboard.

Most recently, I added a table for your Github App installations. This is actually a massive step, and it took a couple of weeks to build-out.

"A couple of weeks?!"

• You, probably

Well, yes, it turns out that having a real job, wife, friends, and hobbies takes a substantial bite out of your time for side projects.

But now that the Github App Installation flow is built-out, it has provided:

• A secure way of associating Users with Github App Installation IDs (for processing in webhooks)
• Handy little dropdowns for Github Accounts & Repositories

The former was absolutely necessary for confidently processing Github webhooks. The latter is just a quality of life improvement (but one that I love).

Below the Github Apps table, you'll find tables for your Projects and User Directories.

Projects and Stacks

A key proposition of Dorsal is that your Projects are the highest abstraction. Anything that can/should/might want to communicate over a private network should be grouped into a Project.

Of course, it's possible to communicate across projects, but you'll have to touch the filthy internet (yuck!).

My hope is to make Environments and Stacks a simple and powerful abstraction that produces an intuitive matrix of your applications.

User Directories

These are pretty janky right now, but they do technically work.

The idea is that you create a User Directory, and associate it with any Project, Stack, or Environment that needs user authentication.

Each application in that Project/Stack/Environment will then register itself with the User Directory.

This could allow you to provide a single sign-on experience across your applications, for example.

In my case, I'm simply using one User Directory for localhost development, and another for my production applications.

Easy peezy.

Domains

How could I almost forget Domains?

This flow took me approximately an eternity to implement, but I think it works properly now.

The concept is very simple: you add a domain that you own, prove that you control the DNS, swap the nameservers, wait for Dorsal to confirm that its nameservers are now authoritative, and then you can use that domain for any application in Dorsal.

Dorsal, currently, needs to manage your DNS records, and I'll be leveraging that for dynamic PR/Preview environments in the future.

I can imagine someone wanting to retain their existing nameservers, and/or add their own DNS records. For now, that's not a priority.

This Blog

Lastly, I'm launching this blog - hosted on Dorsal, of course.

Even at the time of writing, I'm not yet sure how I'll be rendering the content. It's a raw Markdown file at the moment.

I intend to offer a "Markdown Blog" deployment option, and dogfood it with this blog. Depending on how much time that takes to implement, it may be how you're reading this post!

This Dev Log blog will likely live alongside a more technical blog, which - candidly - will be part of marketing efforts to bring people to Dorsal. For now, though, I won't get too far ahead of myself.

Speaking of which...

The Future

The future is full of way way too many ideas, so I'll start with just the very near term.

Environment Variables

I currently connect to the database via a bastion host and yolo insert the environment variables that I need.

This can and should be resolved very soon with a simple update to the API to support environment variable CRUD actions.

It's even worse for secrets, where I manually log into AWS, add the secrets, and then yolo insert the keys into my database.

But we don't need to talk about that...

PR/Preview Environments

I need to fully spec this out, but I want to have something like a checkbox for "provision dynamic environments" and then any PRs that open against the target branch will trigger a dynamic environment to be provisioned, based on a simple template.

I'll start with just Websites (no server/API or database).

My intention with everything is to work on polishing the website/domain/user directory experience with alpha users, and gradually roll it out to beta users, then public preview, and then to everyone.

This will be the process that I later follow with servers/APIs, databases etc.

And That's It

Well, of course, that's not really it, but that's it for today.

If I start talking too much about the future of Dorsal, it will quickly veer into wild speculation and wishcasting.

I'm thinking of having a separate series that's more of a "technical blog," where I can discuss the implementation details, but this dev blog will serve as a high-level overview of progress and rough feature roadmap.

Honestly, I can't believe I've managed to stick with this for a year, and now I'm in too deep to bail.

Stick around, I guess.