Static site or dedicated server: which do you actually need?

The question underneath the question

Almost every hosting decision people agonize over collapses into one real question: does this site need a server standing by, or does it just need to be handed out? Get that one right and the rest — price, speed, how much upkeep it needs — mostly follows on its own.

What a static site handles well

A static site is pre-built pages and assets, pushed out to a global edge network and handed to visitors with no server computing the response on the fly. That's a good fit for anything where the content is the same for everyone, or only changes when someone deliberately redeploys it:

• Marketing sites, landing pages, documentation, and blogs
• Portfolios, brochure sites, and product pages
• Front ends that call out to a third-party API rather than running their own backend
• Anything currently over-provisioned on a full server just to serve HTML and images

The upside is real: no server to patch, near-instant page loads from a global edge network, and it scales to a traffic spike without anyone getting paged.

What forces dedicated compute

Dedicated compute is a persistent instance that keeps running and keeps state between requests. You need it — not "might benefit from it," need it — the moment your app does any of the following:

• Runs its own server-side logic per request, not just templated pages
• Talks to a database it owns, rather than a third party's API
• Holds a persistent connection: websockets, queues, or a long-running job
• Needs scheduled or background work independent of any single visitor's request

None of that is exotic — it's most real applications. The tell is whether the app needs toremember or compute something between one request and the next.

The grey area

Most sites aren't purely one or the other. A marketing site with a contact form is still static — the form just posts to a small relay. A content site with a comments section, a login, or a checkout usually isn't static anymore, even if 95% of its pages are.

APIs, databases, and queues are exactly this grey area, and it's where a flat-quoted conversation beats a self-service calculator: describe what the app actually does and we'll design the instance size and any managed database around it, then quote one number for the whole thing.

A decision checklist

Content is the same for every visitor

Static. No per-request logic to run.

The app has its own login, database, or checkout

Dedicated. Something has to hold state and run logic.

You're not sure, or it's a bit of both

Describe the workload — we'll size and quote it, flat, either way.

You want to change your mind later

Fine either direction — moving from static to dedicated (or back) doesn't lock you in.

Not sure which side you're on? The selector walks this same question in three short questions and points straight at the right page.

The cost angle

Static hosting and dedicated compute are both priced as one flat monthly rate on therate card — no per-request billing to model in advance, and no surprise invoice for a traffic spike. If you'd rather see a number before talking to anyone, the self-serve estimator gives a live monthly total for either path.

Read the full breakdown of each on the static hostingand dedicated compute pages, or just describe the workload through the quote form and get a flat number back within a business day.