Free Website Hosting: What Is Actually Free and What It Really Costs

Short answer. There is no single thing called free hosting — the term hides three different products. Static hosting from Git (GitHub Pages, GitLab Pages, Cloudflare Pages, Netlify, Vercel) is genuinely free, but has no PHP and no MySQL. Free plans from ordinary hosters give you PHP and a database, but with hard limits, injected ads and a third-level domain. Cloud free tiers are free until the quota runs out, then the bill starts.

Three classes of free hosting and how they differ

Search results for free hosting mix incompatible products on one page. Before comparing anything, sort the options into three buckets — they have different economics, different limits and different ways of letting you down.

1. Static hosting from Git. You push HTML, CSS, JS and images to a repository, the platform builds them and serves them from its CDN. The free part is honest: serving static files costs the provider very little, and you bring your projects into its ecosystem. The limitation is structural — the server never executes your code.
2. A free plan from an ordinary hoster. The same shared hosting as the paid one, with trimmed limits: disk, CPU time, number of databases, number of outgoing emails. You pay with ads injected into your pages, a third-level domain, and the upgrade pressure the limits are designed to create.
3. Cloud free tiers. A virtual machine, object storage or a container within a starter quota or trial period. Almost no technical limits — you get a real server. The limit is temporal and metered: quota exhausted or period over, billing begins.

Comparing these classes in a single table of features is meaningless: the first has no backend, the second has no freedom, the third has no permanence. We take each apart below, then bring them together in one comparison.

Static hosting from Git: free, but without PHP and MySQL

This is the only class where the word free needs no asterisk. The model is simple: repository, build step if needed, then delivery of finished files from a CDN. A free plan usually includes a custom domain via CNAME or ALIAS, an automatic TLS certificate, HTTP/2 or HTTP/3, edge caching, and reasonable quotas on bandwidth and build minutes.

What you get

• Speed that paid shared hosting rarely matches: files are served from the nearest point of presence, and TTFB does not depend on how busy your neighbours are.
• Publishing you cannot break: the site is a commit, a rollback is git revert, and your backup is the local clone of the repository.
• Almost no application attack surface: no PHP means no vulnerable plugin, no admin panel means nothing to brute-force.
• Branch previews: most such platforms spin up a separate URL for every pull request.

What you do not get

• Server-side PHP, Python or Ruby. No index.php, no WordPress or similar CMS in its usual form.
• MySQL or PostgreSQL. There is no database at all. You take a separate managed service and talk to it from the browser or from a function.
• Mail on your domain. A static platform is not an MX host. Email stays a separate service, with MX records pointing wherever they normally would.
• Arbitrary server rules. Redirects, headers and rewrites are declared in the platform configuration file, not in .htaccess, and you are limited to what the platform supports.

The first point is partly solved by serverless functions: most platforms include a call quota on the free plan. That covers a contact form or a proxy to an external API, but not a shop with a cart and user accounts.

Selection rule: if the whole site can be described as a set of files that are identical for every visitor, static hosting from Git will do the job better and more reliably than any free shared plan. The moment you need the server to show different things to different users, this class is out.

Free plans from ordinary hosters: where the price is hidden

Everything looks familiar here: control panel, file manager, PHP, a database, FTP. And immediately the caveats begin — the ones rarely printed in large type on the landing page.

The usual set of limits

• Third-level domain. Your site lives at something like mysite.platform.tld. Connecting your own domain is often a paid-plan feature.
• Provider ads. A banner or a script is injected into your HTML on the fly. You do not control what loads, where visitor data goes, or what it does to Core Web Vitals.
• Shutdown on inactivity. No login for N days and the site is suspended, then deleted. This is one of the most common ways people lose a project overnight.
• Hard CPU-time limits. A CMS on a free plan hits the ceiling easily and starts returning 503 exactly when three visitors arrive at once.
• No backups. Or backups on request with no guarantee. There is nothing to restore and nobody to ask.
• No SLA. Formally the provider owes you nothing: the service is free, so downtime cannot be compensated.
• Support as an afterthought. Free-account tickets are handled last, if at all.
• Old PHP and trimmed extensions. If the module you need is missing, there is no way to add it.

Shared IP and the reputation of your neighbours

Free platforms attract spam, phishing and doorway pages. Your site shares an IP address with hundreds of other projects, and the reputation of that address is shared too. The consequences: form notifications land in spam, some corporate firewalls block the domain, and reputation databases may flag the whole range. You can check this before you commit — see the verification section below.

Cloud free tiers: free until the quota runs out

The third class is not hosting in the everyday sense but infrastructure: a virtual machine, object storage, a container platform, functions. Free comes in two flavours here, and confusing them is expensive.

Flavour	How it works	What happens next
Trial period	Full access for a fixed term or up to a starter credit	When the term ends, resources stop or start billing at the normal rate
Perpetual quota	A small permanent allowance: instance hours, storage gigabytes, request counts	Anything above the quota is billed automatically, usually without a separate confirmation

The danger of a free tier is not the limit itself but the absence of a hard stop. Bot traffic, logging left switched on, or a forgotten backup in object storage will push a project past its quota quickly. Set budget alerts on day one, before you publish the site.

Also remember that a cloud VM gives you bare Linux. Updates, firewall, TLS certificates, log rotation and monitoring are all yours. That is a plus for a test environment and a minus for someone who just needs a working website.

What you actually pay with

Here is everything in one table. Use it as the main reference: look at the row labelled main risk, not at the disk quota.

Property	Static from Git	Free hoster plan	Cloud free tier
PHP and server-side code	No; partly covered by serverless functions within a quota	Usually yes, but an old version with trimmed extensions	Yes, you install the stack yourself
MySQL / PostgreSQL	No; an external managed database is required	Often one database with size and connection limits	Yes, but a managed database is almost always outside the free quota
Mail on your domain	No	Sometimes, with message limits and weak deliverability	No; outbound SMTP on ports 25/587 is often blocked
Custom domain	Yes, via CNAME or ALIAS	Often paid-plan only, otherwise a third-level domain	Yes
HTTPS and headers	Automatic certificate, headers set in the platform config file	Certificate may be paid-plan only; headers usually not editable	Full control, you configure everything
Ads in your HTML	No	Sometimes, injected by the provider on the fly	No
Backups and SLA	Backup is your repository; no SLA, but rollback is instant	Usually neither	You make backups yourself; SLA does not cover free resources
Main risk	Hitting the missing-backend wall and rewriting the site	Shutdown on inactivity, shared IP on block lists, data loss with no backup	A bill after the quota or the trial period ends
Good for	Landing page, portfolio, documentation, generated blog	Study project, draft, temporary business card page	Test environment, MVP, infrastructure experiments

The costs nobody lists

• Time. Working around the limits of a free platform burns more hours than a year of normal hosting is worth.
• Visitor data. Provider ad injections are third-party scripts and cookies on your domain. You are accountable for them to the visitor, but you do not control them — and under GDPR that accountability is not rhetorical.
• Domain reputation. Sharing an IP with doorway pages and phishing affects email deliverability and how filters treat your domain.
• Exportability. If the site was built in the platform's own editor, taking it away is often impossible: you get flattened HTML with no sources and no data.
• The account as a single point of failure. An automated account suspension kills the site, the third-level domain and access to your files at the same moment.

Red flags of free forever platforms

• No public page describing when accounts are suspended and deleted.
• No way to download all files and a database dump in one operation.
• A mandatory branded script or banner that cannot be removed.
• Custom domains not supported at all, not even for money.
• No SSH or SFTP access — a web file manager only.
• Certificates issued only for the platform domain, with no HTTPS on yours.
• Terms that reserve the right to place ads and share visitor data with partners.
• No contact channel except a form, and no legal entity named anywhere.

Free domain and hosting: why the domain matters more

A free domain almost always means a third-level name such as mysite.platform.tld. Technically it works. Strategically it is the worst available decision, for several reasons.

• The address is not yours. The second-level domain platform.tld is registered to the platform. Your mysite is just a record in its DNS zone, removable at will.
• You cannot take it with you. Subdomain transfers do not exist. When you leave, the address changes completely — and the accumulated inbound links and search history of that address stay behind.
• Redirects would have to live on someone else's territory. If the platform gives you no way to set a 301, search engines will see two separate sites for years.
• Reputation is shared. Penalties and flags earned by neighbouring subdomains partly spill over onto the whole zone.
• Mail and trust. An address on a third-level domain reads as a temporary project and converts worse.

The correct order is: your own second-level domain first, then any platform — free included. A domain is cheap, lives for years and moves between hosts in a couple of hours. Hosting is a consumable; the domain is an asset.

If you already own a domain, connecting it to a free static platform takes one DNS record — details in the guides on connecting a domain to hosting and choosing a domain name. To confirm the records have spread worldwide, use the DNS propagation check.

A site without a backend: forms, search and comments on static

The main practical objection to static hosting is the contact form. It is solvable, with caveats worth understanding in advance.

Forms

Three options: a third-party form handler (the POST goes to someone else's domain), your own serverless function on the same platform, or a small service on a cheap VM. The markup does not change — only the action does.

<!-- form on a static site: the handler lives on a third-party domain -->
<form method="post" action="https://forms.example-handler.tld/f/abc123">
  <input type="email" name="email" required>
  <input type="text" name="_gotcha" tabindex="-1" autocomplete="off">
  <textarea name="message" required></textarea>
  <button type="submit">Send</button>
</form>

Check three things before launch: where the data physically goes, whether the handler has anti-spam that does not rely on third-party cookies, and whether the extra domain breaks your content security policy. A hidden honeypot field filters out primitive bots for free.

Search

For a site of up to a few hundred pages, client-side search over a prebuilt index (a JSON file generated at build time) is faster than a server-side one. Beyond that, use an external search service. Server-side full-text search on static hosting is impossible by definition.

Comments

Either an external comment service, or discussions in the repository issue tracker, or no comments at all. Every option means either third-party scripts on the page or a missing feature.

Every third-party handler is one more domain receiving your visitors' data and one more point of failure. For a site that collects personal data this is not a technical detail: the handler becomes your data processor, with the contractual and disclosure duties that follow.

When free hosting is a reasonable choice and when it is not

Reasonable

• A landing or business-card page with no forms collecting personal data: contacts, description, map, call button.
• Portfolio and personal sites — static fits this job perfectly.
• Documentation for a project or product: a static generator plus Git hosting is the industry standard, not a compromise.
• Test environments and branch previews: show a mockup to a client, run checks, publish a demo.
• A weekend MVP whose job is to test a hypothesis, not to survive load.
• Learning projects: getting a site published without spending money.

Not acceptable

• Online stores. Cart, stock, payments, receipts — all server-side logic and other people's money. Downtime on a platform with no SLA equals lost orders.
• Any processing of personal data. Lead forms, user accounts, bookings. Under GDPR you need a processor agreement, a documented legal basis, defined retention and a known jurisdiction for the data. A free platform with no contract and no clear data location gives you none of that.
• Anything involving payments. Payment gateways expect HTTPS, reliable webhooks and control over the server.
• A corporate site with mail on the domain. Deliverability from a shared free-platform IP is predictably poor.
• Projects where continuity matters. If one day of downtime costs more than a year of hosting, the free option makes no economic sense.
• Sites that already have traffic. Moving to a platform with no control over headers and redirects is a voluntary loss of rankings.

Migrating from free to paid hosting without losses

Leaving a free platform differs from a normal migration in one way: you often do not control the old side. You cannot set a 301, cannot change headers, cannot export sources. That makes the order of operations more important than speed.

1. Export

Take everything before touching anything. Files over SFTP if it exists, otherwise mirror the rendered HTML. The database as a dump from the panel. Save the list of URLs too — you will need it for the redirect map.

# mirror the public version of the site when there is no SFTP access
wget --mirror --page-requisites --adjust-extension \
     --convert-links --no-parent \
     https://mysite.platform.tld/

# full URL list from the sitemap — the basis of the redirect map
curl -s https://mysite.platform.tld/sitemap.xml \
  | grep -oE 'https?://[^<]+' | sort -u > old-urls.txt

2. Lower the TTL in advance

A day before the switch, reduce the TTL of A and CNAME records to 300 seconds. Otherwise part of your visitors will keep hitting the old address for as long as the current TTL says.

# current TTL of the record (the first number in the answer line)
dig +noall +answer mysite.tld A

# who is authoritative for the zone and with what parameters
dig +noall +answer mysite.tld NS
dig +noall +answer mysite.tld SOA

# after the switch, compare answers from different resolvers
dig @8.8.8.8 +short mysite.tld A
dig @1.1.1.1 +short mysite.tld A

3. Build the new site before switching

Deploy on the new host and verify it through a temporary address or a local hosts entry. Pointing DNS at an unverified copy guarantees downtime.

4. 301 redirects

If the old address was on your own domain, add permanent redirects on the new server and keep them for at least a year. If the old address was the platform's third-level domain, a redirect is only possible through the platform's own tools — which often do not exist. In that case the only remaining options are a refresh meta tag and a canonical link on the old pages, and only if the platform lets you edit HTML at all.

# nginx: permanent redirect from the old host to the new one, preserving the path
server {
    listen 443 ssl;
    server_name old.mysite.tld;

    ssl_certificate     /etc/letsencrypt/live/old.mysite.tld/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/old.mysite.tld/privkey.pem;

    return 301 https://mysite.tld$request_uri;
}

# inspect the redirect chain without downloading response bodies
curl -sSIL https://old.mysite.tld/page/ | grep -iE '^(HTTP/|location:)'

5. Sitemap and reindexing

Update sitemap.xml and robots.txt at the new address, submit the sitemap in webmaster consoles, and check for broken links and unnecessary redirect chains. The full sequence is in the website migration checklist. Verify the result with the redirect checker and the broken link checker.

6. Watch it for two weeks

Keep availability, status codes and speed under observation. Most migration problems surface not at the moment of switching but a few days later, when resolver caches expire and crawlers revisit.

How to verify a free hosting platform

Before publishing a project on a free platform — and again right after — run four checks. They take minutes and reveal exactly what the provider does not advertise.

Speed and TTFB

Free shared plans are usually oversubscribed: a TTFB in the hundreds of milliseconds and unstable response times are normal for them and a problem for you. Measure as a series, not once, and compare against your current platform.

# break the request down into stages
curl -o /dev/null -s -w \
'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' \
https://mysite.platform.tld/

# ten measurements in a row show the spread, not one lucky result
for i in $(seq 1 10); do
  curl -o /dev/null -s -w '%{time_starttransfer}\n' https://mysite.platform.tld/
done

For an online measurement broken down by stage, use the website speed test.

SSL and the certificate chain

A common picture on free plans: the certificate is issued only for the platform domain, while your domain gets a mismatched certificate or an incomplete chain. Browsers show a warning and crawlers simply do not come in.

# issuer, subject and validity dates of the presented certificate
openssl s_client -connect mysite.tld:443 -servername mysite.tld \
  </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -dates

# full chain: there must be more than one certificate
openssl s_client -connect mysite.tld:443 -servername mysite.tld -showcerts \
  </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE'

Faster online: the SSL certificate checker; common failures are covered in SSL error diagnostics and in the guide to free Let's Encrypt certificates.

Shared IP reputation

Find out which IP the platform serves from and check it against block lists and reputation databases. That is also the explanation when form notifications end up in spam.

Tools: the IP address check and the malware and block list check. While you are there, look at which security headers the platform returns and whether it injects third-party scripts into the response — HTTP header analysis.

Availability over time

A one-off check proves nothing: free platforms fail intermittently and put inactive sites to sleep. Set up uptime monitoring and look at a week or two of history — that is the only honest way to evaluate a platform with no SLA.

Frequently asked questions

Is there free hosting for a PHP and MySQL site?

Yes, but only in the second class — the free plans of ordinary hosters. Expect an old PHP version, trimmed extensions, one database with a size cap, a CPU-time limit and no backups. That is enough for a study project or a draft, not for a working site. On static hosting from Git, PHP and MySQL do not exist at all.

What does free hosting forever actually mean?

Usually that the base plan is free under the current terms, which the provider may change. Forever is never a contractual obligation in a service you do not pay for. If the suspension and deletion policy is not documented anywhere, assume the site can disappear at any moment and keep a full copy yourself.

Is game server hosting the same thing?

No, it is a different service. A game server — for Minecraft, for example — needs a permanently running process, a lot of RAM, arbitrary TCP/UDP ports and low latency. Web hosting serves HTTP on ports 80 and 443 and is built for short requests. Free game platforms run on their own economics: slots, servers sleeping when empty, ads in the lobby. It has nothing to do with publishing a website — if such offers show up in your search results, that is just noise around the word free hosting.

Can I move off free hosting and keep my rankings?

If the site was on your own second-level domain, yes: only the IP changes and page URLs stay the same. If it was on the platform's third-level domain, every URL changes, and without correct 301s from the old ones the accumulated history and inbound links do not carry over. That is exactly why the domain should be registered before publishing, not after.

Are free cloud hosting and a free tier the same?

Practically yes: free cloud hosting normally means a starter quota or trial period at a cloud provider. The difference from a hoster's free plan is that you get a real server and full control — along with full responsibility for updates, firewall, certificates and backups. And that the free part ends on a meter, not on a policy.

Does free hosting make sense if the site is built in a website builder?

Free builder plans belong to the same second class with all its properties: third-level domain, forced branding, limited export. The key question before starting is whether you can take the site and its data with you when you leave. A comparison of approaches is in the review of website builders.

Checklist before publishing on free hosting

• You identified the class: static from Git, a free hoster plan, or a cloud free tier.
• You confirmed the class covers what the site actually needs — especially the presence or absence of server-side code and a database.
• You registered your own second-level domain and connected it before any traffic arrived.
• You found the terms covering inactivity shutdown, data deletion and the right to place ads.
• You verified that all files and a database dump can be exported in one operation — and did the export.
• You measured TTFB as a series rather than a single request — speed test.
• You checked the certificate and chain completeness on your own domain — SSL check.
• You checked shared IP reputation and block list status — IP and malware check.
• You reviewed which headers and third-party scripts the platform adds to responses — HTTP headers.
• You set up uptime monitoring and have been watching the platform for at least two weeks.
• You keep personal data, payments and orders off the free platform.
• You already know where you will move if the project grows — selection criteria in how to choose hosting and in the review of hosting providers.