What a Better Registry Strategy Would Look Like for Voiceware

This is the decision I am examining: a production-oriented path from local-style image names to controlled artifact distribution.

Context

I used service-specific image repositories, but I had not built a full registry-promotion workflow into this first pass.

The decision mattered because Without a registry and promotion convention, teams can lose track of which artifact is approved for which environment.

Options I consider

Option A — keep the simplest current behavior. This minimizes moving parts and is often the right choice while proving a migration path.

Option B — introduce a stronger abstraction immediately. This can improve long-term consistency, but it also adds another system to debug before the underlying workload contract is stable.

Option C — keep the simple implementation, but make the boundary explicit and define the trigger for revisiting it. This is often my preferred migration posture.

Decision criteria

source -> image build -> registry identity -> Helm value -> node runtime pull -> container start

Why the Voiceware implementation is useful signal

The repository tells me what was actually chosen at that point in the project. It does not force me to argue that the choice is universal. Infrastructure decisions are contextual: an early test cluster, a production environment, and a multi-team platform may reasonably choose different levels of abstraction.

Trade-offs I would write into the ADR

The primary downside is the failure mode already identified: Without a registry and promotion convention, teams can lose track of which artifact is approved for which environment. The primary reason to keep the decision is the lesson: Use a trusted registry, immutable versions, provenance, and environment promotion rules as the deployment matures.

I would also record what would make me revisit the decision: traffic growth, stronger availability targets, additional environments, security constraints, release complexity, or operational pain that the current model can no longer absorb cheaply.

Revisit triggers

• Prefer immutable tags or digests for releases.
• Verify the node can pull the artifact.
• Do not pair mutable latest tags with assumptions about reproducibility.
• Promote the same built artifact across environments.
• Use an explicit registry/repository path.

A good infrastructure decision is not one that never changes. It is one whose assumptions are visible enough that the team knows when it should change. That is the kind of boring infrastructure I want: easy to explain, easy to inspect, and hard to misunderstand during an incident.