Portfolio Website Hosting for Consultants: What You Actually Need

September 23, 2026 · 11 min read

Quick answer: A consulting portfolio needs almost none of what a hosting spec sheet is designed to sell. The whole site is a few megabytes of static files that get opened a few thousand times a month, so the specs that actually matter are narrow: a CDN with an edge close to your prospects, automatic TLS the platform renews for you, and a bandwidth ceiling generous enough to survive a spike. Every serious host clears that bar on a free or entry tier. Where the real decision lives is one level up, in the architecture — a managed builder that hides the infrastructure, a static site host you own the files on, or a serverless setup you operate yourself. This piece maps the six hosting specs a consultant actually needs to a plain-English score, then matches the three architectures to a consulting page's spiky-low traffic profile so you can pick without reading a datasheet. Once you have picked, the how-to for connecting your domain is the next step; the pay-once vs subscription argument is the parallel one on pricing.

Key Takeaways

Hosting a consultant portfolio is a small problem hosting providers price as if it were a large one. Six specs matter; the rest are decoration. Three architectures cover the entire real decision, and only one of them is wrong for most consultants.

The three architectures worth considering — managed builder, static site host, serverless or self-hosted — cover every legitimate option. The failure modes are different, and only one is a bad fit for almost every consultant on this page.

Table of Contents

• What "hosting" actually is for a portfolio site
• The consultant traffic profile (and why it changes what you need)
• The six hosting specs that actually matter
• The three real architectures
• The decision rule: matching architecture to your situation
• What can silently break your hosting
• When to move — and when to leave it alone
• Frequently asked questions
• Useful sources and further reading

What "Hosting" Actually Is for a Portfolio Site

Hosting is the service that answers when a browser asks for your site. That is the whole job. A visitor types your address, their machine looks up which server has your files, that server sends the files back, and the browser assembles them into a page. Everything a hosting provider sells beyond that — dashboards, staging environments, database plans, worker minutes, image transforms, edge functions — is optional machinery layered on top of that one core function.

For a consulting page, the core function is close to trivial. Your site is a small pile of static assets: HTML for a few pages, one stylesheet, a couple of scripts, some images, a favicon. Once those files exist, the work of serving them to a visitor is a solved problem that has been solved cheaply, in about a dozen different ways, by every serious infrastructure company in the world. The interesting question is not "which host is fastest" — the honest answer is that they are all indistinguishable at this scale. The interesting question is which set of tradeoffs — how much you own, how much you operate, how much you pay — matches the way your practice runs.

That framing matters because the industry sells hosting the other way around. A provider's marketing page is designed for a software company deciding where to run an application that has customers, uptime obligations, and revenue on the line. It lists CPU cores, memory ceilings, database transactions, and worker-minute quotas, and it hides the two numbers a static page actually cares about — global latency and the price of the gigabyte you serve after your first ten thousand. Reading a hosting datasheet as a consultant is like reading a commercial-truck brochure to buy a car. Nothing on the page is wrong; almost none of it is for you.

The Consultant Traffic Profile — and Why It Changes What You Need

Every hosting decision downstream of this section depends on being honest about the shape of the traffic your page actually gets. For most independent consultants it looks like this:

• Baseline is small. A working consultant page typically sees somewhere between 50 and 2,000 pageviews per month. The upper end is a practice that publishes regularly and shows up in search; the lower end is a page that lives at the bottom of an email signature and gets opened when someone was going to reply anyway.
• Traffic is spiky, not steady. The distribution is not a smooth line — it is quiet weeks punctuated by short bursts when a proposal goes out, a post lands, a newsletter cites you, or an existing client forwards the link to someone new. A single day can carry more traffic than the surrounding month.
• Every visit is expensive to you and cheap to the host. A single prospect landing on the page is worth more to your practice than the entire year's hosting bill. The reverse is also true: from the host's perspective, your page is a rounding error on their infrastructure, which is exactly why the free tiers are as generous as they are.
• Peak matters more than average. The failure mode that hurts is a page that goes slow or throws an error during the burst, not steady-state cost. A host that quietly throttles the free tier at 5,000 requests an hour will look great in every review and fail you the one day it matters.

What this profile rules out is anything priced for a steady-state workload — a dedicated server, a "small business" managed hosting plan, a fixed-CPU tier. Those are all designed for something running twenty-four hours a day. Your page runs when a visitor asks, which is not most of the time. What the profile rules in is anything that scales elastically at the edge: an object store behind a CDN, a static-site host, or a managed builder that runs on the same primitives with a UI wrapped around them.

The Six Hosting Specs That Actually Matter

Ignore the twenty specs on a provider's comparison page. These six cover the entire real decision for a consulting portfolio.

1. Bandwidth — measured in the wrong unit almost everywhere

Bandwidth is how much data the host lets you send out to visitors each month. It is almost always the number a shared-hosting salesperson leads with, and it is almost never the constraint that binds. A consulting page weighs 1 to 3 megabytes fully loaded, and the browser caches most of that on repeat visits, so a couple of thousand pageviews a month translates to somewhere between 2 and 10 gigabytes of egress. Every free tier on this list — Cloudflare Pages, Netlify, GitHub Pages, Vercel — publishes a monthly ceiling in the 100 GB range or advertises unmetered egress; the paid tiers extend that by an order of magnitude. Your baseline traffic will not touch the cap.

The trap is the moment you exceed it, because that is where providers stop competing on the sticker price and start competing on the per-gigabyte overage rate. AWS's public rate for CloudFront egress to the internet is $0.085 per GB in North America and Europe on the first ten terabytes a month, dropping in tiers below that; Cloudflare famously does not charge for egress on Pages. That gap only matters when a post travels — a single well-timed link on Hacker News or LinkedIn can push a static portfolio to 50 GB in an afternoon — but it is the difference between a $0 bill and a $4 bill, not the difference between $0 and $400. Watch the number, don't fear it.

2. Global latency and the CDN — this is the one that visibly matters

Latency is how long a visitor waits between clicking a link and seeing your page start to render. It has two components: the round trip between the browser and the server (physics — the speed of light in fibre, plus routing overhead) and the time the server takes to answer once the request arrives. A content delivery network fixes the first component by keeping copies of your files at points of presence around the world, so a prospect in Singapore reads from a machine in Singapore, not from your origin in Virginia.

The tangible target is a time-to-first-byte under 200 milliseconds worldwide, which is inside the range Google's Core Web Vitals guidance treats as good and the threshold below which a page feels instant to a human. Every serious static host in this category — Cloudflare Pages, Netlify, GitHub Pages, Vercel, Amazon CloudFront, Fastly — folds a CDN into the free tier by default; every managed builder in this category runs on top of the same infrastructure. You do not need to buy a CDN separately. What you need to check, once, is that the host has a point of presence in the regions where your prospects are — for most consultants that means at least North America, Europe, and one of Asia-Pacific or the Middle East, which every network on that list clears trivially.

3. Uptime SLA — what the number is, and what it isn't

An uptime service level agreement is the percentage of a billing period the provider commits to serving your requests. The industry shorthand — "three nines," "four nines" — is a compression of the following table, worth memorising because it decides how much you should care.

For a portfolio page whose worst outcome is a prospect refreshing the browser once, 99.9% is already comfortably over-specified — that is a ceiling of 43 minutes of downtime in a month, and a static site cached at the edge almost never gets close to it. Chasing four or five nines is engineering effort priced for a checkout page that loses revenue per minute. What matters more than the number itself is two things the marketing page usually omits: what the SLA actually covers (some exclude regional outages, planned maintenance, and events on their upstream network), and what the payout is when they miss it (the useful ones give service credit; the meaningless ones require you to file inside 30 days and cap at a fraction of the fee). Read the terms once and move on.

4. Storage and per-file asset limits

Storage is how much total data the host will keep for you, and asset limits are the maximum size of any single file. A consulting page fits inside both by a factor of ten. The whole site — HTML, CSS, JavaScript, a favicon, ten to twenty images — is rarely over 50 megabytes, and no individual file needs to be larger than 5 megabytes if the images are compressed properly. Free tiers on static hosts publish caps in the 1 GB total range and per-file limits in the 25 to 100 MB range. Managed builders don't publish the same numbers because they abstract them, but the practical ceiling is the same. The one place this pinches is if you plan to host a case-study video or a full-resolution slide deck on your own domain — at that point you either host the file on a separate object store (S3, R2, Backblaze) and embed a link, or you upload it to a video host and embed the player. Do not use a portfolio host as a general file store.

5. TLS and automatic HTTPS

TLS is the padlock in the address bar. Every serious host in this category now issues and renews certificates for free using the ACME protocol, most commonly through Let's Encrypt. The moment you connect a domain, the host requests a certificate, the domain owner (you, via DNS records) proves the domain is yours, the certificate authority signs a certificate valid for 90 days, and the host installs it and renews it automatically before it expires. This whole chain, invisible when it works, is one of the few genuinely important pieces of hosting for a consulting page — a "Not Secure" warning in a prospect's browser is a first-impression failure the copy cannot recover from. The only decision to make is a small one: whether you want the host to force redirect HTTP to HTTPS by default (you do) and whether you want to preload HTTP Strict Transport Security (probably not — it is a one-way commitment that removes an escape hatch you may want later). Every reputable host defaults both of these sensibly.

6. Egress, requests, and the pricing surface after the free tier

The last spec is the one hosting comparison articles most consistently omit. Free and entry tiers are almost identical on the six items above; where they diverge sharply is at the boundary — what you pay per gigabyte of egress, per million requests, per invocation, per second of edge-function CPU, once you cross the included threshold. Two competing providers can publish identical free tiers and hand you a 10x difference in bill at 100 GB. Cloudflare's stated policy is no egress charge on Pages regardless of traffic; the major cloud providers meter egress precisely and price it per gigabyte with tiers that step down at terabyte breakpoints. For a consulting portfolio this delta is a rounding error 99% of the time, but it is the one that turns into a surprise on the month a post travels. Look it up once, note whether the host charges egress at all, and set a billing alert.

The Three Real Architectures

The six specs above are the shopping list. The choice you actually make is which kind of host handles them for you. Three real options exist, and they trade against each other on a single axis: how much of the operating burden lives with you versus the provider.

Architecture 1: Managed builder hosting

The category most consultants land on without knowing they made an architectural choice. Squarespace, Wix, Webflow, Framer, Carrd, Seera, and every builder in the same category run your page on their infrastructure, on their domain by default, with the six specs above handled invisibly and set to sensible defaults. You do not choose the CDN or the region or the TLS renewal schedule; they are made for you, correctly, and their support team is on the hook when something breaks. The tradeoff is that you do not really own the files — you own the content that produced them, and export options range from thorough (Framer, Ghost) to minimal (many hosted page-builders return a proprietary format that runs nowhere else). For a page you never intend to migrate, that tradeoff is invisible; for a page you might want to move to a different tool in five years, it is a real cost paid quietly in future-you's time.

What managed hosting is good at: getting the site to production in an afternoon, keeping it healthy for years with no operational work from you, absorbing spikes without ever surfacing the underlying scaling to a user. What it is not good at: giving you an escape hatch, letting you tweak headers or edge behaviour, keeping infrastructure decisions in your name. For a consultant whose hourly rate is far higher than any subscription line item, this is almost always the right architecture — the labour saved dwarfs the platform lock-in cost. Seera fits this shape deliberately; so do the mainstream competitors listed in the consultant builders roundup.

Architecture 2: Static site hosting

You still don't run a server, but you own the files. You (or an AI) write the HTML, CSS, and JavaScript; you push them to a static host — Cloudflare Pages, Netlify, GitHub Pages, Vercel; the host serves them from an edge CDN, issues a TLS certificate, and bills you effectively nothing for a portfolio-sized site. The six specs above are cleared by default. The operating burden is small but not zero: you are on the hook for anything the platform can't do for you, which for a consulting page is mainly editing the files when your positioning changes, and re-deploying. That last part is a drag-and-drop or a git push, not a real barrier.

What static hosting is good at: absolute floor on cost, honest ownership of the artifact, portability (the files are yours, the host is a commodity you can leave in an afternoon), best-in-class performance because there is literally nothing to compute at request time. What it is not good at: dynamic behaviour without extra plumbing (a contact form needs a serverless function or a third-party form service), non-technical content updates (there is no CMS unless you bolt one on), and abstracting away the concept of a build step. This is the architecture the no-subscription path ends up choosing implicitly; it is also what most managed builders quietly run on underneath.

Architecture 3: Serverless or self-hosted

You rent primitives from a cloud provider and assemble the hosting yourself. Two flavours: serverless, where you drop your static files into an object store (S3, R2, GCS, Azure Blob) and put a CDN in front of it (CloudFront, Cloudflare, Fastly, Google's edge), paying per gigabyte and per request; or self-hosted, where you rent a virtual private server or a container and run a web server (nginx, Caddy) that answers requests directly. Both give you every knob a hosting platform has, at the price of turning every knob into a decision you now own.

What this architecture is good at: full control, compliance-grade auditability, integration with a broader cloud footprint you already run for other reasons, price optimisation at scale far past what a portfolio page will ever produce. What it is bad at: everything about being a consultant. You are now the operator — TLS certificate rotation, OS patching, security groups, backups, log retention, uptime monitoring, incident response. All of that is a real ongoing cost of your time. For the roughly zero consultants whose portfolios have a legitimate reason to live inside a specific AWS account, this is the right answer; for everyone else it is a category error dressed up as sophistication.

"When you're building for scale, every layer of the stack is a decision — data store, compute, network, cache, security. But when the workload is a static page, the mistake most people make is bringing all those decisions to a problem that doesn't have them. The best hosting for something small is the one that stops asking you questions."

The Decision Rule — Matching Architecture to Your Situation

Three architectures, one rule of thumb. Rank your priorities in the order below and let the first one that has a hard answer decide.

1. How much do you value your own time? If a spare Saturday afternoon costs you more than a year of hosting fees — which is true for every consultant billing above roughly $50/hr — architecture 1 (managed builder) is the default answer and you can stop reading here. The operational burden it takes off your plate is the whole point.
2. Do you need to own the files as an artifact? If the answer is yes — because the content is genuinely portable, or because the practice includes technical prospects who will inspect the site's markup, or because you want the ability to walk away from any vendor with an hour's notice — architecture 2 (static site) is the honest choice. You will spend one afternoon setting it up and never think about hosting again.
3. Does the portfolio have to run inside a specific cloud or compliance boundary? If yes — and this is a narrower set of situations than most people think, usually restricted to consultants working in defense, health, or financial services with contracts that pin infrastructure to a named region or account — architecture 3 (serverless or self-hosted) is the only option that fits. Otherwise it is the wrong answer.

The failure mode this rule is designed to prevent is the middle-tier one: a consultant who picks architecture 3 because it feels more serious, spends 20 hours over the first month wrangling nginx and Let's Encrypt automation, and ends up with a page that is worse on every measurable spec than the free tier of a static host would have given them in ten minutes. Sophistication in hosting is not a virtue; it is a bill.

What Can Silently Break Your Hosting

The specs above are what you shop on. The failure modes below are what will actually catch you out, and none of them show up on a comparison page.

• Free-tier throttling on burst. Some free tiers do not just cap your monthly total; they cap your concurrent requests or your requests per hour, and they enforce it by returning HTTP 429 to visitors once you cross the threshold. That failure looks like your page being down to the exact people who found you interesting enough to click. Read the rate-limit section of the terms; the number to check is requests per hour, not gigabytes per month.
• Certificate renewal that fails when your DNS is misconfigured. ACME renewal requires the host to prove control of your domain every few months. If you moved your DNS provider and forgot to re-add the record the host uses for validation, renewal quietly fails and the certificate expires on a schedule you did not choose. The tell is a "Not Secure" warning that shows up 90 days after a DNS change, not right after. A calendar reminder to load the site cold every 60 days catches it.
• A CDN outage on top of an origin outage. The reason a static site at the edge stays up so reliably is that even when your origin server is unreachable, the CDN serves the last cached copy. What that argument doesn't cover is the day the CDN itself has a regional incident — most operators eventually publish one — during which the edge and the origin both drop for the same visitors. There is no fix on your side; the mitigation is to accept that a portfolio page is not worth engineering around this and to reload it once after any large-scale internet incident.
• A managed builder deprecating a feature you depended on. Not a hosting failure per se, but the same shape. A hosted platform can change a template, remove an export option, or migrate your account onto a different pricing tier with 30 days notice. The mitigation is to keep an offline copy of the content — the raw text and images — separate from the platform, so a forced migration is a rebuild in a new tool, not a rescue of lost material. Do this for any platform that owns your files today.

When to Move — and When to Leave It Alone

Most consultants change hosts too often and rebuild too often. The base rate should be: pick one architecture, stay on it until something concrete breaks or something concrete opens up. Concrete reasons to move:

• The current platform announces a policy change that specifically affects you — a pricing tier that no longer includes what you were using, an export path that is being removed, a domain-connection method that is being deprecated.
• Your practice has changed shape enough that the current platform's feature ceiling has become the bottleneck — for example, a solo consultant who becomes a small firm and needs multi-editor workflows, or a page that has grown from three case studies to twenty and now needs a real CMS.
• The current platform has a repeated failure in production that support cannot resolve, measured over months not days. One outage is a bad afternoon; three in a quarter is a signal.

Reasons that look like they are asking you to move, and are not: a friend picked a different builder and likes it; a hosting article ranked your current platform below its competitor; a new host offered a discount for the first year that expires before the second. All three are common; none are load-bearing arguments. Migrating a portfolio takes a real weekend and pauses the practice-facing work you would otherwise be doing, so the bar for change should be higher than "I saw a review."

Frequently Asked Questions

What hosting does a consultant portfolio website actually need?

Very little, in absolute terms. A consulting page is a handful of HTML pages, a stylesheet, and maybe a dozen images — the whole site typically weighs 2 to 10 megabytes and serves a few hundred pageviews a month, with rare spikes when a proposal goes out or a post lands. Any serious host — a managed builder, a static site host, or a small serverless setup — clears that bar on a free or entry tier. The specs that actually matter for that shape of traffic are three: a content delivery network with an edge close to your prospects (so time-to-first-byte stays under about 200ms), automatic TLS with a certificate the platform renews for you, and a bandwidth ceiling generous enough to survive a viral post. Everything else on a typical hosting spec sheet — dedicated CPU, database transactions, worker minutes — is priced for applications a consultant page is not.

Is a CDN necessary for a portfolio website?

Yes, and you almost certainly already have one without paying for it. A content delivery network caches your files at points of presence around the world so a prospect in Dubai isn't waiting for a round trip to a server in Virginia every time they open your page. Cloudflare, Fastly, Amazon CloudFront, and Google's edge network all fold a CDN into their free or entry hosting tiers by default; the same is true of every managed builder in this category. The tangible effect is a first-byte time in the 50 to 200 millisecond range worldwide, which is inside the threshold Google's own Core Web Vitals guidance treats as good. Where a CDN stops being a nice-to-have and becomes load-bearing is on a page a stranger opens from a mobile network in a country you don't live in — which is exactly what happens when a post travels.

What uptime SLA is good enough for a consulting portfolio site?

For a page whose worst outcome is a prospect refreshing the browser once, a 99.9% service level agreement is already overbuilt — that is roughly nine hours of allowed downtime a year, and a static portfolio page hosted on a serious provider almost never gets close to it. Chasing 99.99% (about 53 minutes a year) or 99.999% (about five minutes) makes sense for a checkout page that loses revenue every minute it is down, not for a page that mostly gets opened after someone has already agreed to a call. What matters more than the raw number is what the SLA actually covers and what it pays out — most consumer hosts publish a target without a credit, and a static site cached at the edge often keeps serving even when the origin is unreachable, so the effective uptime is higher than the paper number suggests.

Should a consultant self-host their portfolio on a VPS or dedicated server?

Almost never. A virtual private server or dedicated box is priced and operated for applications that need a running process — a database, a queue, a real-time service. A consultant portfolio is static content, so paying for a machine that idles 99% of the time buys you nothing except a maintenance burden: operating system patches, TLS certificate renewal, firewall rules, log rotation, backups, uptime monitoring. If a page ever goes down at 2am the day of a pitch, none of that is worth the $5 to $20 a month a VPS would have saved over a managed or static host. The narrow case where self-hosting makes sense is when you are already running other services on the same box and the portfolio is a rounding error on top, or when a compliance requirement pins your infrastructure inside a specific data boundary.

How much bandwidth does a consultant portfolio website use in a month?

Far less than any free tier caps you at. A well-optimised consulting page is roughly 1 to 3 megabytes over the wire on first load, and closer to a few hundred kilobytes on repeat visits because the browser caches the static assets. At a couple of thousand pageviews a month — which is already more traffic than most consultants see outside a viral moment — you are looking at 2 to 10 gigabytes of egress, comfortably inside the 100GB/month range most free tiers publish and orders of magnitude below the terabyte thresholds where cloud providers start billing for egress. The number to actually watch is not monthly bandwidth; it is the price per gigabyte the moment you go over, because that is where a busy hosting-provider spec sheet quietly hides a surprise bill.

Related Reading

• How to Connect a Custom Domain to Your Consulting Portfolio
• Portfolio Builders Without a Subscription: Do They Work for Consultants?
• Cheapest Portfolio Builders With Free Custom Domain
• Best Affordable Portfolio Website Builders for Consultants
• Best Portfolio Builders for Consultants (2026)
• How Much Does a Consultant Portfolio Cost? (By Build Route)
• What Makes a Consulting Portfolio Professional? A No-Fluff Checklist
• Consultant Portfolio Example — Section-by-Section Breakdown
• Portfolio Builder for Consultants
• Resume to Website (Seera)

Useful sources and further reading

• Google web.dev: Core Web Vitals — the definition and published thresholds for LCP, INP, and CLS referenced in the CDN/latency section, including the "good" cutoff of 2.5 seconds for Largest Contentful Paint
• Cloudflare Pages documentation — the free static-host tier used as the "architecture 2" reference, including its stated no-egress-charge policy and the request/build minute limits worth checking before you commit
• Let's Encrypt: how it works — the ACME certificate issuance flow every managed host uses under the hood; the "TLS and automatic HTTPS" section above is a plain-English gloss of this document
• Amazon CloudFront pricing — the published per-gigabyte egress rates cited in the bandwidth section; useful as a reference point for comparing any host that does meter egress against one that doesn't
• AWS Well-Architected Framework — the operational-excellence pillar the blockquote in "The Three Real Architectures" section is adapted from; a longer, more general framing of the "match the machinery to the workload" argument
• Seera: Resume to Website — the managed-hosting path referenced above; parses a CV into a full consultant page on a real domain, with CDN, TLS, and everything in the six-specs list handled by default
• Seera: Pricing — the all-in subscription referenced above ($5.99/mo or $4.99/mo billed annually), which bundles custom domain, hosting, and no watermark