GitHub Pages Jekyll plugin whitelist limits custom plugins

Current process for adding a plugin

GitHub Pages does not expose a public form or API for extending the Jekyll plugin whitelist. The only way to have a plugin considered is to contact GitHub Support or open an issue in the github/pages-gem repository, where maintainers review the request for security and stability.

Likelihood of a user‑configurable whitelist

GitHub has not announced any plan to let Pages users supply a custom plugin list. The whitelist is maintained to guarantee safe, deterministic builds, so a feature that would allow arbitrary gems is unlikely in the near term.

Best‑practice patterns for sites that need non‑whitelisted plugins

• Limit the site to plugins that already appear on the whitelist (e.g., jekyll-redirect-from, jekyll-sitemap).
• Replace missing functionality with built‑in Jekyll features, Liquid filters, or client‑side JavaScript.
• If a plugin is essential, use a GitHub Actions workflow that runs jekyll build with the full Gemfile and pushes the generated _site folder to the gh-pages branch (or uses the pages provider). This bypasses the Pages Jekyll builder while still hosting on github.io.

Verification steps you can perform locally

1. Clone a test repo, enable GitHub Pages on the main branch, add a non‑whitelisted gem (e.g., a custom plugin) to _config.yml and Gemfile, push, and watch the Pages build log for a “plugin not allowed” error.
2. Create a minimal GitHub Actions workflow that checks out the code, sets up Ruby, runs bundle exec jekyll build, and uses the peaceiris/actions-gh-pages action to deploy the _site folder. Verify that the live site reflects the plugin’s output.