Service placement is the starting point of a trustworthy release
Find the server and component before changing a release. A useful placement record connects approved source, publication, the serving image and the evidence needed to verify the result.
Published 5 November 2026. Hostwatch engineering review; implementation limits are stated below.
A service name needs a physical destination
The question “where does this application run?” sounds simple until a team has several servers, a hosted frontend, an old deployment and a separate background component. A domain is useful evidence, but it does not describe every process behind the application. A public address may lead through a proxy. A stopped container may still appear in retained observations. A familiar project name may belong to two installations. Before changing a release, an operator needs a destination that identifies the workspace, server, runtime and component together. Otherwise a technically successful operation can update the wrong thing while the intended application continues serving its previous version.
Hostwatch starts this investigation with the fleet and service inventory. Through MCP, the assistant searches the operation catalog, reads servers and uses service_locations to find the application by name, domain or server. The result can contain several placements, and every placement matters. Preserve their timestamps and availability states instead of choosing the first recognizable row. An offline server is unresolved evidence, not proof that its workload disappeared. If a component has no configured release target, that limitation remains visible. Discovery should make the next action specific enough to review, rather than turn a convenient application label into permission to operate an entire machine.
Public ingress and agent control are different addresses
A website address tells a browser how to reach the product. An agent control address tells the authorized control plane how to inspect and coordinate a server. They can use different hostnames, ports and network paths. An internal container port is a third address, and a registry endpoint is a fourth. Treating these as interchangeable causes surprisingly persistent mistakes: a successful agent health request gets reported as a working public website, or a correct application response hides a broken management connection. Record the purpose of each address. Then choose a check that tests that purpose through the same route a real caller would use.
For a migrated service, public verification includes authoritative DNS, the address family clients use, the expected certificate and a representative application request. Local verification includes the selected runtime and its configured health endpoint. Management verification includes the enrolled server identity and a recent response from the agent. Those observations support one another without replacing one another. DNS caches can keep an old address in use after an authoritative record changes, so an old origin may still need a deliberate transition policy. Hostwatch service placement provides the operational context; the infrastructure owner remains responsible for the DNS and proxy configuration that makes the intended public destination reachable.
Components deserve independent release boundaries
One product can contain a website, an MCP endpoint, a worker and a scheduled maintenance task. These components may share branding and some data, yet have different commands, dependencies and recovery requirements. A small website correction should not silently restart the separate assistant endpoint. A new worker may require coordination with a database even when the public frontend is unchanged. Naming each component in its release profile makes the scope concrete. The review can then say which process changes, which siblings remain in their current state and which compatibility assumptions need a separate check before the operator applies the update.
An operator-installed Hostwatch target fixes the source image, registry destination, container configuration, protected environment reference, persistent mounts and health check. The MCP caller selects that target rather than supplying a new host path or arbitrary command. This arrangement keeps routine work compact while preserving the administrator's decisions about the server. If a component needs a new port, different data mount or changed runtime identity, update its trusted profile through the operator workflow first. An assistant should report a missing capability as a configuration requirement. Inventing a shell command to work around the profile would discard the very release boundary that made the operation understandable.
Source, image and deployment carry separate identities
An approved source tree describes the files a recipe will build. A built image packages the runtime result. A running container identifies what is serving now. A registry tag provides a convenient publication name that can move to another image. These are related identities, with different evidence behind them. Docker's image documentation explains that an image is immutable; changing an application creates another image. The useful release question is therefore which immutable result a stage references at the moment of review. A memorable tag such as current cannot answer that question by itself, especially when another operator is working on the same component.
Hostwatch exposes the source, staged and deployed image identities separately where source builds are configured. Read them together before interpreting a success message. A completed build proves that a particular recipe produced a staged image. A completed registry publication proves that the configured destination accepted the publication. A completed deployment with a passing check establishes more about the live process, but still needs a user-facing verification appropriate to the application. Keep the receipts for each stage. They let a later investigation distinguish “we prepared the fix” from “we applied the fix” without relying on memory, a local repository branch or the latest tag name.
Preview the exact state you intend to change
Production work often involves concurrency even in a small team. Another person can publish an image while an assistant is reading the inventory. An emergency fix can replace a container during a longer build. Hostwatch previews therefore return concrete digests and revisions that the subsequent operation must match. The caller carries those values into the change request. If the state moves, a stale request should fail instead of applying an assumption from several minutes earlier. This is especially useful when an assistant has several tool calls between discovery and application: readable prose is not a substitute for checking the actual state at the action boundary.
Use a fresh publication preview before changing a registry tag, and supply its published digest when an existing tag is updated or replaced. Use a fresh deployment preview before recreating the component, and carry both its source digest and deployment revision into that request. A refusal caused by changed state is useful information. Re-read the component and decide whether the original intent still applies. Do not solve the refusal by repeatedly generating new operation keys against old evidence. A release should preserve the relationship between the reviewed state, the requested action and the recorded result, even when several operators share responsibility for the same server.
Build explicitly, then decide whether to apply
Source updates in Hostwatch are explicit operations. An owner can inspect approved files, upload a bounded archive, preview the proposed source and ask the installed recipe to build it. The recipe has resource and network limits supplied by the operator. A successful build stages an image and records the resulting source revision. It does not replace the live container. That separation gives the operator a useful pause: inspect the result, read diagnostics, compare scope and decide whether this is the release to publish and apply. A source upload alone is merely preparation, regardless of how confidently an assistant describes the intended change.
This workflow installs no CI/CD pipeline, repository watcher or background software updater. A Git push is a source-control action; it does not become an instruction to change the server. Publication and deployment each need their own named operation. Certificate renewal and an explicitly configured backup schedule serve different operational purposes and can continue without creating automatic application releases. Teams should describe that distinction clearly in their runbook. “Manual release” means the software change is deliberately invoked through the supported controls. It does not require abandoning scheduled certificate maintenance, nor does it excuse skipping a review of the exact component and image being applied.
Persistent data belongs in the release plan
Recreating a container can preserve configured volumes and bind mounts, yet application compatibility still needs attention. A new binary can interpret an old database differently. A process running under a different user can lose access to an otherwise intact directory. A generated cache can fail on a read-only root filesystem even when the main page renders once. Docker documents volumes as persistent storage with a lifecycle separate from an individual container. That useful storage property does not establish that a backup is consistent, that the new application can read it, or that returning to an older binary will reverse a schema change.
Before applying a release, identify the durable data, current writer and compatibility boundary. Check backup freshness and a restore method suitable for that store. For a website with account data, include a harmless representative read or isolated test rather than writing fabricated production accounts. For a component with generated assets or caches, verify the intended writable locations and runtime user. Keep test fixtures away from the live data paths. A successful isolated deployment is valuable evidence about the recipe and runtime, while the final production decision still needs the application's own data and compatibility review. These are distinct parts of one release, not reasons to trust only the container health endpoint.
Verify siblings and actual user routes
A narrow component update should be verified against its narrow intent. After updating a website, inspect the serving image and test its important public routes. Then check the separate MCP or worker component that shares the product, particularly if shared dependencies or resources could affect it. A small server can experience memory pressure during a build even when only one container is recreated. Read current host evidence and application logs around the operation window. A clean build transcript cannot establish that a sibling remained responsive, and an isolated health response cannot establish that a customer can complete the product flow that motivated the update.
Choose a small set of meaningful checks rather than a long list of redundant requests. A public homepage, a relevant API route, the configured health endpoint and a data preservation check can establish different facts. Save the observed image identity and timestamps beside their results. If a route intentionally requires authentication, use the authorized verification method and keep private credentials out of the receipt. When evidence is unavailable, say what remains unverified. The final report should explain the behavior observed after application and any remaining limitation. This makes the receipt useful to the next operator instead of turning it into a decorative collection of successful status codes.
Operation keys make retries understandable
Network failures create ambiguity at exactly the wrong moment. An assistant can send a deployment request and lose its connection before receiving the response. Issuing another change with a new key may recreate a component twice. Hostwatch uses stable operation keys so the caller can ask about the original operation and distinguish a retry from a new intent. Poll image_publish_status using the key associated with the selected node. Terminal states carry different meanings: a successful release, a failed preparation and an attempted deployment that rolled back should never be flattened into a generic completed label in the assistant's final message.
An agent restart can leave an operation's outcome uncertain. Investigate the runtime and retained evidence before deciding what recovery requires. Do not treat uncertainty as permission to repeat the change automatically. Operation history and source retention are bounded, so the owner also needs an explicit cleanup routine. Archive completed receipts, discard eligible superseded source trees and forget old receipts only when appropriate. Forgetting removes the old idempotency record permanently; never reuse that key afterward. Keeping the active and deployed source protected makes cleanup practical without quietly deleting the material needed to understand the current release. History maintenance should preserve clarity rather than maximize the number of operations retained forever.
Make the handoff useful to another operator
A release handoff should answer a few concrete questions in connected language. Name the workspace, server and component. Explain what changed in the application and why. Identify the source revision, immutable built result, published destination and serving image where those stages were used. Include the meaningful verification and the data or compatibility limits. Record whether a failed attempt restored the previous deployment. A teammate should be able to assess the result without reading the entire assistant conversation, copying a hidden local path or assuming that the newest repository commit matches the public runtime. The evidence should support the claim actually being made.
Hostwatch provides the same placement and operation context to its website, native client and authorized MCP assistants, while individual controls can differ by surface. Source-file release operations belong to MCP rather than an invented native editor. Cloud access uses the workspace subscription or applicable trial. A privately licensed complete installation uses its annual installation license without a separate Cloud subscription. Neither commercial model removes the owner's responsibility for authorized code, server administration, secrets, backups and recovery decisions. Clear service placement makes those decisions easier to carry out. The useful result is an application whose running state and release history can be explained precisely to the person who operates it next.
Identify the exact server and component, preserve the revision reviewed at each stage, and verify the image and application behavior actually serving after the change.