Hostinger vs Contabo VPS for a small Node.js app

Quick answer: For a self-managed Node.js app needing at least 8 GB RAM, 80 GB listed storage, a US location, and a whole-server recovery path, both Hostinger KVM 2 and Contabo Core Cloud VPS 4 clear the listed capacity floor. Hostinger KVM 2 currently lists 100 GB NVMe and included weekly backup. Contabo Core 4 lists 100 GB SSD and more listed vCPU, while its daily Auto Backup is an add-on; Contabo’s Plus 4 branch is the NVMe-labelled option. The next choice is which available region and recovery route meet your needs. Sources: Hostinger plans, Contabo Core, backup terms.

Important constraint: Both are self-managed VPS routes. The operator still owns Node, the reverse proxy, OS and dependency updates, monitoring, secret custody, and application recovery. A provider image restore can overwrite the whole server; it is neither a portable exit artifact nor a substitute for a rebuild from source. Sources: Hostinger responsibility, Hostinger restore, Contabo restore.

Hold the workload fixed: one current Node.js LTS web/API service, two application processes, and a background worker behind a reverse proxy. Managed PostgreSQL and object storage live outside the VPS. The server holds the OS, app release, runtime, configuration, temporary files, and logs, but not the sole copy of the production database or uploads. Use two listed vCPU, 8 GB RAM, 80 GB storage and a US region as the initial selection floor.

The provider facts below were checked October 3, 2026. A purchase decision needs the current checkout plan, region availability, prepaid total and renewal, backup add-on, tax, and cancellation terms. Compare the configured totals for the same term and backup coverage.

Normalize the plan rows before comparing them

The Hostinger KVM 2 row and Contabo Core row both meet the minimum listed RAM and storage. They are not equivalent configurations. Four listed vCPU do not prove faster response time than two; CPU generation, contention, app behavior, and storage and network paths all matter. Similarly, an NVMe label identifies a storage tier in the product listing but does not prove the app’s database query or API request will be faster. The database is external in this scenario, making that inference especially weak.

Measure the workload’s own pressure points during a future trial: memory used by both Node processes and the worker at the same time, CPU during an expected burst, disk occupied by release artifacts and logs, and any temporary space needed during deployment. An 8 GB listing is not 8 GB available to the application after the OS and services use their share. Set an alarm for the resource that approaches its operational ceiling, and confirm the behavior when the worker and web traffic peak together. Record these readings alongside the client-path measurements below so the result can be repeated after a deployment change.

If NVMe-labelled storage is a hard procurement requirement, compare Hostinger KVM 2 with the Contabo Plus 4 branch rather than treating Core’s SSD as the same class. If the hard requirement is simply at least 80 GB of listed storage, both Core and KVM 2 pass that filter and backup, location, and a same-workload test become more important. Check whether the fair-use and outgoing-traffic terms cover the expected downloads, uploads and worker transfers.

Check location as availability and latency, not a map contest

Hostinger’s VPS location guide currently lists Phoenix and Boston among US choices. Contabo’s US page documents Seattle, St. Louis, and a New Jersey location. The available region for a particular plan can depend on current capacity at checkout. Confirm that the intended plan is orderable there before treating a city name as a decision.

Then test the application path from clients representative of your users: one API request, one static asset, and an operation that reaches the managed database. If the database sits in a different region from the VPS, the database round trip can dominate a request even when the users are geographically near the server. Record the client location, VPS region, database region, test date, and observed times. Keep the request and test data the same on both servers.

Keep the region check separate from the recovery question. A backup tied to a provider’s control panel may not be a portable way to move to another provider, and a region change may require a rebuild. Hostinger’s location guidance says VPS location is fixed after setup and moving involves backup and reinstall; Contabo describes region movement as possible in many cases rather than universal. Plan the portable rebuild even if a panel later offers a migration shortcut.

Compare backups by what you can restore

Hostinger’s VPS backup guide currently describes a weekly default backup, with daily backup as a purchased option. It states up to four retained copies, currently two daily and two weekly under the relevant setup, and a manual snapshot with a short expiry. A whole-VPS restore overwrites current content, locks the server while it runs, and cannot be canceled; the cited route does not support directly downloading the backup or snapshot. Check the account’s current retention before counting on a particular incident date.

Contabo’s snapshot help explicitly says a snapshot is not a backup; it has a documented expiry and cannot be downloaded. The optional VPS Auto Backup runs daily, keeps up to ten off-server copies over a short window, and restores the whole VPS by overwriting it. It does not offer an individual-file restore in that route, and Contabo says recoverability is not guaranteed. Treat that language as a reason to rehearse, not as proof a given backup will fail.

The external PostgreSQL and object storage in this workload simplify the host comparison, but they do not disappear from recovery. The operator must still verify database credentials, network access, object-store permissions, and the consistency of any queued jobs after a server restore. An image can contain an older application release or stale secrets while the managed database has moved on. Define what app version and migration state are valid before pressing a whole-server restore button.

Write down which data is safe to lose from the VPS. A temporary upload may be safe only after it reaches object storage; a job queue may hold tasks that must be replayed or deduplicated; local logs may be needed for diagnosis even if they are not production records. Assign each local path a recovery action: recreate from Git, retrieve from an external service, regenerate, or restore from an independent copy. That list shows whether a weekly image is enough for the stated loss tolerance. It also prevents the team from discovering during an incident that an apparently temporary directory held the sole copy of a customer file.

Rehearse three incidents on paper, then in staging

First, a configuration file is deleted. Identify its repository commit or encrypted artifact, restore only that file, check ownership and permissions, restart the affected service if needed, and verify a health endpoint. If the sole copy lived on the VPS, that is a gap in the deployment design. A destructive whole-image rollback should not be the first response to a small file error.

Second, the VPS becomes unusable. Record the provider image timestamp, what release and configuration it should contain, the expected data-loss window for files kept locally, and who is authorized to restore. In staging, restore to the documented target, then check Node service start, reverse proxy and TLS, external PostgreSQL connectivity, worker behavior, logs, and one non-destructive synthetic job. Record the elapsed recovery time and compare it with the outage the business can tolerate.

Third, the business leaves the provider or changes region. Provision a clean VPS from the recorded OS and configuration, fetch the exact Git release and lockfile, retrieve secrets through the approved custody process, and point a test hostname at the new host. Check the health endpoint and one synthetic transaction before considering a DNS cutover. Keep the old host available under a rollback plan until the new route passes. This exercise is more demanding than image restore, but it tests whether the business can exit without depending on an image it cannot download.

Use one evidence ledger for all three cases: provider and exact plan, region, date, backup timestamp, app commit, source of each secret, expected service state, observed health result, worker result, external-service connection, errors, and actual duration. Leave result cells empty until the staging run. If a recovery path cannot be authorized or cannot reach a valid app state, the listed backup feature has not met this workload’s requirement.

During the clean rebuild, compare the generated server with the old one: Node major version, package lockfile, reverse-proxy configuration, service startup, environment variables, scheduled jobs, TLS renewal path, and monitoring alerts. The app can pass one HTTP health request while its worker is disabled or a future certificate renewal is broken. Keep a short list of checks that covers the recurring work, not only the launch moment. If a setting exists only as an undocumented click in a provider panel, capture it in the build record or replace it with a reproducible step before calling the exit path ready.

Make the decision after normalizing recovery and checkout

Hostinger KVM 2 is the more direct documented candidate when the buyer explicitly requires 100 GB NVMe and included weekly whole-VPS backup. Contabo Core Cloud VPS 4 is a capacity candidate when 100 GB SSD is acceptable and the operator is willing to evaluate the daily Auto Backup add-on; Plus 4 is the branch to inspect if NVMe is required.

At checkout, record market, currency, region, term, upfront payment, renewal, tax, backup add-on, storage branch, and cancellation conditions. Do not compare an introductory effective monthly rate on one prepaid term with another provider’s different term as if they were the same invoice. Confirm backup eligibility for the exact order, then run the staging restore and portable rebuild. The plan that passes the fixed workload and recovery checks is the defensible choice, even if its advertised resource row looks less dramatic.