Cloud or Private Enterprise: choose who operates the control plane
Hostwatch has two distribution models and one shared server agent. Understand the account subscription, the private installation license and the responsibilities that follow each operating choice.
Published 5 November 2026. Hostwatch engineering review; implementation limits are stated below.
Begin with the operating relationship
Choosing an infrastructure product involves more than deciding where to download a binary. Someone operates the central account system, stores the workspace state, manages access and keeps the control plane available. Someone also administers each monitored server and the applications running on it. These responsibilities may belong to different organizations. A clear deployment model names both sides before discussing features or price. Otherwise a team can buy a license expecting hosted operations, or install a public server component expecting it to include an independent management website. The resulting confusion appears later as an urgent access problem, an unplanned hosting task or a mistaken assumption about support.
Hostwatch has two distribution models. Cloud is the account-based service at gethostwatch.com, with operational access governed by a workspace subscription or applicable trial. Private Enterprise is the complete central website and API, delivered privately under an annual installation license. It does not require a separate Hostwatch Cloud subscription. The Go agent is the server component used with either model, rather than a third commercial edition. This article explains that product boundary and the operating decisions around it. The current deployment page, license and written customer agreement remain the references for the offer a customer actually purchases and the rights supplied with it.
Cloud keeps the central installation with Hostwatch
In Cloud, the customer signs into the hosted control plane and creates or joins a workspace. The server owner installs the Go agent on infrastructure they control and pairs it with that workspace. The hosted service coordinates permitted operations and receives the relevant telemetry. Installing the agent does not move the customer's application onto Hostwatch infrastructure, and enrollment does not automatically contribute the server to a shared compute network. These distinctions are practical. They determine where traffic travels, who can change the operating system and which credentials are required when a problem lies in the application rather than in the central management service.
Cloud plans use an allowance of enrolled servers. One enrolled machine consumes one slot even when it is offline; several services or containers on that machine share its slot. A new eligible workspace can begin with the stated seven-day trial for one server. The trial does not create an automatic charge. Paid Cloud access follows the subscription bound to the workspace, with the purchase and renewal terms shown in the purchasing surface. Before buying, confirm which workspace should receive the entitlement and which existing servers count toward its allowance. A container name, paired key or public IP is not proof that a Cloud subscription belongs to that workspace.
Private Enterprise moves the full installation to the customer
Private Enterprise supplies the compiled website, API and supported Linux agent installer packages through a private customer channel. The customer runs the central system on their infrastructure, under the licensed installation identity and approved HTTPS origin. Company workspaces, accounts and the fleet then belong to that installation. A private installation begins empty; it does not inherit Hostwatch's internal servers, customer workspaces or operational credentials. Its commercial entitlement is the installation license. A second Cloud subscription is not needed to make the privately supplied central application usable, which is an essential difference from simply pointing another agent at the hosted service.
The current standard offer describes an annual price of $1,490 for one complete installation, before applicable taxes and separate infrastructure costs. The license does not impose server, user or subscriber count quotas on that installation. This is a commercial capacity rule, not a performance guarantee: processors, memory, storage, network bandwidth and operational design still limit what the chosen hardware can support. Observation, detection and mitigation are included in the base private offer. A written agreement can define additional terms for a particular customer, so record the actual purchased scope rather than inferring an unlimited support service or availability promise from the absence of per-server license fees.
The same agent serves both models
The Go agent runs on a monitored server and exposes its configured observation and operation capabilities to the authorized control plane. It supplies host and workload evidence and performs explicitly permitted local work. Its enrollment key identifies a management connection; it is not the customer's commercial installation license. Keeping those credentials distinct makes incident recovery easier. Replacing a compromised agent key concerns one server relationship. Renewing a private installation license concerns the central software entitlement. Moving a Cloud subscription concerns the workspace purchase. None of these actions should be described as interchangeable ways to unlock every part of the product.
The public agent distribution makes installation accessible, but public availability does not make the software open-source. Its license grants the stated use with an entitled Cloud workspace or valid Private Enterprise installation, subject to those terms. Access to a repository is also different from permission to redistribute a private control plane or operate it for unrelated customers. Third-party components retain their own notices and rights; the delivered agent packages include the relevant license and third-party notice files. When documenting the product, use public distribution to describe access to the installer and proprietary licensing to describe the software rights, rather than allowing the word open to carry several conflicting meanings.
Decide who owns each operational duty
The infrastructure owner administers the monitored server. That includes authorized SSH access, operating-system maintenance, firewall rules, application code, runtime secrets, data retention and a recovery plan. A hosted control plane does not automatically become the administrator of every operating-system setting just because an agent is installed. Conversely, a private central installation places additional duties with its customer: maintain the website and API runtime, protect the control-plane state, configure the HTTPS origin, manage backups and schedule explicit software upgrades. Writing these duties down helps an on-call person choose the correct path when a certificate expires or a service cannot reach its database.
Some responsibilities cross the boundary and need a named handoff. Hostwatch can report a configured health failure and attempt a supported deployment restoration, while the application owner decides whether a database migration is compatible with that restoration. The product can display certificate evidence, while the domain administrator controls DNS and the certificate challenge route. An authorized assistant can upload a source change, while the code owner remains responsible for its rights, correctness and dependency policy. For a private customer, include the owner of the central session secret and installation license renewal in the same responsibility document. A vague statement that the platform handles everything makes these handoffs harder during an incident.
Connect clients to the intended installation
The web console uses the chosen control-plane origin. The native iPhone and iPad client signs into that installation, using gethostwatch.com for Cloud or the origin supplied by a private administrator. Authorized MCP clients use the installation's remote endpoint and its account authorization flow. This keeps workspace membership and entitlement attached to the system the customer selected. It also prevents a common support mistake: debugging an empty hosted account when the user's real servers belong to a private installation. Confirm the origin and workspace before generating a pairing command, reviewing a plan or interpreting a server list that appears unexpectedly empty.
Shared product language helps clients remain consistent without pretending that every surface has identical controls. Services should identify the same server placements, and Plan & license should explain the commercial model clearly. Source-file inspection and release operations are available through MCP where operator profiles enable them; that does not imply a native source editor exists. Private customers should also read the current client limitations. For example, a complete privately hosted website does not automatically register mobile associated domains for every customer hostname. The connection guide should explain what the shipped client supports today, with advanced setup and recovery paths for environments outside the simplest installation flow.
Treat telemetry, code and secrets as separate data classes
A monitoring relationship sends useful operational evidence to a control plane, and the chosen deployment model determines who operates that destination. Review the telemetry and retention settings against the customer's actual needs. Source-release operations add another data class: uploaded source archives and build diagnostics. A build log can contain application information even when it is not intended to contain secrets. An authorized MCP client may process source and operational responses as part of the user's request. Account administrators should understand that path and the client's own handling of the information, rather than assuming every assistant tool response stays on the monitored server.
Private deployment changes where the central application runs, but careful secret handling remains necessary. Keep application environment values, signing keys and private certificates outside source archives. The customer package contains a verification public key rather than the publisher's license-signing private key. Back up the private installation's state and protected environment configuration through an appropriate customer-controlled channel. Losing the session secret can make stored encrypted credentials unrecoverable even when the state file still exists. Describe these dependencies in the recovery guide. A license without server-count quotas cannot restore a lost encryption key, recover an untested backup or replace an organization's decision about access to operational data.
Installation simplicity needs honest prerequisites
The quick agent path reduces setup to naming the server, generating a temporary command for a dedicated DNS hostname, running it through authorized SSH access and verifying the resulting connection. It supports the documented Ubuntu or Debian systemd environment and Linux architecture. DNS and the required HTTP and HTTPS reachability must already make sense for the chosen certificate and proxy setup. Existing agents and conflicting proxy configuration require the advanced path instead of blind replacement. These prerequisites belong beside the command, because simplicity is useful only when the person running it can understand which server and network arrangement the installer expects.
Private control-plane installation also has an explicit sequence: obtain the authenticated customer package, verify its checksums, prepare the installation origin and identity, start the supplied runtime behind a trusted TLS reverse proxy, and activate the signed license. Keep the package outside a public web root. The customer remains responsible for the host and domain used for that central service. The included agent installers then use the same guided pairing model from the private console. Neither distribution installs a CI/CD pipeline, Git-triggered deployment or background software updater. Application releases remain deliberate actions, while certificate renewal and configured backup maintenance can run on their own operational schedules.
Renewal and upgrades should preserve the installation identity
A private license is issued for the installation identity and approved origin. Protect those values as part of the system's operational record. A domain change may require a reissued signed license, and copying a live identity to a second installation is not a substitute for obtaining the rights and configuration that second installation needs. Plan renewal before the expiry window becomes an incident. The product retains activation and recovery access according to its documented license behavior, but an organization should not rely on a grace period as its normal renewal process. Keep the commercial contact and the operational administrator connected through a clear internal procedure.
For software upgrades, retain the state, environment secret, instance identity and previous application image. Stop incompatible writers when the release requires it, verify the new package through the authenticated channel and apply the change explicitly. A container restart policy is useful for keeping an existing process running; it is not permission to replace the application with whatever happens to be newest. Review application-specific data changes independently of the commercial renewal. Cloud customers have a different central operations boundary, yet still need deliberate upgrades for their own agents and workloads. The shared principle is to preserve a verifiable relationship between the installed software, entitlement and the state it must continue to read.
Choose the model your team can operate well
Cloud is a useful fit when a team wants Hostwatch to operate the central account and management service while the team continues to own its application servers. Private Enterprise is useful when the customer needs the complete central installation under its own infrastructure and operating control. The decision should include staffing, recovery ownership, data handling, domain administration and the desired commercial relationship. Counting servers alone can hide the cost of running the private control plane responsibly. Equally, choosing hosted management does not transfer ownership of the customer's application, database or network provider. Make the boundary explicit in the purchasing decision and the operational guide that follows it.
A good final check is to ask a new administrator to describe the setup in a few sentences. They should be able to name the control-plane origin, workspace owner, commercial entitlement, enrolled servers, backup responsibility and release procedure. They should know that the agent is shared by both distribution models, that the private full installation needs no additional Cloud subscription and that public installation does not grant redistribution rights. If that explanation is difficult, improve the guide before adding another plan label or installer option. Clear operating relationships make a product easier to adopt and leave fewer assumptions for the person handling the next certificate, renewal, deployment or recovery incident.
Cloud uses the account and workspace subscription or trial. Private Enterprise supplies the complete central installation under an annual license without a separate Cloud subscription. The same Go agent serves both.