Most articles about hosting a Jekyll site stop at one sentence: GitHub Pages is free and built in, so use that. This is true and also incomplete in a way that causes real problems for anyone whose site grows past a simple personal blog. GitHub Pages runs Jekyll through a restricted, whitelisted plugin list for security reasons, silently ignores any plugin outside that list rather than erroring out, and enforces limits on repository size and build frequency that are rarely mentioned until a site owner hits one of them.
This gap between what Jekyll can do and what GitHub Pages will actually run matters more today than it did in Jekyll’s early years, precisely because Jekyll’s plugin ecosystem has grown considerably since the whitelist was first established, while the whitelist itself has grown far more slowly and conservatively. A developer researching Jekyll plugins today will find dozens of actively maintained options solving problems GitHub’s own whitelist has no equivalent for, and nothing in a typical plugin’s own documentation warns that it will be silently ignored the moment it is deployed to GitHub Pages rather than a general-purpose static host, which is precisely the gap this article exists to close.
This article covers hosting for Jekyll and static site generators more broadly, specifically the tradeoff between GitHub Pages’ built-in convenience and the fuller control offered by dedicated static hosting platforms like Netlify and Cloudflare Pages. That means covering exactly which Jekyll plugins GitHub Pages supports versus silently drops, the specific limits on repository size and build time that matter for a growing site, custom domain and SSL handling differences, build minutes and bandwidth on the paid alternatives, and which setup makes sense for a law firm or agency site built with Jekyll rather than a purely personal blog. If your research so far has only surfaced “just use GitHub Pages, it’s free,” this article picks up exactly where that advice runs out.
The plugin whitelist problem nobody mentions upfront
Jekyll’s real power comes from its plugin ecosystem, which extends the core generator with features like SEO tag generation, sitemap creation, feed generation, and pagination logic that would otherwise require manual configuration. GitHub Pages runs Jekyll in a special safe mode for security reasons, and that safe mode only permits a specific, published whitelist of plugins, currently a few dozen, dominated by Jekyll’s own official plugins like jekyll-seo-tag, jekyll-sitemap, and jekyll-feed, plus a handful of well-known third-party additions.
The security reasoning behind this restriction is worth understanding rather than dismissing as arbitrary bureaucracy. GitHub Pages builds millions of sites automatically from arbitrary user-submitted repositories, and an unrestricted plugin system would mean running arbitrary, potentially malicious Ruby code on GitHub’s own build infrastructure every time someone pushed a commit. Restricting builds to a vetted, security-reviewed plugin list is a reasonable tradeoff from GitHub’s side, protecting its infrastructure at the cost of flexibility for site owners who want to use a plugin outside that reviewed list. Understanding this tradeoff does not make the limitation any less inconvenient in practice, but it does explain why GitHub has been conservative about expanding the whitelist over time rather than opening it up more broadly as the plugin ecosystem has grown around it in the years since the restriction was first put in place.
The dangerous part of this limitation is not that it exists, it is how it fails. If a Jekyll site’s configuration references a plugin outside the whitelist, GitHub Pages does not throw a build error clearly stating the plugin is unsupported. Instead, the build either silently skips the plugin’s functionality or, in some cases, fails in a way that produces a generic build log error that does not clearly point to the plugin as the root cause. A site owner who installed a popular but non-whitelisted plugin locally, saw it work perfectly in local development, and then pushed to GitHub Pages expecting the same result is a genuinely common pattern of confusion, since the local Jekyll build has no restriction on which plugins run, while the GitHub Pages build silently enforces one.
This confusion is compounded by the fact that many Jekyll tutorials, courses, and third-party plugin documentation are written without any mention of GitHub Pages’ restrictions at all, since the tutorial author may have only ever tested locally or deployed through a different hosting method. A developer following a well-written, technically accurate tutorial can do everything correctly and still end up with a broken deployment purely because the tutorial itself never mentioned that the specific plugin being taught falls outside what GitHub Pages will actually execute. This is precisely the kind of gap that a comparison focused purely on Jekyll’s features, rather than on the realities of a specific hosting platform’s restrictions, will never surface for a reader.
The practical workaround many developers use is running Jekyll’s build step themselves through GitHub Actions rather than relying on GitHub Pages’ native, restricted build process. This approach still deploys the final static output to GitHub Pages for hosting, but the actual site generation happens in a GitHub Actions workflow with full, unrestricted access to any plugin the Gemfile specifies, since GitHub Actions runs the build in a general-purpose environment rather than Pages’ locked-down build sandbox. This is the single most useful piece of information missing from most beginner-level Jekyll hosting guides, since it resolves the plugin limitation entirely while still keeping the site on GitHub’s free hosting infrastructure, at the cost of a slightly more involved initial setup than simply pushing to a repository and letting GitHub Pages handle everything automatically.
Setting up this workflow in practice involves adding a YAML configuration file to the repository’s .github/workflows directory that specifies the Ruby version, installs the project’s Gemfile dependencies including any non-whitelisted plugins, runs the Jekyll build command directly, and then deploys the resulting static output folder to GitHub Pages using an official deployment action. This is a one-time setup cost per project rather than an ongoing maintenance burden, and once configured, every future push to the repository triggers the same unrestricted build automatically, functioning almost identically to the default GitHub Pages experience from the site owner’s perspective, just without the plugin restriction sitting invisibly underneath it.
A concrete example of a popular plugin that falls outside GitHub Pages’ default whitelist is jekyll-archives, used to automatically generate archive pages by category, tag, or date, a feature many blogs and documentation sites rely on for content organization and internal linking structure. A site owner who wants this specific functionality has exactly two realistic paths: manually building the archive pages by hand, which defeats much of the purpose of using a static site generator in the first place, or adopting the GitHub Actions build workflow described above to run the plugin as intended. This single example illustrates why the plugin whitelist issue is not a theoretical edge case affecting only obscure or unusual plugins, but a real limitation that touches genuinely common, widely used Jekyll functionality that many site owners reasonably assume will simply work once deployed, particularly since the plugin itself is well documented, actively maintained, and installs without any error or warning during local development.
Repository size and build limits GitHub Pages does not advertise prominently
GitHub Pages imposes a soft repository size recommendation of 1GB, and while sites can and do exceed this without an automatic hard failure, GitHub explicitly reserves the right to limit or disable sites that grow unreasonably large or generate excessive traffic relative to what a free service is intended to support. For a Jekyll site consisting mostly of text content and a reasonable number of optimized images, this ceiling is rarely a practical concern. For a documentation site with hundreds of embedded diagrams, a portfolio with high-resolution photography, or any site that has grown organically over years without periodic asset cleanup, it is worth periodically checking actual repository size rather than assuming a free hosting tier has no meaningful limit at all.
A repository approaching this soft limit is not necessarily in immediate danger of being disabled, since GitHub’s enforcement in practice has historically been lenient and reserved for genuinely extreme outliers rather than a strict, automated cutoff at exactly 1GB. The more immediate practical problem for a growing repository is Git’s own performance rather than GitHub’s policy enforcement: a large repository with years of binary image history accumulated in its commit log becomes noticeably slower to clone, pull, and push, since Git tracks every version of every committed file by default rather than only the current state. A site owner who has never needed to think about Git repository hygiene before can find themselves dealing with sluggish local development workflows long before GitHub’s own size policy becomes the actual limiting factor, simply because years of uncompressed image uploads have bloated the repository’s underlying Git history far beyond what the current live site actually needs to display, a problem that periodic use of Git’s history-rewriting tools can address but that is far easier to avoid in the first place through disciplined image compression practices from day one.
Build frequency and duration carry similar unadvertised limits. GitHub Pages historically recommended keeping builds to roughly 10 per hour and imposed an unofficial 10-minute build timeout, both of which matter more for a site with a large number of pages or a complex asset pipeline than for a simple blog with a few dozen posts. A site that starts timing out during Pages’ own automatic build process, without ever seeing a clear, specific error message explaining why, is frequently running into either this timeout or the plugin whitelist restriction described earlier, and switching to a GitHub Actions-based build workflow resolves both problems simultaneously, since Actions workflows have considerably longer default timeout allowances and no plugin restriction at all.
It is worth being specific about why build time grows nonlinearly as a Jekyll site scales, since this is not simply a matter of more pages taking proportionally more time. Jekyll’s default build process regenerates the entire site from scratch on every build rather than incrementally rebuilding only the pages that changed, meaning a site with 500 pages does not take roughly 500 times as long as a 1-page site, but the relationship is close enough that a documentation site or blog that has accumulated several thousand posts over years of publishing can genuinely start bumping against a 10-minute ceiling that felt comfortably distant when the site had a few dozen pages. This is precisely the kind of limit that a growing site discovers gradually and then suddenly, since each individual post added has a negligible incremental effect on build time until the cumulative total crosses the threshold where the whole build simply stops completing in time.
Comparing this to a generator like Hugo is instructive, since Hugo is frequently recommended specifically as a Jekyll alternative for exactly this reason: Hugo’s Go-based architecture builds even very large sites in a fraction of the time Jekyll’s Ruby-based build process requires, which is why sites approaching Jekyll’s practical build time ceiling sometimes migrate to Hugo rather than simply switching hosting platforms. This is not a recommendation to abandon Jekyll for every large site, since Jekyll’s more approachable templating syntax and larger beginner-friendly ecosystem remain genuine advantages for many teams, but it is worth knowing that a persistent build timeout problem has more than one possible solution: changing the hosting platform’s build environment, as described above, or in more extreme cases reconsidering whether Jekyll itself remains the right tool once a site has grown large enough that build time has become a recurring operational headache rather than an occasional inconvenience worth tolerating for the sake of Jekyll’s other genuine strengths.
Related comparisons on this site:
1. NameHero vs Hostinger: performance compared
2. Cloudways vs SiteGround: cloud hosting compared
3. SpinupWP vs Cloudways: WordPress VPS compared
4. Namecheap vs Porkbun: domain registration compared
5. RunCloud vs Cloudways: managing a DigitalOcean VPS
Netlify and Cloudflare Pages: what the paid alternative actually buys you
Netlify and Cloudflare Pages both host static sites built by any generator, Jekyll included, with a fundamentally different build model than GitHub Pages. Rather than running Jekyll in a restricted safe mode, both platforms execute the build command specified in the project’s own configuration inside a general-purpose build environment, meaning any Jekyll plugin listed in the project’s Gemfile runs exactly as it would in local development, with no whitelist to work around and no silent plugin-skipping behavior to debug.
This difference in build philosophy is worth stating plainly: GitHub Pages restricts what code can run during the build for security reasons specific to its role as a mass-market, zero-configuration hosting service for arbitrary public repositories. Netlify and Cloudflare Pages, by contrast, are built around the assumption that the site owner controls and trusts their own build configuration, since these platforms are not attempting to offer the same zero-configuration, security-sandboxed experience GitHub Pages provides by default. Neither approach is objectively wrong, they are simply solving for different priorities, and understanding which priority matters more for a specific project is the actual decision being made when choosing between them, not simply a comparison of which platform is more feature-rich in the abstract.
Netlify’s free tier includes 300 build minutes per month and 100GB of bandwidth, which comfortably covers most small business and agency sites, along with features GitHub Pages does not offer natively: branch deploy previews that generate a unique preview URL for every pull request before it merges to the live site, serverless functions for handling forms or small dynamic features without a separate backend, and built-in redirect and header configuration through a simple file rather than requiring a workaround. The deploy preview feature in particular changes the practical workflow for any team larger than a single developer, since a content editor, a client stakeholder, or a second developer can review a proposed change on a live, fully functional preview URL before it ever touches the production site, catching layout issues or content mistakes in a realistic environment rather than only in a local development setup that may not perfectly match production.
Cloudflare Pages offers a broadly comparable free tier with unlimited bandwidth specifically, which is a meaningful advantage for a site that expects unpredictable traffic spikes, such as a firm whose blog post occasionally goes viral within a specific professional community, since Netlify’s bandwidth allowance on the free tier can be exceeded by a genuinely large traffic spike in a way Cloudflare’s unlimited allowance cannot. Cloudflare Pages also benefits from sitting directly on Cloudflare’s own global content delivery network, the same infrastructure that powers a significant share of the internet’s overall traffic routing, which gives it a genuinely large, mature edge network without needing to layer a separate CDN service on top the way some competing platforms require for equivalent global performance.
Build minute allowances on both platforms’ free tiers are worth monitoring for any site with a genuinely large number of pages or a complex asset optimization pipeline, since a slow, resource-intensive build can consume a meaningful share of a monthly allowance surprisingly quickly if the site rebuilds automatically on every single commit rather than being batched or triggered more deliberately. For most small business, agency, and professional services sites, which tend to publish new content at a modest, predictable cadence rather than committing dozens of times per day, this is rarely a practical concern, but it is worth understanding as a real resource with a real ceiling rather than treating free-tier build minutes as an unlimited resource that never needs any monitoring at all over the life of a growing site.
Custom domain and SSL handling is straightforward and free on all three platforms, GitHub Pages, Netlify, and Cloudflare Pages, each provisioning a free SSL certificate automatically once a custom domain’s DNS is pointed correctly. The meaningful difference shows up in DNS propagation speed and certificate provisioning reliability, where Cloudflare’s own DNS infrastructure gives Cloudflare Pages a natural advantage for anyone already using Cloudflare for their domain’s DNS, since certificate provisioning and CDN routing happen within the same infrastructure rather than requiring a separate CDN layer on top. A site already using Cloudflare as its DNS provider before choosing a hosting platform will generally find Cloudflare Pages the more seamless option purely on this integration point alone, independent of any other feature comparison between the platforms.
Global edge performance is worth a brief separate mention, since a static site’s core selling point is speed, and the choice of hosting platform genuinely affects how consistently that speed holds up across different visitor locations. GitHub Pages serves content from Fastly’s content delivery network, which is a mature, well-regarded CDN in its own right, so GitHub Pages is not a slow option by any reasonable measure. Netlify and Cloudflare Pages both also run on globally distributed edge networks, and in practice the differences between all three for a typical text-and-image static site are small enough that build and workflow features, rather than raw edge performance, are the more decisive factor in choosing between them for most small business and agency use cases, with performance itself rarely being the deciding factor once all three platforms are already fast enough to satisfy any reasonable visitor expectation.
Which setup makes sense for a law firm or agency site
A purely personal blog or a small open-source documentation site with modest traffic and simple content needs is well served by GitHub Pages using the default whitelisted plugin set, since the zero-configuration deployment directly from a Git push remains the lowest-friction option available for that specific use case. The moment a site needs a specific SEO or feed plugin outside the whitelist, expects meaningful image-heavy content growth over time, or is being built professionally for a client who expects a certain level of reliability and support responsiveness, the calculus shifts toward either a GitHub Actions-based build feeding into GitHub Pages, or moving the whole project to Netlify or Cloudflare Pages directly.
For an agency building a Jekyll-based marketing or documentation site on behalf of a law firm client specifically, Netlify or Cloudflare Pages is generally the more defensible choice over relying on GitHub Pages directly, for reasons beyond the plugin whitelist alone. Both platforms provide a dashboard interface non-technical stakeholders can use to view deploy status and roll back to a previous version without needing to understand Git directly, branch deploy previews that let a client review a proposed content change before it goes live on the production domain, and considerably clearer build error reporting when something does go wrong, compared to GitHub Pages’ more opaque build log output. For a client relationship where the agency needs to hand off some level of visibility or control to the client’s own staff, this dashboard-based workflow is a genuinely practical advantage that GitHub Pages’ git-only interface does not offer.
There is also a professional perception dimension worth naming directly, even though it is not a technical limitation in the strict sense. A law firm client reviewing their own agency’s technical choices may reasonably ask why their production website is hosted on GitHub Pages, a platform whose name and branding are strongly associated with software development and open-source code repositories rather than professional business websites. This is not a fair criticism in a purely technical sense, since GitHub Pages’ underlying infrastructure is entirely capable of serving a professional site reliably, but client perception is a real factor an agency has to manage, and a Netlify or Cloudflare Pages deployment, or a deployment behind a fully custom domain with no visible platform branding at all, avoids this particular conversation entirely, letting the agency’s technical choices stay invisible to a client who understandably cares more about the finished result than the underlying infrastructure decisions behind it.
Migration between these platforms, should a project’s needs change after launch, is generally low-friction precisely because all three host the same static output from the same Jekyll source repository. A site initially launched on GitHub Pages for its zero-configuration convenience can typically be repointed to Netlify or Cloudflare Pages later by connecting the same Git repository to the new platform and updating the domain’s DNS records, without needing to rebuild the site itself from scratch. This makes the initial hosting choice lower stakes than it might otherwise feel, since a site is rarely permanently locked into its first hosting decision, though avoiding an unnecessary migration by choosing the more appropriate platform from the outset still saves the DNS downtime and configuration effort a later switch requires, along with the small window of mixed old and new DNS records propagating simultaneously that can briefly confuse visitors or search engine crawlers hitting the domain during the transition period itself, an outcome worth avoiding through upfront planning rather than accepting as an unavoidable cost of a later platform change.
For an agency managing several client sites built on Jekyll or a similar static site generator, standardizing on a single hosting platform across the whole client portfolio, rather than choosing case by case, generally pays off in reduced operational overhead. A consistent deployment process, a single set of build configuration conventions, and a single platform’s dashboard and support documentation to become genuinely expert in, compounds into meaningfully faster troubleshooting and onboarding for new team members compared to supporting a mixed environment where every client site sits on a different hosting platform with its own quirks and configuration patterns to remember. This standardization also pays off directly during a client onboarding conversation, since being able to say “every site we build follows the same proven deployment process” is a stronger answer than needing to explain, case by case, why one client’s site is hosted differently than another’s for reasons that may not be obvious or reassuring to someone without a technical background evaluating the agency’s overall competence and consistency.
Sources and references consulted: supported plugin list, Jekyll pagination, GitHub Pages limits, Cloudflare DNS, Git push deployment, pages.github.com, netlify.com, pages.cloudflare.com, static site reliability.
