Moving a service needs more than a destination server
The easy part is drawing an arrow between two servers. The difficult part is knowing what must move, when the destination is truly serving users and what to do if the connection disappears halfway through.
Published 23 October 2026. Hostwatch engineering review; implementation limits are stated below.
Start with a service, not a container name
A website may consist of a public renderer, an API, a worker, a database, a cache and scheduled jobs. A container inventory describes how some of those pieces currently run. It does not establish the complete application boundary or tell you which data must remain consistent. Hostwatch’s Services view brings workspace services and their source servers together, with measured resource evidence where available. It also shows observed data services and persistent paths alongside operator-declared dependencies. That distinction is deliberate: finding a mounted directory is evidence of a mount, not proof of a complete migration plan.
For an operator, the first useful question is what makes this service work on this server. Identify the public route, runtime, architecture, image or release revision, data stores, uploads, secret references, timers and outbound dependencies. Mark which relationships were observed and which were explicitly declared. Preserve collection failures as partial coverage. A missing database edge must not become a confident statement that the service is stateless. The catalog should help assemble and review this context before anyone chooses a destination, especially when several services share a database, a proxy or a background queue.
A visible server is not automatically a safe destination
A server can be online and have free memory while still being unsuitable for a particular service. Check runtime support, CPU architecture, storage headroom, required connectivity and access to the necessary secret references. A successful image pull proves only that the image was fetched. It does not establish that its data is present, the database schema is compatible or the routing layer is under the operator’s control. Hostwatch exposes candidate destinations, but an executable move requires an operator-configured recipe for the particular source, destination and service. A node without that recipe remains visible with a blocker.
This is an important limit of the feature. Hostwatch does not infer a safe database transfer protocol from a container name, automatically install a general remote shell or promise that any service can move to any connected server. The published configuration example contains placeholders; it is not a production route. The current interface and journal support configured operations, while each real application needs its own transfer and recovery procedure. Treating an unavailable destination as an explicit preparation task is more useful than exposing a confident Move button whose implementation guesses at persistent data.
Turn the procedure into a fixed, reviewable recipe
An installed recipe binds the organization, source server, destination server and service to an operator-controlled executor. Hostwatch checks the executable’s pinned SHA-256 before its phases. API and MCP callers select the configured recipe; they cannot submit a new executable path, SSH key, environment value or arbitrary shell command. The executor receives a bounded operation document and returns structured checks and outcomes. Installation-specific credentials and remote allowlists remain with the operator. This gives the application team a place to define the real transfer protocol without turning an observational dashboard into an unrestricted execution endpoint.
The procedure must explain consistency, not just copying. A database may require a verified dump, a replication handoff or a brief write pause. Uploads may need an initial copy and a final synchronization. A worker may require draining or a guarantee that two consumers will not both perform the same external action. Secrets should be rebound using approved private references rather than printed into an operation log. The correct mechanism depends on the application. The recipe’s value is that these choices become inspectable prerequisites and repeatable phases, with an owner and a recovery plan.
Bind the preview to the deployment you inspected
A preview is a read-only inspection, not a reservation that makes the world stop changing. Hostwatch’s migration plan includes the observed source revision and a short validity window. Starting the operation requires that plan, its expected revision, an explicit confirmation and a stable idempotency key. Preflight checks the source again immediately before work. If a deployment changed after the operator read the preview, the operation should stop before copying an unexpected version. A stale plan is not a minor UI inconvenience when data layout or runtime requirements may have changed.
Readiness checks should cover both the destination and the recovery route. Confirm a usable recovery point, required dependencies, destination health verification, route ownership and the supported rollback period. Include free disk and memory requirements in the installed route configuration, but do not confuse a threshold with a complete capacity model. The destination also needs room for the temporary transfer and retained recovery material. If a check is unavailable, mark it unresolved. An operator should be able to explain why the move is allowed now, not merely point to a list of green server status badges.
Keep copying, health and user traffic as separate phases
The configured execution sequence rechecks preflight, creates a recovery point, synchronizes the bundle and data, verifies the destination, performs cutover, verifies the externally used route and only then retires the source. Each phase has a different proof obligation. A healthy process does not prove that the application can read its restored data. A healthy destination does not prove that users reach it. A DNS or proxy update being accepted does not prove that the expected route is active. The interface should name the current phase and preserve the completed checks so a mobile operator can follow the same evidence as the web console.
Retirement is particularly easy to do too early. Keep the source available according to the application’s protocol until route verification is complete. Define whether it must be read-only, paused or isolated during that period to avoid conflicting writes. Preserve the recovery point for the agreed retention window. The executor must make its phases idempotent for the same job identity, including the case where a timed-out invocation partially completed. A generic controller cannot supply these guarantees for an arbitrary database. It can require the procedure to express them and refuse to present an unverified step as a completed move.
A lost response is an unknown outcome, not a retry instruction
The operator’s network can disappear after a cutover has been applied but before its result is returned. If the next tap creates a new job, a second operation may race with the first. Hostwatch uses a durable journal and a stable idempotency key so repeating the same start returns the original job. An unresolved operation locks that service against another move. If the journal cannot be written, execution refuses to start. These are control-plane guarantees; the installed phase programs must still handle the application’s own partial effects correctly.
After a controller restart, a running operation becomes outcome_unknown and is not replayed automatically. A timeout or invalid phase result can produce the same unresolved state. This is intentionally different from a verified failure. The operator must inspect both servers, routing and the journal before requesting recovery. Automatically rolling back a cutover whose executor may still be running can create a second conflicting change. The interface should retain the operation identity and its last verified step, explain the uncertainty and provide the installed recovery path rather than offer a generic Retry button with a new key.
Make rollback a verified outcome with an honest name
A verified failure after preflight can invoke the configured rollback path. Its job is to restore the previous routing and service/data location, then verify that restoration. If that succeeds, Hostwatch reports rolled_back: the migration failed and the previous location was recovered. If recovery fails or cannot establish its result, the service remains unresolved. These labels matter. A cheerful success state for a rolled-back move would erase the original objective and leave the next operator guessing which server is actually authoritative.
Before installing a production recipe, rehearse its transfer and recovery in a controlled environment with representative data. Test the database consistency check, secret rebinding, cutover verification, controller restart and lost-response handling. Use the same plans and journal through the website, mobile app and MCP so a switch of interface does not create a new operation. Record which destinations and application revisions were tested. Services then becomes a useful operating surface: it shows where work runs, what it depends on and which moves are genuinely prepared. The arrow between servers is the summary of that evidence, not a substitute for it.
A service move is complete only after the destination, data and user-facing route are verified. A preview, accepted job or running container is an intermediate state, and an unknown outcome must remain unresolved.