Beta Late Than Never
July, 2026
Debugging Begins…
The first non-admin user has now deployed multiple services with Dorsal!
While this is still exciting, I must admit that the non-admin user is also me, which does make it a bit less of a milestone. Technically, I suppose, we’re still in alpha testing.
I originally thought that I would likely need someone external to help with beta testing, but I’m actually finding it pretty easy to log in and act like a super annoying user. I don’t fully read things. I fill out forms with whatever comes to mind, and I report bugs as soon as I’m confused or when something doesn’t work immediately.
As a result, my Admin/Developer persona has had a hefty backlog of bug reports to wade through over the past week or two, and it’s been awesome.
Honestly, even though bug bashing is typically tedious, it’s been such a nice change of pace to simply pop an issue off the little kanban board that I’m using, put on some music, and get to work.
I’ve spent the better part of the past year making big, important architectural or database-level decisions, and it’s been a nice break to just find missing functionality at certain endpoints, unhandled exceptions, and missing documentation.
For the time being, I really don’t need to bring on another user for testing, though that point appears to be getting nearer and nearer. I figure that I’ll loop in my first third-party user once I stop finding bugs on my own every time I sit down to use the app.
Picking up from last month’s Dev Log, I had said that I just needed to:
- Add OIDC auth for ECR image pushes from Github
- Test with my personal user
- Fix any egregious bugs
- Call on my first
alpha userbeta user
So, I’m well on my way!
Token Broker
One of the main implementation details that occurred this past month was the introduction of a simple Token Broker API for the Github Actions auth flow.
I had originally hoped to leverage AWS Session Tags to create a scoped role from a single IAM Role that all Github Actions could assume directly via AWS. The idea was that the scoped role would only allow the Github Action to push images to the ECR Repo(s) with which it was associated in Dorsal.
Due to some security-based restrictions in AWS that prevents wildcards, this was not an option.
So, instead of calling STS or an AWS OIDC Provider endpoint directly, the Github Action now calls a Dorsal API endpoint, which authenticates the JWT and returns scoped session tokens for the Github Action to use when pushing the image to ECR.
This actually works so well that I may update the Static Website deployment flow to do the same thing.
Because a Github repo is connected to Dorsal via a Github App installation, I’m able to confirm that the same user connected the Github repo and owns the ECR repo that it wants permission to upload an image to.
This sort of information lives in the Dorsal database, so if I add future functionality, like subscriptions, I could verify that data against the request at the same time. It also allows me to add standard controls for an internet-facing service (firewall, rate limits) without risking additional charges from AWS for spam throughput.
Performance Improvements
Health Checks
One of the things that my annoying test user was complaining about was 502 and 503 errors when reloading the web console.
Despite the fact that this is, obviously, very rude behaviour on his part, I did fix those (I think). The issue came down to an incorrectly configured ALB health check, which would wait for the retries to timeout and then allow the unhealthy target groups to serve traffic.
Fixing the health check meant that the rolling nodes/pods now serve traffic right away.
Reconciliation
I’m also finding that the process of triggering manifest regeneration is becoming too intertwined with other logic: rendering forms, updating the database, etc.
To avoid scattering calls to deployStack(...) or deployApplication(...) everywhere, which idempotently regenerate the relevant manifest(s) based on the current database state, I’m planning to investigate adding something like a response middleware to the requests.
The idea would be that the request goes through the following flow:
- Authentication
- Authorization
- Action (database update, form template render, etc)
- New Step: Conditionally trigger a manifest regeneration
- Respond to the user
The new step above would probably check things like the HTTP method and path. For example, if it was a GET request, abort the regeneration flow and simply proceed with whatever the response was going to be.
However, if it were a mutating method, the path could be inspected to determine what may have been changed. The manifest regeneration can then be triggered for the relevant objects, and then the response is returned to the user.
This will, ideally, place all of the manifest regeneration logic in a single place, making it much more maintainable. It will also keep the other code paths clean.
Vibe Check
So, how am I feeling about things? Despite having one of the most socially-demanding months of my life (in a good way), July was also incredibly productive on the Dorsal front, and I’m feeling very optimistic.
It finally feels like I’m progressing towards a useable application every time that I sit down to work on it. As always, I have a nearly limitless list of ideas, but I finally feel like I have enough of the core functionality satisfied that a less-buggy version of what I have now would provide value to people.
Reliable manifest generation, like I described above, will go a long way to closing the gap. Many of the bugs I’ve been fixing have been related to a busted state reconciliation process. Beyond that, there will be some time spent on any unapologetically bad rendering issues, a little documentation, and automated tests.
Oh, that’s worth mentioning… browser-based tests are still proving to be a real time save. Using a simple, serverside-rendered web app that can run 100% locally has meant that Playwright tests have been far more reliable than I’ve experienced on other projects.
The test generation is mostly trivial, though the selectors often need to be cleaned up a bit. But if I spend 20 minutes on making some tests for new functionality, I save that time back within the week. I feel far more confident about refactoring implementation details now than I would in a world without my little E2E test suite.
So, overall, the vibes are pretty good. As of early August, 2026, I feel like I made some appropriate decisions about the structure of Dorsal as a system, and I think I’ll be able to continue building on it for the foreseeable future.
Until next month,
Nathan