README.markdown

April 13, 2025 · View on GitHub

Drumknott

April 13th 2025

Sorry folks, Drumknott is no more - it was a nice little service, but never earned enough to pay for its own hosting. That's not terrible, but after coming across Pagefind, I realised I could just encourage migration to that, and save both myself and customers a little bit of money.

Stay safe out there, and look after each other! 🇵🇸🇱🇧🏳️‍⚧️🏳️‍🌈

Build Status Depfu

A simple Rails app that provides a search backend for Jekyll sites. It's available as a (cheap!) paid service at drumknottsearch.com, but you can fire up your own instance if you wish.

It expects both PostgreSQL, Redis and Sphinx to be available, and you'll need to run both a web process (currently Puma) and a worker process (Sidekiq). Stripe is used for payment processing, and Postmark for email delivery.

Environment Variables

Drumknott expects many environment variables to function:

  • BUGSNAG_API_KEY for tracking errors via Bugsnag.
  • DATABASE_URL which is the primary PostgreSQL database.
  • FLYING_SPHINX_API_KEY, FLYING_SPHINX_HOST, FLYING_SPHINX_IDENTIFIER, and FLYING_SPHINX_PORT courtesy of the Flying Sphinx add-on.
  • INVOICE_FROM which has the invoice issuer details (which is likely a multi-line value including the postal address).
  • NEW_RELIC_LICENSE_KEY for sending performance statistics to New Relic.
  • PAPERTRAIL_API_TOKEN for sending logs through to Papertrail.
  • POSTMARK_API_KEY, POSTMARK_API_TOKEN, and POSTMARK_SMTP_SERVER to manage outbound email through Postmark.
  • REDIS_URL for the Redis service used by Sidekiq.
  • SECRET_KEY_BASE for Rails' verification of signed cookies.
  • SIDEKIQ_USERNAME and SIDEKIQ_PASSWORD to control access to Sidekiq's dashboard.
  • STRIPE_PLAN_ID is the plan that is used for the subscription payments.
  • STRIPE_PUBLISHABLE_KEY and STRIPE_SECRET_KEY are the Stripe API credentials.
  • STRIPE_WEBHOOK_SECRET is used for authenticating webhook requests from Stripe.

Contributing

Patches are very much welcome - though if you're thinking about adding in a new feature, I recommend opening up an issue on GitHub to discuss things first to check if I have any feedback on implementation details and whether the feature is likely to be merged in.

All pull requests/patches should have tests unless there's a very good reason for not including them (for example: headless browser required for javascript processing). That said, if you've got a patch in mind but not sure how to test it, create a pull request and I'll happily provide some suggestions on where to start.

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

Licence

Copyright (c) 2016, Drumknott is developed and maintained by Pat Allan, and is released under the open MIT Licence.