Octeth v5.9.6 is out today, and after two releases in a row with no new features at all, this one is the opposite. Sixty-one pull requests, sixty-nine issues, a brand new user interface and roughly sixty new admin API commands.
I have written before about making my peace with small releases on a two-week cadence. This is the other thing a fixed cadence produces: occasionally the fortnight lands on the week a large piece of work becomes ready, and you ship it because the date says so.
The largest piece is a completely new user interface. What I want to write about is not the interface itself so much as one decision about how we shipped it, because it is the decision I went back and forth on the longest.
We Shipped It Next To The Old One
The new interface does not replace the interface you have. It runs beside it.
Your existing customer area is still exactly where it was. Your admin area has not moved. The new interface answers on its own paths, has its own login, runs in its own container, and keeps its own database that never touches your Octeth data. If you upgrade and do nothing else, your team's day does not change. One setting turns the whole thing off.
That is not the tidy way to do it. The tidy way is to replace the old interface, migrate everyone, and be left with one thing to maintain instead of two. Every instinct I have as an engineer says do that. We are now carrying two interfaces, which means two places a bug can live and two places a feature has to land.
I decided against it, for a reason that has very little to do with engineering.
Octeth is self-hosted. When I ship a change, nobody at Octeth deploys it. An agency owner somewhere decides to run an upgrade, on a Thursday, on the platform that sends their clients' mail. If that upgrade also replaces the interface their team has been using for three years, I have not shipped them an improvement. I have shipped them a training problem, a support burden, and a week of their staff asking why the button moved, all of which arrive on their desk and none of which arrive on mine.
A platform you own should not be able to reorganise itself underneath you because your vendor had an idea. The ability to say "not yet" is part of what you are buying when you choose to host something yourself, and a forced migration quietly takes that away.
So the new interface is an offer rather than an event. Try it on one client. Leave it off entirely. Run both for a year while you decide. The cost of that choice is mine to carry, not yours.
The honest trade-off, since I would rather say it than have you find it: the two interfaces have separate logins for now. If you need both, you sign in twice. That is the part I am least happy with, and it is the next thing to fix.
What The Interface Actually Is
It is a complete second interface for your clients. Campaigns, journeys, subscriber lists, transactional sending, templates, suppressions and reporting, all built fresh.
The part that matters most for the agencies we work with is that it whitelabels properly. Brand name, legal name, support address, terms and privacy links, logo, wordmark, favicon and a two colour palette, all from configuration. Not a logo slot in the corner of something that is obviously somebody else's product. If you are putting a platform in front of ten or more clients under your own name, that distinction is the whole thing.
The Admin API Is Finally Complete
The other half of the release is less visible and, for some of you, more useful.
We went through all forty-seven admin screens and compared them against what the API could actually do. About a third were fully covered, a third partially, and a third had no programmatic equivalent at all. Settings, sub-admin management, global suppression, bounce processing, sender domain moderation, SMS gateways, delivery server performance reporting: all things you could do in our admin area and nowhere else.
That gap is now closed, across roughly sixty new commands. Which means the console your agency runs on no longer has to be the one we designed. If you onboard clients the same way every week, that is now a script. If our admin dashboard shows you the wrong five numbers, you can build the right five somewhere else.
Alongside it, sub-administrator accounts finally got a real permission model over the API. Each of your team members can hold their own API key rather than sharing the master one, so activity is attributable and a single key can be revoked without disrupting everyone. If you have a team of five and only two of them should be able to delete an account, that is now enforceable programmatically and not just on screen.
We Started Installing Our Own Release Before Releasing It
One more thing, because it belongs to the same family as the bug I wrote about last time.
Before this release, we added a step: build the real release package, then install it on two throwaway servers. One fresh install, one upgrade from the previous version. Not a test suite, not a review, an actual install of the actual archive.
The first time we ran it, it found three faults. The worst one left the installation directory in a state the web server could not read, so every single page returned a permission error while the upgrade process printed "Upgrade Complete!" on the way out.
That fault had been shipping since v5.9.4.
It was invisible to everything we already had. Our tests passed, because the code was correct. Code review passed, because there was nothing wrong with the code. A locally assembled package worked, because the problem only appeared in the archive the build process actually produces, on a server that had never seen Octeth before. The only thing that could catch it was doing exactly what a customer does.
I find that genuinely humbling. We have a lot of process, and none of it was looking at the one artifact every customer receives.
It runs before every release now.
Everything Else
The rest is correctness work, mostly in the places where a failure is silent. A journey action that failed to send used to advance the subscriber as though they had been mailed, so they permanently missed that email and nothing surfaced it. Segment rules that negate, such as "is not" or "does not contain", were excluding every subscriber whose field had never been filled in, which is the opposite of how they read. Campaigns now brand with your client's own verified sender domain, so per-client domain reputation finally counts on the channel that sends the most volume.
That last set of changes will move some numbers you are already looking at, in ways worth reading about before you upgrade rather than after. The changelog covers each one directly.
