AiXVPScost & terms for AI / automation

Contabo Decision guide Updated 2026-11-12

Contabo for WordPress: Which Plan, and What Breaks First

If I were putting a small self-managed WordPress site on Contabo, I would start with Cloud VPS 4 and spend the difference on backups and a real mail path. I would move to Cloud VPS 6 for more RAM and disk headroom when the site has WooCommerce, staging, or a plugin/import pattern that needs it. I would move to Cloud VPS Plus 4 only when a measurement points to I/O or port, not to RAM or CPU. I would not buy a Performance or GPU plan by default. The reason is simple: WordPress rarely breaks because the plan name is too small. It breaks first on disk, PHP workers, database memory, mail deliverability, or a backup that cannot be restored. Those are stack decisions, not plan-card decisions.

Contabo review Sources
Contabo decision guide — one purchase question, one decision.
Scope. Decision draft. Contabo product and price facts were checked on the official Contabo pages on 2026-11-12. This is a planning analysis, not a hands-on WordPress test, a paid order, or a provider ranking. Prices, inclusions, and availability change; verify the configurator before ordering.

What WordPress actually consumes

A WordPress request is not one resource. The web server hands the request to PHP, PHP queries MySQL, and both touch the filesystem. A page cache can remove most of that work for anonymous visitors. Logged-in users, cart and checkout requests, cron, plugin updates, and imports bypass or stress different parts of the stack.

For capacity planning, I would write down five numbers before comparing plans:

  • PHP worker count and memory limit. A small site may run two to four workers; WooCommerce and page builders can need more.
  • MySQL buffer pool and working set. The database should fit the hot working set in memory, not just the whole dump on disk.
  • Disk for uploads, plugins, themes, backups, and logs. WordPress grows quietly, especially with image regeneration and backup plugins.
  • Cron and admin work. Updates, imports, and backups are short peaks that can exhaust a small plan even when normal traffic is low.
  • Mail path. A VPS can run WordPress, but that does not mean it should send the site's mail directly. Contabo documents port access, a sending limit, and PTR management; those do not create sender reputation. The outbound mail guide covers the Contabo-specific pieces.

That list is more useful than a page-view estimate. A cached brochure site and a WooCommerce store can show the same visitor count and need very different plans.

The three Contabo plans I would compare first

Contabo's current Core and Performance pages list several plans. For a WordPress decision, three are enough to frame the choice. The prices below are the list price and the 24-month term price, both excluding VAT, as shown on 2026-11-12. VAT is added at checkout. They are not a quote for a different term, region, or renewal period.

PlanvCPURAMStorageSnapshotsPortList / 24-month price
Cloud VPS 448 GB100 GB SSD1200 Mbit/s€5.50/mo list; €4.40/mo on a 24-month term (20% off), both excl. VAT
Cloud VPS 6612 GB200 GB SSD or 100 GB NVMe2300 Mbit/s€7.50/mo list; €6.00/mo on a 24-month term (20% off), both excl. VAT
Cloud VPS Plus 44 AMD EPYC8 GB150 GB NVMe5500 Mbit/s€13.50/mo list; €10.80/mo on a 24-month term (20% off), both excl. VAT

Two details matter more than the headline price. First, Contabo says a one-time setup fee applies to new Cloud VPS 4 orders on monthly contracts, and that longer terms waive it; the exact fee is in the configurator. Second, the low monthly figures are tied to a 24-month term. If I wanted a short commitment, I would compare the actual cart, not the plan card.

The Cloud VPS Plus 4 has the same rated CPU count and RAM as Cloud VPS 4, but it changes the storage to NVMe, raises the port to 500 Mbit/s, and includes five snapshots instead of one. That is an I/O and operations upgrade, not a RAM upgrade. For WordPress, that can matter for database and plugin work, but it does not replace PHP or MySQL tuning.

What breaks first on a small WordPress plan

I would rank the failure modes in this order, because they are the ones that turn a cheap plan into an expensive afternoon.

Disk before CPU. Uploads, backups, image regeneration, logs, and staging copies all land on the same disk. A 100 GB plan can be plenty for a small site, but a backup plugin that keeps three local copies can eat the margin. The first symptom is often a failed update or a database write error, not a slow page.

PHP workers and memory. A page builder or WooCommerce can exhaust the PHP memory limit or the available workers before the CPU looks busy. The fix may be a higher memory limit, fewer plugins, a page cache, or a larger plan, in that order. A larger plan without a PHP diagnosis just moves the same limit.

MySQL working set. A small database fits easily. A store with orders, revisions, and plugin tables grows. If the buffer pool is too small, queries wait on disk. That is a database and memory question, not a CPU-count question.

Mail deliverability. WordPress sends password resets, order mail, and form notifications. A VPS with a fresh IP and no sending history is not a mail service. Contabo documents port access, a sending limit, and PTR management, but those do not create sender reputation. For a business site, I would use an external SMTP provider and keep the VPS out of the direct-to-recipient path. The WordPress mail map explains the broader path.

Backups that are not restores. A snapshot is a disk image with a retention period. Auto Backup is a daily off-server copy with a shorter retention. Neither is a tested restore. Before launch, I would restore a copy to a separate server and confirm that the site, database, uploads, and mail settings come back.

What I would order for three site types

A cached brochure or blog. Cloud VPS 4 is the first candidate. Put a page cache in front, keep uploads and backups under control, use external SMTP, and keep one snapshot plus an off-server copy. The 8 GB RAM is enough for a small PHP worker pool and MySQL working set; the 100 GB SSD is the line to watch.

A small WooCommerce store. I would start at Cloud VPS 6, not because the store needs six cores on day one, but because the extra RAM, disk, and second snapshot give more room for checkout peaks, order tables, and plugin updates. I would also budget a staging copy and a restore test. If the store is media-heavy or the database is large, Cloud VPS Plus 4's NVMe and 500 Mbit/s port become more interesting than another pair of cores.

A multisite or agency staging box. I would compare Cloud VPS 8 or Cloud VPS Plus 6. The decision is disk and snapshot count first, RAM second, CPU third. A multisite network with several sites and staging copies is a disk-and-backup problem before it is a compute problem. The multisite and staging architecture page covers the layout.

For a site that is mostly static but has a heavy admin, I would not jump to a dedicated or GPU plan. I would measure the admin requests, the plugin load, and the database queries. WordPress is usually fixed by removing work, not by buying a bigger machine.

Where Contabo's extras fit, and where they do not

Contabo's snapshots and Auto Backup are useful, but they are different layers. Snapshots are disk images with 30-day retention; Auto Backup is 10 days of daily off-server backups. The billing and backup guide explains the restore behavior. Object Storage is a third layer: S3-compatible file storage from €2.49/month, useful for uploads, database dumps, and archives that should not live only on the VPS.

None of those products is managed WordPress. Contabo gives you the server and the panel; the application, PHP configuration, database, updates, mail, and backups remain your job. If the site cannot tolerate that responsibility, the right comparison is a managed WordPress host, not a larger Contabo plan.

The first 30 days on the plan

A plan choice is a hypothesis until the site runs on it. For the first month, I would record a small baseline rather than wait for a complaint:

  • Disk: free space at the start and end of each week, plus the size of uploads, backups, and logs. A steady decline is a planning signal even if the site feels fine.
  • PHP workers: the maximum concurrent workers and any 502/504 events. If workers saturate at normal traffic, the next step is a cache or a worker limit, not automatically a larger plan.
  • MySQL: slow queries, buffer pool usage, and the size of the largest tables. A growing order or revision table changes the memory requirement.
  • Mail: delivery failures, spam placement, and whether the site is sending directly or through an SMTP relay. A working form is not proof of inbox delivery.
  • Cache: hit rate for anonymous pages and the bypass paths for logged-in users, carts, and previews. A high hit rate can make a small plan feel larger.
  • Backups: the last successful snapshot, the last successful off-server copy, and one restore test. An untested backup is a hope.

I would also record the plan's renewal date and the next plan's price. Upgrading is easier when the trigger is a measured threshold rather than a bad week.

When a managed WordPress host is the better comparison

Contabo sells a server, not a managed WordPress service. If the site cannot afford the time for PHP configuration, database maintenance, plugin updates, security patches, mail, and restore tests, the right comparison is a managed WordPress host, not a larger Contabo plan. A bigger VPS does not remove those tasks; it only gives them more room.

The Contabo route fits when the site owner or a small team wants root access, a predictable server, and the freedom to run other services on the same box. It fits less well when the site is a business-critical store with no one responsible for the stack. The decision is about who does the work, not only about the monthly price.

What this does not decide

This article does not measure WordPress response time on Contabo, does not test a WooCommerce checkout, and does not compare Contabo with a managed WordPress host. It also does not quote a setup fee or a renewal price, because those are cart-specific. It gives a plan-selection order and the failure modes I would check first.

If I had to leave one rule: buy the smallest plan that fits the stack after caching and mail are handled, then let a measured bottleneck choose the upgrade. The plan card is the last step, not the first.

Sources