announcement routing docker self-hosted

Working toward Routerly v0.2.0

Carlo Satta 5 min read

Work on Routerly v0.2.0 is in progress. This iteration is focused on five areas: semantic-intent routing, clearer version update visibility, a better path for development installs, a refreshed Docker build workflow, and general bug fixing.

This is not a release note. It is a progress update, based on what is already visible in the public Routerly repository and documentation today.

Semantic-intent routing

The largest functional addition in the current public codebase is the new semantic-intent routing policy.

It classifies the incoming request with embeddings, then narrows the candidate model pool before later scoring policies run. Each intent is defined by:

  • Example phrases that represent a category of request
  • A list of candidate models allowed to handle that category

The current implementation already documents three outcomes:

OutcomeConditionEffect
confidentHigh top score and clear margin over the second intentRestrict routing to the matched intent pool
ambiguousHigh top score but weak marginMerge the top two intent pools
unknownScore below thresholdPass all candidates through

The intent centroids are cached in memory for one hour, so the expensive part is not repeated for every request. In the benchmark work published today, the semantic-intent path is described as using text-embedding-3-small, with no LLM call on the routing path.

This matters because it moves part of Routerly’s intelligence from prompt-based routing to a deterministic, lower-cost classification step. For teams that have clearly separated workloads, for example coding, support, analytics, or general chat, this should make routing easier to reason about and cheaper to operate.

Version updates and dev installs

Another focus area for v0.2.0 is the experience around keeping Routerly up to date and trying newer code earlier.

The building blocks are already present in the public project:

  • The installer fetches the latest release when available
  • If the GitHub release API is unavailable, it falls back to the main branch source archive
  • Existing installations are detected automatically
  • The update flow already supports Update, Reinstall, and Uninstall
  • routerly status and GET /api/system/info expose the running version and service health

That means Routerly already has the core primitives needed for better version visibility and smoother upgrade workflows. The v0.2.0 cycle is where that path is being tightened up.

For development installs, the public docs already support multiple source-based paths:

  • Manual install from source with Node.js 20+ and npm 10+
  • Running the service directly in development mode from the monorepo
  • Building a local Docker image from a cloned branch

The goal for this cycle is not to invent a second product distribution. It is to make the current source-first and branch-first paths easier to use when testing work that is ahead of the latest stable tag.

Docker build improvements

Routerly already ships an official Docker image on Docker Hub for linux/amd64 and linux/arm64. The current Docker build also shows a clearer production baseline than the first public release:

  • Multi-stage build
  • npm ci with lockfile enforcement
  • Production install with --omit=dev
  • Non-root runtime user
  • Built-in health check on /health
  • Persistent data mounted through ROUTERLY_HOME=/data

There is also a documented path to build a custom image locally from source. That matters for contributors and for teams that want to test a local branch before a tag is cut.

In practical terms, the Docker work for v0.2.0 is about reducing friction between three modes that Routerly now supports in parallel: latest stable image, local source build, and development branch testing.

Bug fixing and stabilization

This release cycle is also a cleanup pass.

Routerly is still in active development, and the public repository says that explicitly in both the installer and the setup flow. The right interpretation of v0.2.0 is not “more features at any cost”. It is “make the next features operationally safer to use”.

The public code already shows that trend:

  • Docker and supply-chain hardening moved image builds to npm ci
  • The installer has dedicated Docker-based regression coverage
  • The update and reinstall flows preserve configuration and user data

That kind of work is less visible than a new routing policy, but it is what makes a self-hosted gateway usable outside a demo environment.

What stays the same

The fundamentals are not changing in v0.2.0.

Routerly remains a self-hosted gateway that is wire-compatible with the OpenAI and Anthropic APIs, stores its state on disk as JSON, and can run without an external database. The work in progress is aimed at making the routing smarter and the day-to-day operations cleaner, not at changing the core deployment model.

More details will follow when the version is tagged.

Sources

All articles