Choose a Bare Metal Server Provider: 15-Point Checklist

How to Choose a Bare Metal Server Provider: 15-Point Checklist

Choose a bare metal server provider by matching its hardware, network, support, and contract to your workload. Request written evidence, test the service, and compare the full cost. Remove offers that fail mandatory requirements. Keep unanswered questions open until the provider supplies enough proof.

A bare metal server gives one customer use of a physical machine. The provider’s service determines much of what happens around that machine: deployment, network access, hardware repair, support, and billing.

Two offers can list similar processors and memory yet leave you with very different operating duties and recovery options.

Our checklist connects each buying decision to something you can inspect. Apply the same checks to every supplier, including us.

Set Your Requirements Before Comparing Providers

Write a short requirements sheet before reviewing plans. Include:

• Application type and software dependencies.
• User locations and acceptable response times.
• Normal demand, peak demand, and expected growth.
• CPU, memory, usable storage, and network needs.
• Acceptable data loss and service recovery time.
• Tasks your team can manage.
• Budget, contract period, and launch date.

Make mandatory requirements clear. A database may need a specific restore target. A game server may need stable routes to player networks. A small team may need help with operating system maintenance.

Our rule is simple: a low price cannot make up for a failed mandatory requirement.

The 15-Point Bare Metal Provider Checklist

Check	Evidence to collect
1. Workload fit	Application test results
2. Hardware configuration	Exact component list
3. Storage	Usable capacity and disk test conditions
4. Location and routes	Measurements from relevant user networks
5. Bandwidth and transfer	Written limits and billing examples
6. DDoS protection	Coverage, restrictions, and response terms
7. Deployment and software	Delivery date, supported images, and licenses
8. Access and automation	Working console and required management tools
9. Hardware replacement	Covered parts and replacement timing
10. Uptime SLA	Measurement rules, exclusions, and remedies
11. Support	Task ownership and incident procedures
12. Backup and recovery	A successful application restore
13. Security and accountability	Relevant reports and data handling procedures
14. Growth and exit	Capacity plan and data export process
15. Cost and contract	Complete quote and renewal terms

1. Match the Server to Your Actual Workload

Start with the work the server must perform. A larger processor will not fix an application that waits on slow storage or a distant database.

Use measurements from your current system where possible. Record peak memory use, concurrent users, disk activity, and application response times. Include batch jobs and backups in the workload picture.

Ask the provider to explain the proposed configuration against those requirements. Then test a representative application workload with the same software settings and data size across shortlisted offers.

Accept the configuration once it meets your target and leaves enough spare capacity for expected growth. Set that margin from your workload. A fixed percentage does not suit every application.

2. Confirm the Exact CPU, RAM, and GPU Configuration

Request the processor model and generation, physical core count, thread count, memory capacity, and expansion limits. “Intel Xeon” or “AMD EPYC” alone leaves too much room for different configurations.

Check error-correcting memory, or ECC RAM, if your requirements call for it. For GPU workloads, confirm the GPU model, memory capacity, drivers, and application compatibility.

Separate physical cores from processing threads. Also check software licensing rules before paying for additional cores.

Ask whether the provider can substitute components and whether you can approve changes first. Compare the delivered hardware with the order during setup.

Keep the exact configuration in the written quote. A product family name cannot replace a component list.

3. Check Usable Storage and Sustained Disk Performance

Compare usable storage after the planned disk layout, filesystem overhead, and free-space allowance.

For example, two 1 TB drives in a mirrored RAID 1 configuration provide about 1 TB of nominal capacity before formatting. They do not provide 2 TB of usable mirrored storage.

Request drive details, endurance information, health monitoring, and replacement terms. Check how a failed drive and rebuild could affect application performance.

Disk benchmark results need context. Record the read/write mix, block size, dataset size, cache settings, test duration, and number of outstanding requests.

Run write tests only on approved test storage without production data. RAID can help with some drive failures, but it does not replace a separate backup.

4. Test the Location and Network Route

A location close to your users is a useful starting point. The actual network route still needs testing.

Request a test address in the proposed facility. A provider’s looking glass can also help you inspect routes from its network.

Measure application response time, network delay, packet loss, and changes across busy periods. Test from the networks your users depend on. Include routes to external databases, storage services, and other application dependencies.

A single ping result shows only a small part of the picture. Repeat measurements and compare them with application behavior.

Choose the location that meets your service target from relevant networks. The nearest city on a map may not provide the best route.

5. Read the Bandwidth and Transfer Terms

Keep these three terms separate:

Term	Meaning
Port speed	The link rate of the server’s network connection
Committed bandwidth	The throughput the provider commits to under stated terms
Transfer allowance	The volume of traffic included during a billing period

A 10 Gbps port does not establish 10 Gbps of sustained internet throughput. Other links, congestion, destinations, and application limits can affect results.

Ask about inbound and outbound billing, private network charges, overages, and traffic restrictions. Request invoice examples for normal use and a busy month. If the offer uses 95th-percentile billing, ask the provider to show the sampling and calculation method.

Unmetered describes a traffic billing arrangement. It does not, by itself, promise unlimited speed.

6. Check the Scope of DDoS Protection

Distributed denial-of-service protection, or DDoS protection, needs more detail than a check mark beside the plan.

Ask which attack types and protocols the service covers. Check detection time, filtering controls, added fees, and the procedure for reporting blocked legitimate traffic.

Separate the provider’s total filtering capacity from the protection available to your server. Ask whether the provider may blackhole an attacked address. Blackholing drops traffic to that address and can stop legitimate access as well.

For a game server, confirm coverage for the game’s actual traffic. For a website, distinguish network protection from application-level filtering.

Request written service limits and an approved test process. Never assume a large protection figure describes every customer’s service.

7. Verify Deployment Time, Operating Systems, and Licenses

Confirm delivery for the exact configuration and region you intend to order. Ready-stock servers and custom builds can follow different schedules.

Ask when the delivery clock starts, including any payment checks. Confirm when billing begins and whether setup or installation costs extra.

Check the supported operating system versions, custom image process, reinstall options, and driver support. If you plan to run a hypervisor, confirm compatibility and any provider restrictions.

Review licenses for Windows Server, database software, control panels, and other paid tools. Check whether the provider supplies them or expects you to bring suitable licenses.

Tie the delivery commitment to a usable configuration. Receiving login details is only one part of being ready to deploy.

8. Test Remote Access and Automation

Root or administrator access gives you control inside the operating system. You also need a recovery path if that operating system stops responding.

Check remote console access, power controls, rescue boot, and reinstall tools. A baseboard management controller, or BMC, provides separate hardware management functions. Ask how the provider protects access to it.

For repeated deployments, inspect the application programming interface, or API. Confirm supported actions, permissions, rate limits, and available automation tools. Check Terraform support if your team uses it.

Test the workflow your team needs, including access during a server problem. A working customer portal does not prove that every action has an API.

Buy the level of control your operations require. One manually managed server may not need a full automation platform.

9. Read the Hardware Repair and Replacement Terms

A support response and a completed repair are different events.

Request the written sequence for reporting a fault, diagnosing it, replacing the part, and returning the server to service. Ask when the replacement timer begins and which components the commitment covers.

Check local spare parts for the chosen facility. Confirm procedures for failed drives, memory, power supplies, and system boards. Assign responsibility for firmware updates and maintenance notices.

Also ask what happens after replacement. Your team may still need to reinstall software, rebuild storage, restore data, or check the application.

Compare the repair commitment with your recovery needs. A fast component swap does not guarantee that users can immediately access the service.

10. Read the Uptime SLA and Its Exclusions

A service-level agreement, or SLA, defines commitments for specified services. Read the covered service before comparing the percentage.

A network availability SLA may exclude operating system faults or application downtime. Check planned maintenance, measurement rules, claim deadlines, required evidence, and service credit limits.

For reference, a 30-day period contains 43,200 minutes:

Availability percentage	Corresponding unavailable time in 30 days
99.9%	43.2 minutes
99.99%	4.32 minutes

These figures show arithmetic before contract exclusions. They do not predict future outages.

Review incident history and the provider’s explanations of past failures. Service credits offer a contract remedy. They do not restore your application or replace a recovery plan.

11. Confirm Support Duties and Incident Handling

Ask the provider to define “managed” through specific tasks. Different plans can assign very different duties to the customer.

Use a responsibility table before signing:

Task	Details to confirm
ενημερώσεις λειτουργικού συστήματος	Owner, schedule, and reboot approval
Monitoring	Covered systems and response to alerts
Firewall changes	Owner and change request process
Backups	Schedule, retention, and failure handling
Recovery	Restore owner and application checks
Application support	Included software and limits

Check support hours, contact channels, incident priorities, and the route to a technical engineer. Separate first-response targets from repair or resolution commitments.

Submit a normal technical request during the trial. A quick sales reply cannot establish emergency support performance.

Leave no critical operating task without a named owner.

12. Prove the Backup and Recovery Process

Set two targets before reviewing backup plans:

• Recovery point objective, or RPO: the acceptable amount of data loss, measured in time.
• Recovery time objective, or RTO: the target time to restore service after disruption.

An RPO of one hour means the business aims to lose no more than one hour of data. An RTO of two hours sets a two-hour service recovery target. These are planning targets until a tested design supports them.

Check backup location, retention, encryption, access controls, deletion protection, and restore fees. Include the capacity needed to hold and recover the data.

Restore a representative backup and check the application. A successful backup job alone does not prove that the files are complete, usable, or quick enough to recover.

13. Check Security Evidence and Supplier Accountability

Identify the company that signs the contract and the organizations that operate the facility, hardware, and support service. Reseller arrangements need clear responsibility, especially during an incident.

Review account permissions, multifactor authentication, access logs, physical access procedures, incident notices, and encryption key ownership.

Request current security reports or certificates that cover the relevant organization, service, and site. Have your security reviewer check their scope and the controls your team must supply. Dedicated hardware alone does not establish application security or compliance.

Ask how the provider sanitizes drives before reuse and handles failed drives that cannot follow the normal process. NIST SP 800-88 Rev. 2 provides guidance for media sanitization programs.

Request evidence of the provider’s process. A reference to a standard is not evidence that the provider follows it.

14. Plan Capacity Growth, Migration, and Exit

Ask how the next upgrade would work. Extra memory may need downtime. A processor change may require another server. Additional machines depend on stock and delivery capacity.

Check IP address changes, migration help, data transfer costs, and availability in other regions.

For redundant systems, map shared failure points. Two servers in one facility may still depend on the same power system, network equipment, or site. Match the design to the failures your service must survive.

Plan your exit before you need it. Confirm data export, backup access, cancellation steps, service-change notices, and the time available to retrieve data after termination.

Test that you can move your data and configuration. Include any overlap period during which you must pay both providers.

15. Compare the Full Cost and Contract

Compare equivalent configurations, locations, included services, and contract periods. A lower server rental can leave more work and expense with your team.

Add recurring charges for software, IP addresses, transfer, backups, protection options, and support. Include setup, migration, internal administration, and applicable taxes.

For a chosen period, use:

Total cost = setup and migration + recurring service charges + internal operating costs + exit costs.

Estimate uncertain costs separately and state the assumptions. Do not mix a possible outage loss into the provider’s quoted invoice.

Read promotion expiry, renewal pricing, automatic renewal, cancellation notice, acceptable-use restrictions, and early termination fees.

Request one complete written quote. Keep each included feature, limit, and extra charge beside the configuration it applies to.

Compare Providers With Evidence Before Scores

Copy this table for each shortlisted provider. Add the actual requirement, proof location, reviewer, and date to each row.

Requirement	Mandatory?	Evidence	Result
Application performance target	Yes or no	Test record	Confirmed, unresolved, or failed
Hardware replacement deadline	Yes or no	Contract clause	Confirmed, unresolved, or failed
Recovery target	Yes or no	Restore record	Confirmed, unresolved, or failed
Required location	Yes or no	Order and site details	Confirmed, unresolved, or failed
Total cost limit	Yes or no	Complete quote	Confirmed, unresolved, or failed

Use “not applicable” for features the workload does not need. Keep an unanswered requirement unresolved rather than treating it as a pass.

Remove providers that fail mandatory checks unless your team formally changes the requirement. Score optional benefits only after the mandatory checks pass. Set any scoring weights before comparing results.

For example, a cheaper quote with an untested restore process remains unresolved if recovery is mandatory. A low price does not answer the recovery question.

Run a Trial Before Signing a Long Contract

Agree on the test scope, cost, duration, and cancellation terms first. Then follow a repeatable process:

1. Compare the delivered hardware with the quote.
2. Install the required software and representative data.
3. Test application performance and relevant network routes.
4. Check remote console access and the recovery workflow.
5. Restore a backup into a separate test environment.
6. Submit a technical support request.
7. Compare expected usage with the billing terms.

Keep software versions, settings, datasets, and test conditions consistent across providers. Record limitations alongside results.

A short trial can show configuration fit and operational problems. It cannot establish annual uptime or guarantee future support quality. Use the trial, contract, and documented service history as separate evidence.

Adjust the Checklist to Your Workload

Different workloads place different demands on a provider. Use these priorities to guide the review without skipping mandatory business requirements.

Workload	Main priorities	Useful test
Production database	Memory, storage latency, recovery, replacement	Representative queries and a timed restore
Game server	CPU behavior, player routes, DDoS coverage	Application test during busy player hours
Video delivery	Sustained throughput, routes, transfer costs	Approved transfer test and busy-month invoice
Virtualization host	CPU features, memory, storage, network controls	A representative mix of guest workloads
Small technical team	Management scope, support, recovery ownership	Responsibility review and support trial

We recommend setting application targets before choosing hardware or service tiers. This keeps the comparison tied to the work your business needs to complete.

Common Questions About Bare Metal Providers

Does bare metal hosting include server management?

The plan determines management duties. A provider may maintain physical hardware while your team handles the operating system, backups, and applications. Request a written task list. The terms “bare metal” and “dedicated server” do not, by themselves, define the management service.

Does a 100% uptime SLA mean the server cannot fail?

No. An SLA defines a service commitment and the remedy for a qualifying failure. Read its coverage, measurement rules, and exclusions. Hardware, networks, and applications can still fail. Design recovery around your business needs rather than relying on the percentage alone.

Can a provider guarantee the full network port speed?

A provider can commit to throughput under specified conditions. Confirm the measurement point and limits. A server’s port speed alone does not guarantee the same transfer rate to every internet destination, since routes, remote systems, and application behavior also affect performance.

Are backups part of a standard bare metal plan?

Inclusions vary by provider and plan. Confirm backup capacity, frequency, retention, location, and restore fees before ordering. Also establish who checks failed backup jobs and who restores the application. Treat any missing answer as an open requirement.

Can we upgrade a bare metal server without downtime?

Some changes may avoid downtime, but physical upgrades often require maintenance or migration. Ask about the exact component and procedure. Confirm expected interruption, data handling, rollback options, IP changes, and any charges before approving the upgrade.

Is a short trial enough to judge a provider?

A trial helps assess workload fit, access tools, recovery procedures, and support interactions. It cannot prove long-term reliability. Combine its results with written commitments, relevant security evidence, and service history before accepting a longer contract.

Use the Checklist to Request a Complete Quote

Bring your workload requirements into the quote process. Ask every provider to confirm the hardware, location, network terms, support duties, recovery options, and full cost in writing.

To assess our options, review Atal Networks bare metal server plans and send us your requirements. Ask us to address the same 15 checks before you place an order.

Choose the offer that meets your mandatory requirements with evidence your team can review.