Loading review card…
Loading review card…
Loading review card…
Every review on HostingProf follows the same rubric. Weights are public. Evidence is required. We don't accept sponsored placements.
We score every host on five dimensions. Each gets a 0–10 sub-score, blended into the overall score via the weights in §2.
Sub-scores combine via the following fixed weights. The numbers below render directly from lib/content/weights.ts— the same module the build-time sync script uses to compute every review's overall score (so editorial copy and computed numbers can never drift).
| Dimension | Weight |
|---|---|
| Performance | 30% |
| Reliability | 25% |
| Value | 20% |
| Support | 15% |
| Ease | 10% |
From Phase 7 onward, every published review carries at least three first-hand evidence artifacts — a TTFB measurement run, a support ticket transcript, and a billing screenshot for the project size we tested. Reviews shipped in Phase 3 are explicitly marked as stubs via the on-page Stub content banner: the scoring rubric is locked, but the supporting evidence is still being collected.
Reviews get a visible “Update due” badge after 90 days without a re-test. Comparisons inherit the badge from whichever of their two underlying reviews is the most stale. We re-test sooner when a provider ships a major architectural change (region launch, pricing reset, control-panel rewrite).
HostingProf does not accept money for review placements, score adjustments, or "featured" rankings. Every recommendation is the recommendation we'd give a friend. If we ever change this, we will say so on this page first and disclose every affected review.
Found a factual error in a review? Email corrections@hostingprof.com with the URL and the fact. We respond within 5 business days, fix the page, and log the correction at the bottom of every affected review.
Bigger errors or methodology disputes? Submit them via the contact form on /about.
Our reviews are noindex'd as stubs until backed by first-hand testing data. Our tools are indexed from day one because each delivers genuine computational value: real GPU pricing math, real n8n sizing recommendations, real SSL handshake inspection. The distinction is honesty about content completeness, not SEO strategy — shipping thin review pages would harm both users and our search trust score under Google's Helpful Content guidance.
The GPU Pricing Calculator is backed by a hand-curated dataset of 30 entries (6 providers × 5 GPU models). Every row carries a source_urlpointing to the provider's public pricing page, plus a last_verifieddate — the founder hand-verifies each value every quarter, and the result table's amber Update overdue warning fires automatically when last_verified_max is more than 120 days old.
| Field | Value |
|---|---|
| Dataset version | 1 |
| Entries | 30 |
| Last verified | 2026-05-24 |
| Next scheduled refresh | 2026-08-24 |
Refresh cadence is quarterly. Bumping version in the JSON file invalidates every cached calculation downstream — readers and the long-TTL Postgres tool_cache table both pick up fresh numbers on the next deploy without manual cache eviction.
The n8n Hosting Recommender scores 5 VPS providers against four weighted dimensions. Weights are revisable post-launch — the founder edits lib/tools/n8n-recommender/weights.ts and this page re-renders the new numbers automatically on the next deploy.
| Dimension | Weight |
|---|---|
| Budget | 35% |
| RAM | 30% |
| Region | 20% |
| Workflows | 15% |
RAM and workflow-count thresholds are grounded in n8n's own self-hosting docs and community sizing reports — not founder-invented capacity assumptions. Each band's source link points to the upstream guidance.
| Tier | Min RAM (GB) | Approx max workflows | Source |
|---|---|---|---|
| 1 GB — light experiments (< 10 workflows) | 1 | 10 | Source |
| 2 GB — n8n's official minimum (10–50 workflows) | 2 | 50 | Source |
| 4 GB — production recommended (50–200 workflows) | 4 | 200 | Source |
| 8+ GB — heavy concurrency / queue mode at scale | 8 | 1000 | Source |
Scoring methodology adapted from the Mozilla HTTP Observatory (source code) under the Mozilla Public License 2.0. Score-to-grade map and per-test point modifiers are taken verbatim from the Mozilla source. The SSL Checker runs each probe against your URL and totals the modifiers; a Vitest snapshot test pins these constants verbatim so any Mozilla update surfaces as a deliberate PR diff (tests/unit/lib-tools-ssl-checker-grading.test.ts).
| Threshold | Grade |
|---|---|
| ≥ 100 | A+ |
| ≥ 95 | A |
| ≥ 90 | A |
| ≥ 85 | A- |
| ≥ 80 | B+ |
| ≥ 75 | B |
| ≥ 70 | B |
| ≥ 65 | B- |
| ≥ 60 | C+ |
| ≥ 55 | C |
| ≥ 50 | C |
| ≥ 45 | C- |
| ≥ 40 | D+ |
| ≥ 35 | D |
| ≥ 30 | D |
| ≥ 25 | D- |
| ≥ 20 | F |
| ≥ 15 | F |
| ≥ 10 | F |
| ≥ 5 | F |
| ≥ 0 | F |
Each per-header scorer picks one modifier key based on the header's presence and value. Modifiers fold additively into a 100-point baseline; the final score is clamped to [0, 100] before the grade lookup above.
| Modifier | Points |
|---|---|
preloaded | +5 |
maxage_6mo_plus | 0 |
maxage_under_6mo | -10 |
not_implemented | -20 |
header_invalid | -20 |
no_https | -20 |
invalid_cert | -20 |
| Modifier | Points |
|---|---|
no_unsafe_default_src_none | +10 |
no_unsafe_inline_eval | +5 |
unsafe_inline_in_style_only | 0 |
insecure_scheme_passive | -10 |
unsafe_eval | -10 |
unsafe_inline | -20 |
insecure_scheme | -20 |
header_invalid | -25 |
not_implemented | -25 |
| Modifier | Points |
|---|---|
via_csp_frame_ancestors | +5 |
sameorigin_or_deny | 0 |
allow_from | 0 |
not_implemented | -20 |
header_invalid | -20 |
| Modifier | Points |
|---|---|
nosniff | 0 |
not_implemented | -5 |
header_invalid | -5 |
| Modifier | Points |
|---|---|
private | +5 |
no_referrer_when_downgrade | 0 |
not_implemented | 0 |
unsafe | -5 |
header_invalid | -5 |
| Modifier | Points |
|---|---|
secure_httponly_session_samesite | +5 |
secure_httponly_session | 0 |
not_found | 0 |
without_secure_hsts_protected | -5 |
session_without_secure_hsts_protected | -10 |
without_secure | -20 |
invalid_samesite | -20 |
antiCsrf_without_samesite | -20 |
session_without_httponly | -30 |
session_without_secure | -40 |
The Hosting Detector identifies the infrastructure behind a domain by combining four independent signals. Each signal reports its own availability and confidence; the tool never silently guesses, and a failed signal is rendered as UNAVAILABLE rather than dropped — the other three still answer (per-signal partial results).
| Signal | Source |
|---|---|
| DNS resolution + ASN classification | Resolve the domain to an IP, then map that IP to its autonomous system using the vendored MaxMind GeoLite2 ASN database plus a curated table of the top ~50 hosting ASNs (see Attributions). |
| HTTP response headers | Server, X-Vercel-Id, CF-Ray and similar fingerprints reveal the edge/CDN and origin stack. |
| WHOIS registration | APILayer WHOIS lookup, fronted by a monthly budget circuit-breaker (see below). |
| SSL certificate | TLS handshake against the resolved IP — issuer and SAN entries corroborate the hosting provider. |
The ASN classification table covers roughly the top 50 hosting and CDN autonomous systems and is refreshed quarterly alongside the vendored GeoLite2 database. An IP whose ASN is outside the curated set is reported honestly as unclassified rather than guessed.
WHOIS calls cost money, so an atomic monthly counter (Upstash INCR keyed on the billing month) runs before any outbound request. When the counter crosses 90% of the confirmed APILayer monthly cap, the probe short-circuits with budget_exceeded and the WHOIS signal renders as UNAVAILABLE — the DNS/ASN, headers, and certificate signals are unaffected. This caps spend without taking the whole tool offline.
When a domain sits behind a CDN, the true origin host is frequently not directly detectable. In that case the tool says so explicitly (“origin is behind the CDN and not directly detectable”) instead of inventing a provider. Detection is descriptive, not an endorsement — identifying a host implies nothing about its quality.
The DNS/ASN signal is powered by MaxMind GeoLite2 data — see the Attributions section for the required CC BY-SA 4.0 notice.
The Modern Stack Cost Estimator projects the monthly bill for a developer workload across six platforms — Vercel, Netlify, Cloudflare Pages, Fly.io, Render, and Railway — using each provider's public pricing tiers. Costs are computed piecewise-linearly from official vendor pricing pages; nothing is guessed or estimated by feel.
| Provider | Tiers modelled |
|---|---|
| Vercel | Hobby (free) → Pro |
| Netlify | Starter (free) → Pro |
| Cloudflare Pages | Free → Workers Paid |
| Fly.io | Pay-as-you-go |
| Render | Free → Starter |
| Railway | Usage-based |
Overage charges (bandwidth, function invocations, build minutes, egress, persistent volumes) are the part of a hosting bill that surprises developers, so we surface their dollar impact inline with an amber badge rather than burying them in a footnote. Every fee row carries the verbatim origin_sentencequoting the vendor's billing docs plus a source_url link, so you can verify each number at its source.
The dataset is hand-verified against each provider's official pricing page and refreshed quarterly. Every plan and fee carries a last_verified date; when the dataset is more than 120 days stale the result UI raises an amber Update overdue banner so a reader never mistakes an aging estimate for a fresh one.
The TTFB Tester measures time-to-first-byte for a URL from three Vercel compute regions in parallel and reports per-region sub-timings (DNS, TCP connect, TLS handshake, and server wait).
| Region | Location |
|---|---|
iad1 | Washington, DC, USA |
fra1 | Frankfurt, Germany |
hnd1 | Tokyo, Japan |
Each region runs two requests: a discarded warm-up that primes our function's DNS resolver and Node TLS subsystem, then a measured request on a fresh TCP socket forcing a full TLS handshake. Discarding the first request means TLS session resumption never under-reports tls_ms, so the measured run is a faithful first-visit analogue.
Both probes issue a GET (not HEAD — dynamic servers often short-circuit HEAD and report misleading timings) and abort the moment the first response chunk arrives, so no response body is ever downloaded.
Each region has an 8-second timeout and the fan-out uses Promise.allSettled, so a slow or failing region is rendered greyed with a TIMEOUT/ERROR chip rather than silently dropped. A cold-start heuristic flags COLD-START SUSPECTED when a region's ttfb_ms exceeds 800ms and its tls_ms exceeds 300ms. Each (URL, region) result is cached for 300 seconds in the Postgres tool_cache table; re-running a recent test shows a CACHED chip instead of FRESH.
This product includes GeoLite2 data created by MaxMind, available from https://www.maxmind.com. MaxMind's GeoLite2 ASN database powers the Hosting Detector tool's autonomous-system identification signal and is licensed under CC BY-SA 4.0. We refresh the vendored database quarterly.