Choosing free website hosting for developers is easier when you start with what your site needs to do. A portfolio or documentation site can run on static files alone. A web app that renders pages on the server, handles form submissions, or calls private APIs needs server-side functionality too. GitHub Pages, Vercel, and Cloudflare Pages all support deployment from code, but their capabilities and free-plan restrictions differ.
This comparison explains how each service handles frameworks, backends, custom domains, bandwidth, and deployment. Free-plan terms and quotas can change, so treat plan details as a starting point and check each provider’s current documentation and pricing before launch.
Key takeaways
- GitHub Pages is a straightforward choice for static sites closely tied to a GitHub repository. It does not run your application’s server-side code.
- Vercel is designed for frontend frameworks and can also run functions, subject to plan limits and usage rules.
- Cloudflare Pages serves static sites and supports server-side code through Pages Functions, which use Cloudflare Workers.
- Custom domains are supported by all three, but you still need to own or register the domain and configure DNS.
- “Free” means subject to plan terms, usage limits, and provider policies—not a guarantee of unlimited hosting forever.
How to choose a hosting service
First, identify whether your site is static or needs a backend. Static sites consist of files such as HTML, CSS, JavaScript, and images. They can include browser-side interactivity, but the browser cannot safely store secrets or perform trusted server-side tasks. A site that needs private API keys, server-side rendering, or secure form processing needs a serverless function or another backend service.
Next, consider your workflow. Do you want a simple build from a GitHub repository, framework-aware previews for every change, or access to an edge runtime? Finally, estimate the traffic and build activity your project may need. A free tier that works for a class project might not fit a growing business.
GitHub Pages, Vercel, and Cloudflare Pages compared
| Consideration | GitHub Pages | Vercel | Cloudflare Pages |
|---|---|---|---|
| Best fit | Portfolios, project pages, documentation, and other static sites | Frontend applications and framework-based projects | Static sites and applications that use Cloudflare’s edge platform |
| Framework support | Works with static output; has built-in support for Jekyll. Other frameworks generally need a build step that produces static files. | Framework-aware deployments support many popular frontend frameworks; capabilities depend on the framework and project configuration. | Supports static build output from many frameworks; use Pages Functions for supported server-side routes. |
| Server-side functionality | No application server or serverless functions | Functions are available, with usage governed by the active plan and platform limits. | Pages Functions provide server-side code through Workers, subject to Workers limits and plan terms. |
| Custom domains | Supported; DNS and domain verification need configuration. | Supported; connect a domain and configure its DNS. | Supported; configuration depends on whether the domain is managed through Cloudflare or an external DNS provider. |
| Bandwidth | GitHub documents a soft bandwidth limit, commonly stated as 100 GB per month. Check the current Pages limits before relying on it. | Transfer is subject to plan quotas and usage rules. Do not assume it is unlimited. | Static asset bandwidth is advertised as unmetered on the free Pages offering; Functions and other services have separate limits. Verify the current terms. |
| Deployment | Publish from a branch or use GitHub Actions for a build workflow. | Connect a Git provider or use the Vercel CLI; deployments can be created for changes and branches. | Connect a Git provider for builds or use direct upload options; available workflows may vary by project setup. |
| Plan considerations | Has published site size, build, and bandwidth limits, plus policies about acceptable use. | Free-plan quotas and permitted use differ from paid plans; review current terms, especially for commercial projects. | Build and Functions limits apply even when static asset delivery is unmetered. Check current plan details for your use case. |
The table describes broad product differences, not a guarantee that every framework or deployment setup will work without configuration. Features and quotas may change, and particular builds can require extra setup.
GitHub Pages: a good home for static projects
GitHub Pages is a practical fit when your site can be published as static files and your code already lives on GitHub. It works well for personal portfolios, documentation, course projects, and project landing pages. A static site generator can create the files before deployment; Jekyll is supported by GitHub Pages, while other generators may need to build through GitHub Actions.
A typical workflow is to push changes to a repository, build the site if needed, and publish the resulting files from a configured branch or Actions workflow. You can attach a custom domain, but publishing a site does not include purchasing that domain.
The key limitation is that GitHub Pages does not run a general-purpose backend for your site. A JavaScript form in the browser does not become a secure server-side form handler merely because the site is hosted online. Use a separate backend service for trusted operations, and never put private credentials in files sent to visitors’ browsers.
GitHub Pages also has usage limits and acceptable-use policies. It is not a reason to assume that a project can serve unlimited traffic or operate as a free substitute for commercial application hosting.
Vercel: framework-aware deployment with functions
Vercel is often considered for frontend projects that benefit from framework-specific build handling and deployment previews. You can connect a supported Git repository or deploy with the Vercel CLI. A successful build can produce a deployable site, and supported projects can also use server-side or serverless functionality.
That flexibility comes with additional considerations. Functions, build activity, and data transfer are subject to plan limits. The free plan is not interchangeable with a paid production plan: check its current usage quotas and permitted-use terms before using it for a commercial project. If your app depends on a function or other platform feature, test that path rather than checking only that the homepage loads.
Custom domains are available, but you must configure the DNS records Vercel specifies. Domain setup and DNS propagation can take time, so keep the provider’s setup instructions handy when troubleshooting.
Cloudflare Pages: static delivery with an edge option
Cloudflare Pages can build and publish static sites from a connected Git repository, and it also offers direct-upload workflows. For projects that need server-side routes, Pages Functions run on Cloudflare Workers. This makes it possible to add backend behavior without treating the static site itself as a traditional server.
The distinction between static delivery and functions matters when you estimate usage. Unmetered static asset bandwidth does not mean every related service is unlimited. Functions, builds, and other platform capabilities can have their own quotas or plan conditions. Review those limits if your site relies on dynamic requests.
Cloudflare Pages supports custom domains. The DNS steps depend on your domain setup; follow the current instructions for your account and domain rather than copying records from another project.
A practical decision workflow
- List what the site must do. If it only serves built files, all three may be candidates. If it needs server-side rendering, form handling, or private API access, compare the available function runtimes and their limits.
- Check framework output. Confirm how your framework builds and where it writes the deployable files. For static hosting, the build output—not your source folder—is usually what gets published.
- Choose a deployment workflow. Pick repository-based builds for automatic deployments, or a CLI/direct-upload workflow if it better fits your project.
- Review current plan limits. Check bandwidth or transfer, build usage, function requests and execution, file or project restrictions, and the provider’s acceptable-use terms.
- Connect and test a custom domain. Verify DNS configuration, HTTPS availability, redirects, and both the root domain and any
wwwsubdomain you plan to use. - Test the deployed site. Check pages, assets, navigation, forms, and any function-backed routes on the public deployment. A successful build does not guarantee every runtime feature behaves as intended.
For a static site, inspect a URL’s components with a URL parser if you need to check that a link contains the expected scheme, host, path, or query string. Parsing a URL is a debugging aid; it does not configure DNS or secure a backend.
Common mistakes and troubleshooting
Assuming “static” means “no JavaScript”
A static site can include JavaScript that runs in a visitor’s browser. The limitation is that this code cannot safely keep secrets or perform privileged server-side work. Move those operations to a properly secured backend.
Publishing the wrong build directory
A framework may generate files in a folder such as dist, build, or another configured output directory. If deployment succeeds but the site is blank or missing assets, check the build command and published directory in the provider settings.
Treating preview deployments as production guarantees
A preview can help you review a change, but it may use different environment variables, domains, or settings from production. Test the production deployment and keep its configuration distinct from previews where appropriate.
Misreading bandwidth claims
Unmetered static file delivery is not the same as unlimited functions, builds, or database usage. Look at each service your application uses, and confirm what happens if a quota is reached.
Expecting a custom domain to work immediately
A domain can fail to load because DNS records are missing, incorrect, or still propagating. Confirm the exact records required by the host, remove conflicting records where appropriate, and allow time for DNS changes to take effect.
Recommendations before launch
- Keep secrets and private API keys on a server-side service, not in frontend code or public repository files.
- Use a custom domain you control and enable HTTPS through the provider’s supported setup.
- Monitor usage if the site attracts traffic or depends on server-side functions.
- Check current pricing, quotas, and acceptable-use terms before relying on a free plan for a public or commercial project.
- Keep a copy of your source code and build instructions so the site can be moved if your needs or the provider’s terms change.
Conclusion
For simple static projects, GitHub Pages can offer a direct path from a GitHub repository to a published site. Vercel is worth considering for framework-based apps and projects that use its function capabilities. Cloudflare Pages combines static hosting with an edge-function option. The right choice depends on your framework, backend needs, deployment workflow, and expected usage—not just the word “free.” Compare the current provider limits before you commit to a plan.