The difference between managed and unmanaged hosting comes down to one question: who’s responsible for the server? With managed hosting<\/strong>, your provider handles the operating system, security patches, software updates, and often performance tuning. With unmanaged hosting<\/strong>, you get root access to a bare server and the rest is on you.<\/p>\n Most people land on this page because they’re shopping for a VPS or dedicated server and they’ve noticed a significant price gap between managed and unmanaged plans. That gap isn’t arbitrary \u2014 it reflects real labour. Understanding what’s included on each side helps you spend your money in the right place.<\/p>\n This article breaks down what each model actually covers, where each one makes sense, and a few things vendors don’t always tell you upfront.<\/p>\n “Managed” isn’t a standardised term. Two providers can both advertise managed hosting and deliver completely different levels of service. Before you sign up for anything, get specifics in writing.<\/p>\n That said, here’s what a solid managed plan typically includes:<\/p>\n Here’s what managed hosting usually does not<\/strong> cover, even from reputable providers:<\/p>\n \ud83d\udcdd Note: Managed WordPress hosting is a narrower, more specialised product. It’s managed hosting tuned specifically for WordPress \u2014 often with staging environments, automatic core\/plugin updates, and WordPress-trained support staff. It’s not just a regular managed VPS with WordPress pre-installed. If WordPress is your only workload, that’s worth the distinction.<\/p>\n Unmanaged plans hand you a freshly provisioned server with root SSH access, a base OS image (usually Ubuntu 22.04 LTS, Debian 12, AlmaLinux 9, or similar), and that’s about it. No control panel. No firewall rules out of the box. No one to call if you misconfigure What you’re buying is raw compute at a lower price point. At Host & Tech, unmanaged VPS plans start at $5.83\/mo \u2014 the trade-off is that you own everything from the OS upward.<\/p>\n Unmanaged suits you if you can comfortably handle all of the following:<\/p>\n \u26a0 Warning: A common mistake is choosing unmanaged hosting to save $20\u2013$30\/month, then spending 10+ hours on a server incident that a managed support team would have resolved in under an hour. Factor in your own time honestly.<\/p>\n You run a small e-commerce store on WooCommerce. You have no in-house developer. You need the site up reliably, SSL to renew automatically, and someone to call when something breaks at 2am before a sale campaign.<\/p>\n Unmanaged hosting is wrong for this situation. You’d be responsible for server security at a time when WooCommerce sites are actively targeted by bots scanning for outdated plugins. Managed hosting \u2014 or better yet, managed WordPress hosting \u2014 means someone else is watching the server layer while you focus on the business.<\/p>\n You’re comfortable with Linux. You run a custom Nginx config, use Docker Compose for your deployments, and you’ve got Ansible playbooks for provisioning. A managed environment would restrict your stack and you’d constantly be working around the provider’s defaults.<\/p>\n Unmanaged is the right call here. You want full control of You have a backend developer who knows Linux basics but isn’t a dedicated sysadmin. You’re scaling up and can’t afford downtime, but you also can’t afford a full-time infrastructure hire yet.<\/p>\n This is where managed dedicated servers earn their cost. Your developer handles application-layer work; the hosting provider handles OS security, monitoring, and hardware. It’s a reasonable split of responsibility for a team at that stage.<\/p>\n I see this assumption cause real problems. Many users sign up for managed hosting expecting that someone is actively watching their server 24\/7 and will call them the moment disk I\/O spikes. That’s not how most managed plans work.<\/p>\n “Managed” typically means the provider will respond<\/em> to issues, not necessarily detect<\/em> them proactively. Some plans include active monitoring; many don’t unless you’re on a higher tier or have explicitly added it. Before you rely on managed hosting as your safety net, ask your provider directly: “If my server’s RAM hits 98% at 3am on a Sunday, what happens?” The answer will tell you a lot.<\/p>\n At Host & Tech, our managed plans include proactive server monitoring with alert thresholds \u2014 but I’d still recommend you set up your own application-level monitoring (Uptime Robot, Better Uptime, or a self-hosted Uptime Kuma instance) regardless of plan type. Don’t rely on a single point of alerting.<\/p>\n This happens more than you’d think. You edited Scope disputes are frustrating, and they’re common. The provider says “that’s your application, not the server.” You say “the server is broken.” Usually, the line is drawn at the OS and server software layer. If Apache is crashing because of a misconfigured What “Managed” Actually Means (and What It Doesn’t)<\/h2>\n
\n
\n
What Unmanaged Hosting Gives You<\/h2>\n
sshd_config<\/code> and lock yourself out.<\/p>\n\n
ufw<\/code> or iptables<\/code><\/li>\nhtop<\/code>, iostat<\/code>, netstat<\/code> output and acting on it<\/li>\n<\/ul>\nSide-by-Side Comparison<\/h2>\n
\n\n
\n \nArea<\/th>\n Managed<\/th>\n Unmanaged<\/th>\n<\/tr>\n<\/thead>\n \n OS patching<\/td>\n Provider handles it<\/td>\n Your responsibility<\/td>\n<\/tr>\n \n Control panel<\/td>\n Usually included or available<\/td>\n You install it (if you want one)<\/td>\n<\/tr>\n \n Firewall setup<\/td>\n Configured by provider<\/td>\n You configure it<\/td>\n<\/tr>\n \n Support scope<\/td>\n Server-level issues included<\/td>\n Network\/hardware only<\/td>\n<\/tr>\n \n Root access<\/td>\n Sometimes restricted<\/td>\n Full root access<\/td>\n<\/tr>\n \n Price<\/td>\n Higher<\/td>\n Lower<\/td>\n<\/tr>\n \n Best for<\/td>\n Businesses, non-technical teams, agencies<\/td>\n Developers, sysadmins, DevOps teams<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Real-World Scenarios<\/h2>\n
Scenario 1: Small Business Running WooCommerce<\/h3>\n
Scenario 2: Developer Building and Deploying Multiple Client Apps<\/h3>\n
\/etc\/nginx\/nginx.conf<\/code>, the ability to install whatever you need via apt<\/code> or dnf<\/code>, and no support team accidentally touching your config files during a routine update.<\/p>\nScenario 3: Growing SaaS Company<\/h3>\n
The Non-Obvious Gotcha: Managed Doesn’t Mean Monitored in Real Time<\/h2>\n
Common Issues and Troubleshooting<\/h2>\n
“I chose unmanaged and now I’m locked out of SSH”<\/h3>\n
\/etc\/ssh\/sshd_config<\/code>, changed the port or disabled password auth before adding your key properly, and now you can’t get back in. On a VPS, your provider’s control panel usually offers a web-based console (VNC or noVNC access) that bypasses SSH entirely \u2014 use that to fix your config and restart the SSH service with systemctl restart sshd<\/code>. On a dedicated server, you may need to request IPMI\/iDRAC access from your host.<\/p>\n“My managed provider says fixing this is out of scope”<\/h3>\n
.htaccess<\/code> file in your WordPress install, that’s application scope. If Apache is crashing because of a misconfigured \/etc\/httpd\/conf\/httpd.conf<\/code> the provider manages, that’s their scope. Get clarity on the boundary in writing before you need it.<\/p>\n“Unmanaged server is running fine but keeps getting compromised”<\/h3>\n