the0 v1.14.0 - Catching Up

The last proper release post was the0 v1.3.2 - State and Queries. That was January 2025.

The current line is now v1.14.0.

So yes, there is a gap.

This post is not going to pretend the silence was a content strategy. It was not. the0 is not just a product to me. It is me. It is the thing I kept shaping while life was doing what life does, which is sometimes brutal and sometimes very quiet about it.

Most of 2025 was spent trying to understand what comes next after my dad died from cancer. Losing him did more than hurt. It damaged a lot of my self-confidence. I have always been introverted, but after that I became much more closed off, mostly interacting with family and a few friends.

I kept coding because work is often how I cope. the0 and other side projects gave me somewhere to put the grief, fear, and restlessness. Writing publicly was harder. Being public with people, and being public with my work, started to feel exposed in a way I did not know how to handle.

At the same time, my mum is going through her own fight with cancer, and we are trying to be there for her. That made life feel more real and more urgent. It made me feel even more closed off, but it also made the responsibility clearer: I need to focus, build things that matter, and provide for my family.

So this is part of me trying to be public again, despite the discomfort.

Now let me catch you up.

The Short Version

Between v1.3.2 and v1.14.0, the0 became smaller, stricter, and more operationally serious.

The main direction:

• The platform moved further toward CLI-first deployment.
• Backtesting was removed from the product surface.
• The AI Agent Workbench was removed from the frontend.
• Runtime execution became more explicit across Docker and Kubernetes.
• Local development got more reliable.
• Security and dependency work became a regular part of the project.
• The app is now moving toward an app-first model with login and dashboard as the first real screens.

If earlier versions were about proving that the platform could support many languages, state, queries, and runtime modes, this period was about deciding what the0 should stop being.

That is not as flashy as a launch post, but it matters more.

The Missing Version Ledger

Here is the compressed version ledger from the missing public comms window. This is not every patch, but it is the shape of the work.

v1.4.0

v1.4.0 was a deployment and packaging release. Helm packaging became more serious, and the chart started supporting external services. This was the point where the Kubernetes story became less of an internal convenience and more of an operator-facing path.

It also carried earlier AI and research-agent experiments. Some of that work did not survive into the current product direction, but it matters historically because it shows the project still exploring how much surface area the0 should own.

v1.5.0

v1.5.0 started the local development reset. The old docker/ folder was removed in favor of the0 local, and install instructions moved toward the vanity installer path.

This was a major product signal. Local the0 stopped being a collection of compose files you had to understand first and started becoming a command-led workflow.

v1.6.0, v1.6.1, and v1.6.2

The v1.6 line made local mode more practical. the0 local moved toward prebuilt GHCR images by default, example bot deploys were fixed, runtime image resolution got corrected, and slower CLI update paths were made less fragile.

This was not a glamorous release line. It was the kind of work that makes onboarding less embarrassing.

v1.7.0 through v1.7.9

The v1.7 line was mostly about logs, auth routing, and production rough edges.

Real-time bot log streaming landed through NATS and SSE. Scheduled bots were corrected to use polling where streaming did not fit. Auth calls moved through the Next.js API proxy. The domain moved from the0.dev to the0.app. Helm ingress bugs were fixed. MinIO SSL support reached the bot controller. Log endpoints, stale database connections, scheduled bot console performance, and frontend security updates all got attention.

This is the line where the app started feeling less like a demo UI and more like something that had to survive real usage.

v1.8.0, v1.8.1, and v1.8.2

The v1.8 line was about data correctness and state continuity.

Bot version bumps were fixed so state was preserved correctly. JSONB handling between postgres.js and Drizzle was repaired. API key timestamps, clipboard handling, and stale dependencies were cleaned up.

This was the sort of release line that protects trust. If a bot update loses state or a JSON field gets encoded twice, the product stops feeling reliable fast.

v1.9.0

v1.9.0 brought the unified master-detail dashboard redesign.

This matters because the product was carrying too many separate screens and weak transitions. The dashboard started moving toward a more coherent operational console, where the user can inspect bots, logs, status, and details without feeling like they are jumping between unrelated tools.

v1.10.0

v1.10.0 was a security and correctness release.

Hardcoded JWT fallbacks were removed. Auth errors moved away from string matching toward typed API errors. Missing database indexes were added. Runtime containers lost unnecessary privileged mode. API typing was tightened.

This was one of the more important invisible releases. A self-hosted system that runs code cannot treat security posture as a side quest.

v1.11.0 through v1.11.4

The v1.11 line focused on custom bot version management, cleanup, and logging performance.

Custom bot versions became easier to manage and clean up. Old PRP, story, and AI context artifacts were removed from the tracked repo. Logging navigation hangs and stale state accumulation were fixed.

This was another simplification line. Less repository clutter, better custom bot lifecycle management, and fewer frontend performance traps.

v1.12.0 through v1.12.5

The v1.12 line made logs and metrics more usable.

Interval pickers landed. Bundle caching improved. NDJSON parsing improved. Streaming log reads were fixed. Metrics filtering got sharper. Temporary file cleanup improved. Tail-based log reads, hour presets, live defaults, UTC interval handling, missing log file handling, and dashboard refresh behavior all got patched.

This was a real operator experience release line. Observability only counts if the UI can keep up with the volume and the time ranges mean what users think they mean.

v1.13.0 through v1.13.5

The v1.13 line continued the operational polish and then shifted hard into security.

Console and dashboard refresh intervals became configurable. Scheduled bot defaults were corrected. Log entry expansion preserved timestamps. Final sync timeout increased for slower shutdown paths. Named CLI environments landed through the0 env. Database readiness checks became opt-in.

Then v1.13.5 pulled a lot of security work together: security scanning CI, hardened container images, pod runtime security, API dependency remediation, SDK docs dependency remediation, frontend dependency remediation, Go vulnerability fixes, runtime integration test stabilization, and security summary cleanup.

That is a lot of work hidden behind one quiet version number.

v1.14.0

v1.14.0 is the app-first auth release.

The app no longer starts as a marketing page with public signup. Fresh installs and existing installs go to login. Authenticated users go to the dashboard. The root admin is now created or synced from deployment configuration with THE0_ADMIN_EMAIL and THE0_ADMIN_PASSWORD.

It also adds admin user management, self-service user settings, last-admin protections, local admin configuration support, and deployment docs for root admin configuration.

This release changes the posture of the product. the0 is now more clearly a self-hosted operations app, not a public signup SaaS shell.

Public Silence, Private Work

The site made it look like the0 paused at v1.3.2. The repo did not.

There were releases, fixes, security patches, runtime changes, CLI changes, Kubernetes changes, frontend removals, docs updates, dependency patches, and architecture corrections. The work continued, but the public narrative did not keep up with it.

That is a problem for a project like this.

Self-hosted infrastructure needs public communication. Operators need to know what changed, what broke, what got removed, and what they need to do during upgrades. Developers need to understand where the product is going. Future me also needs a trail of decisions, because code alone does not explain the emotional or product context behind a release.

So from here on, minor versions should get short public notes. Not essays every time. Just enough to answer:

• What changed?
• Who needs to care?
• Is there an upgrade action?
• Why did we make this decision?

This post is the catch-up note.

CLI-First Became Real

One of the clearest product decisions in this period was moving deployment toward the CLI.

The frontend used to carry more deployment workflow than it should have. That sounds convenient until you maintain it. Deploying bots is operational. It needs repeatability, scripts, local files, config files, version control, and predictable failure modes. A browser form is not always the right place for that.

So the0 moved more of that weight into the CLI.

The frontend still matters. It is where you inspect deployed bots, read schemas, view running instances, and understand the system. But the act of packaging and deploying custom bots belongs closer to the developer's machine and closer to the source files.

That is why the app now points users toward CLI deployment instead of trying to own every step in the UI.

This also made the product simpler. Fewer forms. Fewer half-overlapping flows. Fewer places where a bot could be "almost deployed" but not quite.

And the app itself has become more operational. This is the kind of screen the product is moving toward: bots on the left, a focused dashboard in the middle, live logs on the right.

The Product Got Smaller

Some features left.

Backtesting was removed. The AI Agent Workbench was removed. Frontend deployment forms were removed. Update flows that belonged in the CLI were moved out of the app. The old idea that the0 should be a broad platform for every adjacent workflow got cut back.

That might sound negative, but it is one of the healthier things that happened.

the0 is strongest when it is focused on this core loop:

1. Build a bot.
2. Package it with a clear schema.
3. Deploy it.
4. Run it in a controlled runtime.
5. Observe logs, metrics, state, and query results.
6. Update it without guessing what the platform is doing.

Everything else has to justify its place.

Removing code is not glamorous. It is also not just cleanup. It is product design.

Runtime Work Became Less Romantic

The v1.3.2 post talked about state and queries. That was an exciting architecture post because the feature was new and visible.

The later runtime work was less dramatic, but very important.

Docker and Kubernetes both needed sharper behavior around runtime images, writable paths, object storage, local healthchecks, and the way source-mode runtime services start up. There were fixes around local Docker socket permissions, Kubernetes runtime hardening, query results, vendored dependencies, and image wiring.

This is the kind of work that does not always make a great headline, but it is the difference between "cool demo" and "I can run this without babysitting it."

In self-hosted systems, boring runtime behavior is the goal.

Security Became Routine

Another big change was the amount of security and dependency work.

There were dependency remediation passes across API, frontend, SDK docs, and Go components. Security scanning became more visible. Container hardening became more deliberate. Accepted vulnerabilities got written down instead of hand-waved.

That is not a one-time effort. It is maintenance.

I used to think of security work as something you do after building features. That is wrong for this kind of project. the0 runs code. It builds code. It executes user-provided bots. It talks to Docker, Kubernetes, object storage, databases, and queues.

Security is not a garnish here. It is part of the product.

Local the0 Got More Serious

The local development path also changed a lot.

the0 local has become more important because self-hosted software needs a local story that is not miserable. Local Compose files, prebuilt versus source modes, service healthchecks, Docker group handling, generated environment files, and clean restart behavior all matter.

This is not just developer convenience. It is also how operators learn the system before running it somewhere more serious.

If local mode is flaky, the platform feels flaky.

The App Is Becoming App-First

The next major visible change is app-first auth.

The app is not a marketing site anymore. Marketing belongs on this site and in the docs. The app should open to the thing the operator or user needs:

• Fresh install: login, with the root admin created from deployment configuration.
• Existing install: login, with the configured root admin synced during API startup.
• Authenticated user: dashboard.

Open signup is going away. v1.14.0 introduces explicit admin roles, and operators configure the deployment-managed root admin with THE0_ADMIN_EMAIL and THE0_ADMIN_PASSWORD. The API fails startup if those values are missing or invalid.

That may feel less magical, but it is safer.

Self-hosted systems should not silently choose privileged users during an upgrade. The deployment should say who the root admin is, and password rotation should happen through the same deployment system that owns the environment.

This is the same product direction as the CLI work: less guesswork, fewer vague states, clearer ownership.

What This Means For Operators

If you run the0, the important takeaways are:

• Read upgrade notes before minor version upgrades.
• Expect the CLI to be the primary path for deploying and updating custom bots.
• Expect the app to focus on login, dashboard, inspection, and management.
• For app-first auth, plan your root admin configuration before upgrading.
• For Kubernetes, provide the root admin password through a Secret, not plaintext Helm values.
• For Docker Compose, refresh generated Compose files so the API receives both root admin variables.

Migration Guides

I added a dedicated migration guide for this because it is the kind of release where a short note is not enough:

• v1.14.0 Root Admin Migration

The exact docs will keep living in the docs site, but release posts should start pointing to operational changes instead of letting them hide in pull requests.

What This Means For The Blog

The old posts were big. I like them, but they take too much energy to make every time.

Going forward, I want a smaller public communication rhythm:

• Minor version release note.
• Operator upgrade note when behavior changes.
• Occasional architecture post when a decision deserves a deeper write-up.
• A bigger catch-up post only when the project actually needs one.

This is the reset.

There will probably be one more retrospective post that backfills the missing versions in a cleaner timeline. Not a novel. Just the public changelog the project should have had while I was mostly surviving and coding.

For now, the important thing is simple:

the0 is still here.

It is smaller in some places, stronger in others, and more honest about what it wants to be.