Choose a dedicated server by matching the workload to the actual hardware and assigning responsibility for operation, access and recovery. Start with a capacity brief and a responsibility sheet, then inspect the provider’s product-specific documentation. A server specification is only useful when the team can explain how it will monitor, maintain and recover the application running on it.
The first question is what the workload needs to do. Describe the application, its data, its busiest relevant activity and the operational knowledge available to support it. Keep known measurements separate from estimates. This makes the hardware discussion concrete without inventing a universal memory, processor or storage threshold for every business.
The worked example below concerns a hypothetical internal business application. The factual examples come from Hetzner’s own bare-metal overview and technical measures, retrieved on 24 October 2026. They illustrate one provider’s documented responsibilities, while hosting and web development remain the broader service discussions.
Which hardware evidence should inform the decision?
Hetzner directs customers to current model specifications for hardware details. Its bare-metal overview provides a starting point for locating those details. Retain the particular proposed model and specification source with the decision record, rather than treating a provider’s general product name as a complete capacity description.
Hetzner exposes basic auction-server specifications through Robot’s Hardware tab. If that is the product being assessed, use the corresponding server record. An older or individually offered configuration deserves its own specification check, especially where the decision depends on a particular drive arrangement or memory configuration.
Hetzner offers drive and RAM upgrades only for certain models. Treat future expansion as a product-specific question. Write the proposed growth scenario and ask which documented upgrade route applies to the exact model. Avoid turning a general upgrade statement into an assumption that every component can be expanded on demand.
For the hypothetical application, prepare an inventory of data volumes, relevant usage observations and the tasks that create the greatest load. If measurements are missing, name the test needed to obtain them. A clear unanswered question is more useful than an apparently precise specification derived from a guessed number of users.
Who operates an unmanaged dedicated server?
Hetzner assigns hardware monitoring responsibility to the client. Hetzner offers a System Monitor tool that can be activated through Robot. These documented points separate the availability of a monitoring mechanism from the responsibility to configure and respond to it. Identify who receives alerts, who interprets them and who can open a hardware-support request.
Hetzner gives customers root access to its unmanaged server. Hetzner says application installation is generally the customer’s responsibility. Decide who maintains the operating system and application, reviews changes and keeps access under control. Include the ordinary maintenance work in the assessment instead of discussing only the initial installation.
Hetzner supports custom operating-system installation through a KVM console and ISO. This is a documented installation route to assess where the workload needs a particular image. Ask the implementer to identify the supported procedure and its implications for the proposed system, including how configuration and application data will be retained separately from installation media.
| Responsibility area | Evidence to request | Decision to record |
|---|---|---|
| Capacity | Exact model and workload observations | Why the proposed hardware fits the workload |
| Expansion | Model-specific upgrade documentation | Which growth assumptions are supported |
| Monitoring | Configured signals and response route | Who investigates hardware or application alerts |
| Administration | Operating-system and application scope | Who maintains each layer |
| Access | Account ownership and authorised roles | Who may operate the server and management panel |
| Recovery | Separate backup and restore exercise | Who restores service and what evidence is retained |
The sheet is an original selection aid. Complete it against the actual proposed product and the responsibilities the business is prepared to accept.
What does isolation mean for the application owner?
Hetzner’s technical measures make dedicated-server management, maintenance and security the client’s responsibility. Its technical measures distinguish unmanaged and managed products. Keep that product distinction visible when comparing offers; a physical server and a managed application service are different operating arrangements.
Hetzner says the client controls access to its dedicated server. Identify the application and administration boundaries that your own design needs within that server. If several applications share it, write down their accounts, data locations and authorised operators. The proposed separation between those applications should be reviewed as a design requirement, rather than inferred from the dedicated hardware label.
Include management-panel ownership in the responsibility discussion. The person who can open a support request may need different authority from the person who operates the application. Agree a practical handover route and retain the relevant records privately so an incident does not depend on one colleague remembering which account owns the server.
How should recovery readiness be demonstrated?
Begin with the business service that needs to return, not merely the machine. List the application, configuration, data and dependencies needed for a useful recovery. Define the evidence that would show the restored service can perform its intended task. This turns recovery into an assessable exercise rather than a claim based on the presence of a backup file.
For the hypothetical internal application, propose restoring an approved fictional dataset into a separate environment. Have the application owner identify a representative record and workflow to check after restoration. Record the environment, backup version, steps taken and observed result when the exercise is performed.
Keep hardware replacement and application recovery as separate work items. A repaired component still leaves questions about software state, data and validation. Assign those responsibilities explicitly so the business can assess whether the proposed operating arrangement matches the support capability available to it.
Original capacity-and-ownership decision sheet
Write a short workload statement, then attach the exact model specification and the observations used to assess it. Mark every estimated input as an estimate and identify the measurement needed where the decision depends on it. Record a capacity concern as a test question with an owner, rather than adding unsupported hardware limits to the brief.
Next, complete the responsibility table with named roles and the evidence each needs. Ask the person responsible for monitoring to explain the response route, and ask the recovery owner to describe the separate restore exercise. Resolve any gap between what the provider documents and what the business expects before treating the proposal as complete.
Use the completed sheet to compare capacity, operating effort and unresolved work together. For domain dependencies, see domains. To discuss the workload and the responsibilities still needing evidence, get started with the decision sheet and its supporting observations.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.