Managed vs Unmanaged Dedicated Servers (2026 Buyer’s Guide)

In 2026, a dedicated server gives you exclusive CPU and RAM, and usually local storage, on a single physical machine. You still share the provider’s network edge and backbone, but you get a defined port speed and bandwidth plan. 

The real decision is operational ownership: who patches the OS, watches alerts at 3 a.m., and restores service when something breaks. 

Managed vs unmanaged dedicated servers come down to control versus coverage. 

Managed plans cut risk by handling OS patching and baseline monitoring, and sometimes backups if they are in scope. 

Unmanaged plans keep costs lower and flexibility higher, but your team owns security hardening, monitoring, and incident response. 

This guide helps you pick fast using a simple TCO check, a clear RACI split, and an SLA checklist, then migrate with steps that avoid downtime surprises.

Key Takeaways

• If you lack a sysadmin or 24/7 coverage, choose managed.
• If you have strong skills and want full control, choose unmanaged.
• If you want OS help but keep app control, choose co-managed.
• Managed lowers outage risk. Unmanaged lowers the server fee.
• TCO per month = server fee + licenses + (ops hours × rate) + (annual incident cost ÷ 12).
• On managed, the provider patches and monitors the OS. You own apps and data.
• Check SLAs: network uptime, credit ladder, hardware swap time, response times, and maintenance notice.
• Use 3-2-1 backups. Encrypt them. Test restores every quarter. Set RPO and RTO.
• Tune BIOS, kernel, storage, and DB. Prove gains with load tests.
• Pick port speed and bandwidth model. Add L7/WAF if your app needs it.
• Avoid lock-in: keep root, use standard formats, bring your own DNS and monitoring.
• Decision rule: two “managed” needs → managed. Three “unmanaged” needs → unmanaged. Else start co-managed.

Core Concepts

Managed Dedicated Servers

Your provider builds and hardens the server, installs the OS, applies patches, and sets baseline security. On higher tiers, they watch the server 24/7, run backups, and respond to incidents under an SLA. Always confirm what your plan includes. 

You own code, data, and app settings; the team handles the plumbing that keeps it stable. Pick this path if uptime risk is real, compliance matters, or your team is lean.

Unmanaged Dedicated Server

The provider images the OS (or you do), then you lock it down, patch it, and run monitoring. You design backups, test restores, and carry the pager. You get full root and full freedom to run any stack or control panel. 

Choose this if you have real admin skills, want custom builds, and need to stretch the budget without adding vendor-managed services.

Managed vs Unmanaged Dedicated Servers: Full Comparison

You’ve got the core ideas. Now let’s compare the managed vs unmanaged dedicated server models across the parts that decide outcomes. 

Operations & Governance

Set the ground rules for who does what, when, and how. Good ops cuts risk before security tools ever fire.

Managed

• Provisioning: Provider images the server, validates firmware, and ships a hardened base OS.
• Rebuilds: Fast re-images on request with preserved configs or snapshots.
• Patching cadence: Scheduled OS/kernel updates with maintenance windows and rollback plans.
• Configuration control: Standardized baselines, change tickets, and drift checks.
• Access management: Role-based access, MFA, and credential rotation policies.
• Runbooks: Documented steps for common actions (reboots, storage growth, log rotation).
• Escalation paths: Clear SLOs from first response to senior engineer handoff.
• Capacity planning: Guidance on CPU, RAM, NVMe, and bandwidth headroom.
• Decommissioning: Data wipe, cert/key retirement, and audit logs.

Unmanaged

• Provisioning: You choose the OS image, file systems, and packages (the provider may image the OS).
• Rebuilds: You maintain images and automation for clean redeploys.
• Patching cadence: You plan windows, test updates, and handle rollbacks.
• Configuration control: Use IaC (Ansible/Terraform) to prevent drift.
• Access management: You enforce SSH keys, MFA, and least privilege.
• Runbooks: You write, test, and keep them current.
• Escalation paths: Your on-call ladder and response targets.
• Capacity planning: Your forecasts, alerts, and upgrade timing.
• Decommissioning: Your wipe, key retirement, and proof of destruction.

Co-managed note: Provider handles OS patching and baseline monitoring. You keep control of apps, containers, and deploys. This reduces toil without giving up stack choices.

Security Responsibilities

Security lives on top of ops. Decide who owns each control so gaps don’t appear during a busy release.

Managed

• Baseline hardening: SSH keys only, firewall rules, minimal services, kernel params.
• Patch response: Regular cadence plus fast paths for critical CVEs.
• Network defense: Edge L3/L4 DDoS is often included; L7/WAF is typically an add-on or higher-tier feature. Confirm limits and thresholds.
• Vulnerability management: Scheduled scans, reports, and tracked remediation.
• Endpoint controls: IDS/IPS or EDR, where offered; alert routing to on-call.
• Access controls: RBAC, MFA, and privileged session auditing; key rotation guidance.
• Certificates & TLS: Issue, renew, and deploy certs; enforce strong ciphers/HSTS when in scope.
• Encryption: Disk or volume encryption where supported; documented key custody.
• Backups security: Encrypted at rest and in transit, with restricted restore access.
• Logs & time: Centralized logs, retention policy, and NTP sync for audit integrity.
• Compliance help: DPAs/BAAs where available, evidence packs, and control mappings.
• Incident handling: Triage, containment, and comms per SLA; post-incident review.

Unmanaged

• Baseline hardening: You design SSH, firewall, and kernel posture.
• Patch response: You watch advisories and patch on your timeline.
• Network defense: Provider shields L3/L4; you build WAF/L7 rules and rate limits.
• Vulnerability management: You run scans, parse findings, and close items.
• Endpoint controls: You deploy IDS/IPS or EDR and tune noise vs signal.
• Access controls: You manage RBAC, MFA, PAM, and key rotation.
• Certificates & TLS: You handle PKI, renewals, and cipher policy.
• Encryption: You choose disk/volume encryption and manage keys.
• Backups security: You encrypt, store off-server, and restrict restores.
• Logs & time: You centralize logs, set retention, and enforce clock sync.
• Compliance: You own policy, training, and audit responses.
• Incident handling: You triage, contain, and run forensics.

Co-managed note: Expect provider control of the OS layer (hardening, patches). You still own application secrets, WAF rules, and data model risks.

Monitoring, Alerting, and Incident Response

Security works only if you see trouble early. Monitoring is the link between your ops and the controls you set in the last section. Next, we’ll use these signals to drive backup and recovery plans.

Managed

• Coverage: Host checks, service checks, port probes, and synthetic HTTP tests.
• Metrics: CPU, RAM, disk I/O, filesystem, NIC, p95 latency, error rate, queue depth.
• Logs: Central syslog at minimum; app logs on higher tiers. Clear retention (30-90 days).
• Alert routing: Phone, SMS, and push with on-call rotation managed by the provider.
• Runbooks: One playbook per alert. Include steps, owners, and rollback.
• SLOs: Acknowledge and resolve targets by severity (Sev 1, Sev 2, Sev 3).
• Escalation: Timed handoffs to senior engineers. The ticket states you can track.
• Status: Maintenance mode, public status page, and monthly incident reports.
• Metrics of success: MTTA and MTTR tracked and shared after each event.

Unmanaged

• Tooling: Pick a stack (Prometheus + Alertmanager + Grafana, or ELK/Loki + Uptime checks).
• Signals: Define the “golden signals” per app: latency, traffic, errors, and saturation.
• Thresholds: Set pages on user impact, not just CPU spikes.
• On-call: Build a fair rotation with clear handoffs and no-page windows for maintenance.
• Runbooks: Keep them short and current. Link them in the alert message.
• Comms: Draft incident templates for users and stakeholders before you need them.
• Reviews: Run blameless postmortems. Assign owners and due dates for fixes.

Backups and Disaster Recovery

Monitoring tells you when things break. Backups and DR decide how much you lose and how fast you bounce back.

Managed

• Policy: Common patterns include daily incrementals plus weekly fulls, with a defined retention window (varies by plan).
• Scope: Filesystem and database-aware jobs; point-in-time for major engines.
• Storage: Off-server or off-region options. Object storage with versioning on request.
• Security: Encryption at rest and in transit. Limited restore access.
• Immutability: Object lock or immutability on higher tiers.
• Testing: Scheduled restore drills. Evidence is shared after each test.
• DR plan: Who declares, who executes, target RPO and RTO, and a cutover checklist.
• Failure handling: Alerts on missed jobs, low space, or checksum errors.
• Costs: Clear pricing for storage, egress, and emergency restores.

Unmanaged

• Rule: Follow 3-2-1. Three copies, two media, one off-site.
• Database safety: Use app-consistent backups and pre/post hooks.
• Storage: Use object storage with versioning and lifecycle policies.
• Keys: Encrypt with a KMS. Rotate and test recovery with a staged key.
• Restores: Run quarterly drills. Take the steps. Log who did what.
• Targets: Set RPO and RTO per app. Publish them.
• Snapshots vs backups: Snapshots are fast. Backups are safer. Use both.
• Runbooks: Step-by-step guides for file, DB, and full-host recovery.
• DR site: Define a cold, warm, or hot path. Rehearse the cutover.

With recovery covered, you can judge the promises in the fine print.

Reliability and SLAs

SLAs define what “reliable” means on paper. Your job is to match those promises to your risk and your stack. After this, we move into stack tuning and network choices.

Managed

• Network uptime: A target plus a credit ladder. Know how credits apply and how to claim.
• Power: Dual feeds, UPS, and generator tests on a schedule.
• Hardware: Replacement targets and onsite spares. Include NICs, PSUs, and disks.
• Response: Timed SLOs for acknowledge, action, and escalation by severity.
• Maintenance: Notice periods, windows, and status page updates.
• Packet loss/latency: Some providers publish targets. Ask for them.
• Measurement: Who measures and from where. External probes beat internal views.
• Exclusions: DDoS carve-outs, acts of nature, and customer errors. Read them.
• Credits: Caps, time to credit, and claim steps. Put a reminder on your calendar.

Unmanaged

• What carries over: Network and power targets still apply. Hardware help still exists.
• What does not: No promise for your OS, services, or apps. That is on you.
• Windows: You schedule freezes and plan change windows.
• Proof: Run external uptime checks and save reports.
• Status: Publish your own status page and incident notes.

Uptime Math (Per Year)

• 99.9%: 8h 45m
• 99.99%: 52m 34s
• 99.999%: 5m 15s

You now have eyes on the system, a safety net for data, and clear promises from the vendor. 

Performance and Stack Tuning

You set the uptime bar with SLAs. Now make the server fast under real load. After this, we’ll lock the network and DDoS posture.

Managed

• BIOS/CPU: Performance power profile, SMT/HT policy by workload, C-states/P-states tuned, NUMA awareness.
• IRQ/NIC: IRQ pinning, RSS/RPS, GRO/LRO, offload settings, MTU choice per link.
• Kernel/TCP: Reuse/fin, backlog, buffers, window scaling, TCP Fast Open, BBR/CUBIC by test.
• Storage: NVMe first for I/O bound apps; RAID1/10 for writes; controller cache with BBU where applicable; write cache policy set.
• File systems: XFS or ext4 for most stacks; ZFS when you need snapshots and checksums.
• Queues: NVMe queue depth sized to p95 latency targets.
• Web tier: Nginx/LS/OpenLiteSpeed with HTTP/2 or HTTP/3, gzip/brotli, HSTS, OCSP stapling.
• PHP/Python/Node: PHP-FPM pm settings, uWSGI/Gunicorn workers, Node cluster or PM2 workers per core.
• DB layer: InnoDB buffer pool and redo log size; PostgreSQL shared_buffers, work_mem, autovacuum.
• Caching: Redis/Memcached sizing, TTL policy, hot-key watch.
• Validation: Provider runs load tests on request and shares before/after graphs.

Unmanaged

• Plan: Write a short test plan for read, write, and mixed traffic.
• Tools: k6, wrk, JMeter, pgbench/sysbench, fio; record versions and flags.
• CPU/NUMA: Pin workers to cores, keep memory local per NUMA node.
• Kernel/TCP: Change one knob at a time and chart p95/p99.
• Storage: Benchmark fio with realistic block sizes; measure IOPS and tail latency.
• File systems: Pick for your pattern (large files vs small writes).
• Queues and pools: Right-size DB and thread pools; avoid thundering herds.
• Cache policy: Decide what to cache, for how long, and when to evict.
• Canary: Roll tuning in stages and watch SLOs.
• Proof: Keep dashboards and a changelog for each win.

Networking and DDoS

Good tuning fails on a weak link. Lock the ports, the routing, and the shields. 

Managed

• Port speeds: Clear 1/10/25 Gbps options. Ask for the tested line rate, not burst claims.
• Commit model: Unmetered vs 95th percentile (enterprise/optional at many hosts). Know commit, overage rules, and headroom.
• Peering: Named carriers, IXPs, and regional routes. Publish looking-glass where possible.
• Anycast (enterprise/optional): Global entry for latency-sensitive APIs, with health-based failover.
• Jumbo frames: MTU policy per VLAN; end-to-end or leave at 1500.
• QoS: Mark and shape if you run mixed traffic (streaming + API).
• DDoS L3/L4: Always-on edge scrubbing, automatic detection, and attack reports.
• DDoS L7: WAF and rate limits as add-ons; rules for bots, bursts, and auth bypass.
• CDN: Offload static assets; shield origins; enable TLS 1.3 and HTTP/3.
• Runbooks: Blackhole/BGP Flowspec steps (enterprise/optional), contact paths, and exit criteria.

Unmanaged

• Same pipes: You still ride the provider network; measure from your users’ regions.
• Traffic policy: Pick unmetered if you push steady streams; use 95th if traffic spikes.
• Routing checks: Trace to top markets; track p95 RTT and packet loss.
• Edge stance: Keep GRE tunnel or provider scrubbing ready; test failover.
• L7 defense: WAF rules, per-IP and token-bucket rate limits, CAPTCHA on risky flows.
• App hardening: Slowloris guards, keep-alive caps, sane timeouts, connection pools.
• Geo and ACLs: Block where you do not sell; narrow admin ranges.
• Logs: Keep attack logs for patterns; trim noisy rules to cut false positives.
• Drills: Simulate traffic spikes and small floods; confirm alerts and auto-actions.

Compliance and Data Location

You hardened the stack and the network. Now prove control on paper. 

Managed

• Attestations: Data center controls, documented procedures, and access logs you can cite.
• Agreements: BAAs or DPAs if offered. Clear roles for processor vs the controller.
• Evidence: Help collect logs, access reviews, and change records for audits.
• Encryption: Guidance on disk, backup, and in-flight encryption with key custody defined.
• Regions: Advice on data residency, cross-border transfers, and mirror options.
• Retention: Support for log and backup retention targets tied to policy.
• Playbooks: Steps for incident notices and regulator timelines.

Unmanaged

• Policy: You own security policy, code posture, and data handling rules.
• Audits: You prepare evidence, train staff, and run access reviews.
• Controls: You enforce least privilege, key rotation, and segregation of duties.
• Legal: You select regions, DPAs, and transfer terms with counsel.
• Testing: You run periodic control tests and document results.

Control, Customization, and Tooling

This is where managed vs unmanaged dedicated server becomes a daily experience. Control affects speed, safety, and how you ship.

Managed

• Base images: Standard images and hardened baselines on most plans.
• Panels: cPanel/Plesk or similar for fast onboarding and team handoff.
• Root: Often available, sometimes audited or limited during troubleshooting.
• Guardrails: Approved repositories, kernel versions, and firewall policies.
• Add-ons: One-click web, DB, cache, and WAF modules on higher tiers.
• Automation: Provider scripts for routine tasks and safe rollbacks.

Unmanaged

• Root freedom: Full root from day one with no guardrails.
• OS choice: Any Linux or Windows build, custom kernels, or minimal images.
• Panels or none: Run cPanel, Plesk, DirectAdmin, or manage pure CLI.
• IaC: Bake images with Packer; apply config with Ansible; stand up infra with Terraform.
• Pipelines: Build AMIs or templates, test in staging, then promote.
• Hooks: Pre/post deploy checks, health gates, and auto-revert on failure.

People and Process

The right model depends on the team you have and the time you can spend. 

Managed

• Focus: Your team ships features while ops runs in the background.
• On-call: Fewer wake-ups and fewer context switches.
• Docs: You document the app; the provider documents the box.
• Coverage: Holidays and nights are covered by a 24/7 team.
• Risk: Lower chance of missed patches or silent backup failures.

Unmanaged

• Time: Expect steady hours each month for patches, reviews, and tickets.
• Rotations: Build a fair on-call, define paging rules, and track burnout.
• Training: Keep admin skills sharp across OS, security, and tooling.
• Runbooks: Write and rehearse steps for deploys, rollbacks, and incidents.
• Continuity: Plan handovers so knowledge survives attrition.

Cost and TCO

People and process set the effort. Now put a price on it. This section converts time, risk, and add-ons into one monthly number you can compare across offers. 

Managed

• What you pay for: a higher monthly fee that bundles admins, tooling, and 24/7 response.
• What you save: fewer hours on patching, restores, and incidents; lower chance of a long outage.
• Typical add-ons: control panel, Windows license, backup storage, extra IPs, premium DDoS, and monitoring for apps.

Unmanaged

• What you pay for: a lower server fee.
• What you carry: your team’s time, on-call fatigue, and the cost of mistakes.
• Typical add-ons: the same licenses and storage, plus your own monitoring stack and alerting service.

Hidden Costs to Check (Both Models)

• Bandwidth commits vs 95th percentile overage.
• Snapshot and restore egress from object storage.
• “Emergency hands” or remote-hands fees (remote hands = physical tasks, not full server management).
• Hardware upgrade labor and lead time.
• Per-ticket or per-incident charges on lower tiers.

Tco Formula (Use Monthly Values)

Effective Monthly Cost = Server Fee + Licenses (panel / OS / backup) + (Ops Hours × Hourly Rate) + (Expected Annual Incident Cost ÷ 12)

Quick Example

• Managed: $220 server + $40 licenses + (2h × $50) + ($2,400 ÷ 12) = $520
• Unmanaged: $150 server + $30 licenses + (12h × $50) + ($6,000 ÷ 12) = $730

If your team time is expensive or the outage risk is real, managed closes the price gap fast. If you have deep skills and steady apps, unmanaged can still win.

Procurement and Contracts

Translate the TCO inputs into clear terms. Scope, SLAs, and exits protect you when teams change or issues spike. 

Managed

• Scope of service: a written page that lists inclusions (patching, hardening, monitoring, backups, restore help) and exclusions.
• Support SLOs: response and escalation times by severity, channels (chat/ticket/phone), and hours.
• SLA links: network uptime, power, and hardware replacement targets, with the credit ladder and claim steps.
• Maintenance: notice period, window length, and status page use.
• Security: baseline controls, access model, key handling, and change control.
• Compliance: BAAs/DPAs if offered, evidence packs, and audit support.
• Migration help: discovery, data sync, cutover, rollback, and a named hypercare window.
• Pricing clarity: list add-ons (DDoS tiers, extra IPs, backup storage), overage rules, and how the 95th percentile is calculated.
• Exit terms: data export, wipe method (e.g., NIST SP 800-88 Rev. 2), and certificate of destruction.

Unmanaged

• Lean terms: hardware, network, and power responsibilities; remote-hands policies and rates.
• Root access: your control; provider escalation only with consent.
• Licenses: who buys and manages panel/OS keys.
• Change windows: you schedule freezes; the provider lists any datacenter-level maintenance.
• Exit terms: same wipe-proof and timelines; clarify IP renumbering and DNS cutover support.

Fine Print to Sanity-Check (Both Models)

• Credit caps and timelines to claim.
• “Force majeure” and DDoS carve-outs.
• Hardware spares on site and parts list.
• Data location and region change process.
• Trial/POC terms and conversion path.

Migration and Lifecycle

Contracts signed. Now go live smoothly, then keep the server healthy for years. This section ties your ops plan to day-one cutover and ongoing refresh.

Managed

• Cutover plan: the provider maps dependencies, enables backups, and rehearses data sync.
• Final sync: you lower DNS TTL, freeze writes, run the last rsync/snapshot, and switch.
• Validation: health checks, logs clean, latency within target, backups running.
• Hypercare support: one week of fast response for early bugs and tuning.
• Docs: runbooks, access lists, and change history shipped to your team.

Unmanaged

• Discovery: inventory apps, ports, users, cron, and storage.
• Parity: match OS, libraries, and versions in staging before any move.
• Data moves: pick rsync, snapshots, or dump/restore; test both ways.
• Cutover: TTL to 300s, freeze window, final sync, swap, smoke tests.
• Rollback: prewritten steps to revert DNS and data; time each step.
• Post-go-live: enable monitoring pages, tune alerts, and schedule the first patch window.

Lifecycle Care (Both Models)

• Patch rhythm: monthly OS updates; fast lanes for critical CVEs.
• Perf reviews: quarterly CPU, RAM, NVMe, and network headroom checks.
• Backup drills: quarterly restore tests with timing and proof.
• Cost reviews: commits vs usage, overage patterns, right-size options.
• Refresh points: OS EOL, kernel support, CPU generation jumps, NVMe wear.
• Decommission: planned cutover, data wipe (with proof), key retirement, DNS cleanup, and access removal.

Risk and Lock-In

You priced both paths and planned the move. Now check the traps that appear later.

Managed

• Operational risk: Lower on higher tiers. A 24/7 team can patch, monitor, and restore service when those items are in scope. Incidents reach an engineer fast.
• Security risk: Lower at the OS layer. Missed patches and weak baselines are less likely.
• People risk: Lower. Holidays and attrition hurt less when a provider covers nights and weekends.
• Compliance risk: Lower if you need BAAs/DPAs and audit evidence.
• Lock-in sources:
  • Provider panels and custom images.
  • Proprietary backup formats and runbooks tied to tickets.
  • Managed firewalls/WAF rules you can’t export cleanly.
  • IP space that does not move with you.
• Mitigations:
  • Keep root and export rights in the contract.
  • Store backups in standard formats and a second location you control.
  • Use your own DNS, secrets store, and CI/CD.
  • Ask for an exit plan with steps, data formats, and timelines.
  • Prefer public tooling over provider-only agents when possible.

Unmanaged

• Operational risk: Higher if skills slip or coverage gaps appear at night.
• Security risk: Higher if patching lags or configs drift.
• People risk: Higher. On-call fatigue and single-owner knowledge can stall you.
• Compliance risk: Higher if you must assemble evidence without help.
• Lock-in sources:
  • Data gravity (large DBs, snapshots, object storage egress).
  • Provider IP space and bandwidth commits.
  • Time lock-in from custom builds with poor docs.
• Mitigations:
  • Infra-as-code for every config.
  • Containers or images you can move.
  • Object storage with lifecycle rules and tested exports.
  • Third-party DNS, monitoring, and WAF you can keep across hosts.
  • Regular move rehearsals for one non-critical service.

A simple lens: probability × impact. Managed cuts probability. Unmanaged raises control and can cut impact if your team is sharp. Your pick in the managed vs unmanaged dedicated server debate depends on which lever you value more.

Who Should Choose Which

Pick a Managed Dedicated Server If

• Uptime drives revenue or legal exposure.
• You lack a full-time sysadmin and 24/7 coverage.
• You need BAAs/DPAs or audit support.
• You want one accountable team for OS patching and restores.
• You prefer a predictable bill over variable on-call time.

Pick an Unmanaged Dedicated Server If

• You have real admin skills and a fair on-call rotation.
• You need custom kernels, niche filesystems, or non-standard stacks.
• You want full root access without guardrails.
• You optimize budgets by trading money for time you already have.
• You plan to automate everything with IaC and test runbooks.

Pick a Co-Managed Dedicated Server If

• You want the provider to own OS patching and baseline monitoring.
• You keep control of apps, containers, and deploys.
• You need a faster setup now, with room to take more control later.

Rule of Thumb

• If two or more “managed” bullets fit, go managed.
• If three or more “unmanaged” bullets fit, go unmanaged.
• If you split down the middle, start co-managed and review in 90 days.

Responsibilities & Support 

Owner = who executes + is accountable for outcome.

Note: Backup/restore scope varies by plan. If it’s not written in the contract, assume you own it.

Final Thoughts

Here’s the bottom line: pick the model that matches your people, risk, and timeline. If you need uptime and lack 24/7 coverage, choose managed. If you have real admin skills and want full control, go unmanaged. 

Not sure? Start co-managed. Review in 90 days. RedSwitches offers both paths. Managed plans cover OS patching and monitoring, and may include scheduled backups if they’re in scope, so your team can ship.

Unmanaged plans give full root and a clean server for custom stacks. We’ll map RPO/RTO, DDoS tier, and panel licensing up front, then plan a safe cutover. Ready to move? Talk to an engineer for a build sheet.

FAQs

Q. Do I keep root on a managed plan?

Often yes, sometimes with an audit. Ask for: customer retains root, provider uses sudo with session recording, and no changes without approval. Put it in the contract.

Q. Does managed include backups?

Sometimes. Confirm type (file/image, DB-aware), schedule (example: daily incrementals + weekly fulls), retention, off-site storage, encryption, restore SLA, test cadence, and any restore fees.

Q. Can unmanaged match managed reliability with a skilled team?

Yes, if you run tight ops: 24/7 monitoring, clear SLOs, fast patching, IaC to prevent drift, quarterly restore drills, and an on-call rotation that actually answers.

Q. What counts as included DDoS vs an add-on?

Included: L3/L4 edge scrubbing with a traffic cap. Add-ons: higher caps, L7/WAF rules, bot controls, custom signatures, and attack reports. Check null-route thresholds and fees.

Q. What is a realistic hardware replacement target?

20–60 minutes for hot-swap parts (PSU, drives, NIC). 2–4 hours for the motherboard or chassis. Require on-site spares and written targets.

Q. Managed vs unmanaged VPS vs dedicated: when to use each?

• Managed VPS: small teams, variable loads, quick start.
• Unmanaged VPS: dev/test, low cost, some noise risk.
• Managed dedicated: uptime-sensitive, steady high load, compliance.
• Unmanaged dedicated: custom stacks, full control, skilled team. For heavy I/O or GPUs, pick dedicated.

Q. Can I switch later without downtime?

Often near-zero downtime is possible if your stack supports replication/blue-green. Lower DNS TTL, clone the stack, sync data continuously, cut over with blue/green or a load balancer, keep rollback ready, and rehearse the plan first. Otherwise plan a brief cutover window.