RubyEvents.org indexes Ruby conferences, meetups and talks

An index of Ruby events, formerly RubyVideo.dev

RubyEvents.org, previously named RubyVideo.dev, exists to index Ruby related events and videos from conferences and meetups around the world, and the README credits pyvideo.org as the inspiration. That framing explains the shape of the project. It is a catalogue, not an event platform. There is no ticket sales, no attendee accounts, no schedule conflict detection, no CFP workflow. What it does is collect a large number of scattered things, mostly recorded talks from community events, and give them a searchable home with enough metadata to browse. The audience for the software is therefore two different groups. The end users are Ruby developers looking for a talk to watch or a conference to attend. The actual users of the codebase are contributors, and the README is unusually blunt about how the project expects to be extended: adding more content is called the most direct way to contribute, and the running site has a contributions page listing the remaining known TODOs so a newcomer can pick an item and start. That is a sensible posture for a data project where the bottleneck is coverage rather than code.

Solid Queue and Solid Cache keep the job on a single SQLite file

The stack is current Rails rather than a legacy one. The README names Hotwire, Solid Queue and Solid Cache as the pieces the project is built with, and the top level of the repository backs that up with the expected Rails layout, including app/, config/, db/, lib/, test/, storage/, a Gemfile, a Rakefile, a config.ru and a Procfile.dev. Solid Queue is the background job backend, which matters a lot for this kind of site because pulling in videos and enhancing talk metadata is slow, network bound work that has no business running inside a web request. Solid Cache handles caching. Both live inside the application, so there is no separate Redis or Memcached to operate. The database is SQLite, and the README says so plainly: the deployment is a Hetzner VPS with Kamal and SQLite as the main database. Read that as a deliberate small scale choice. A single file database with a single server is cheap and simple for a mostly read-heavy catalogue, and it is also a ceiling: writes are serialised through one file, background jobs and web requests share the same box, and there is no path to horizontal scaling without moving off SQLite. The repository also carries docker-compose.typesense.yml, which shows the same pragmatic approach to the search dependency.

Vite, Tailwind, daisyUI and Stimulus own the front end

The front end is a separate build pipeline rather than Rails asset pipeline. The README says Vite, Tailwind with daisyUI components and Stimulus are used, and the package manifest confirms the versions and the rest of the client side stack: Turbo Rails and the Hotwire native bridge for navigation, request.js, chart.js with chartkick for charts, maplibre-gl for maps, splide for carousels, vlitejs for video playback, tippy.js for tooltips and flag-icons for country flags. The npm scripts show how the pieces are driven:

    "build": "bin/vite build",
    "lint": "standard",
    "format": "standard --fix",

The package manager is pinned in the same file:

  "packageManager": "[email protected]",

Two consequences for a contributor. First, a Rails developer who expects a single command to serve the app will find a second toolchain, a yarn install and a Vite build that has to be run before the assets appear. Second, the presence of maplibre-gl and chart.js says the site is a browsing experience with a map and per-event statistics, not a plain list, and that is a lot of client side code to keep working across the browsers the project chooses to support. The README notes that for compatible browsers it demonstrates the Page View Transition API, which is a progressive enhancement: on browsers that support it the navigation animates, and on the others the site still works, just without the effect. It is a good example of using a modern API where it helps and degrading quietly where it does not.

Typesense carries the search in the cloud or on your laptop

Search is not a database feature here. The README credits Typesense for sponsoring a Typesense Cloud instance that powers the search functionality, and the repository carries a docker-compose.typesense.yml file for running a node locally. The .env.sample describes both arrangements. For local development, a single node, the defaults are:

TYPESENSE_HOST=localhost # optional, defaults to localhost
TYPESENSE_PORT=8108 # optional, defaults to 8108
TYPESENSE_PROTOCOL=http # optional, defaults to http

For production with multiple nodes, the sample file points at the Typesense Cloud service domain format and shows how the port and protocol change for a TLS endpoint on 443. The split between a local single node and a hosted multi node cluster is the kind of detail that usually appears only after a first deployment, so it is worth reading before you set up search. It also tells you something about the scale of the site: one hosted instance with several nodes is enough for an index of conference talks, and that in turn shapes the rest of the deployment, since a managed search cluster is the one part of the stack the VPS does not host. A contributor running the app locally therefore needs a Typesense node before the search box will do anything, and the .env.sample comments make each setting optional with a stated default, which means an unset key silently falls back to localhost.

Deploying with Kamal and a production-only Dockerfile

The Dockerfile is explicit about its purpose. Its own comment says it is designed for production, not development, and that it is meant to be used with Kamal or built and run by hand. The base image is pinned to a Ruby version, and that Ruby version comes from an argument:

ARG RUBY_VERSION=4.0.6
FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base

The comment adds that RUBY_VERSION must match the Ruby version in .ruby-version, which is the kind of detail that breaks a build quietly when it drifts. The build then installs system packages for native gems and image work, installs a pinned Node version and a pinned Yarn version, and copies the Gemfile, Gemfile.lock and .ruby-version before running bundle install. The final image sets RAILS_ENV to production, enables bundle deployment mode and excludes the development group, and a separate build stage is used to keep the runtime image smaller. The comment in the Dockerfile gives the build command used by hand:

# docker build -t rubyevents .

The run command in the Dockerfile comment expects a RAILS_MASTER_KEY value taken from config/master.key and publishes port 80, and the .env.sample marks KAMAL_RAILS_MASTER_KEY and KAMAL_REGISTRY_PASSWORD as required to deploy with Kamal. So the deployment path is: build the image, hand it the master key, let Kamal roll it out to the Hetzner VPS. A dev container is available as a separate option, and the Dockerfile points to the Rails dev container guide rather than trying to serve both purposes from one file.

Adding an event is the contribution the project wants first

The contributing guide is linked from the README as CONTRIBUTING.md, and a code of conduct is released with the project, which tells you something about how the maintainers run it. The mechanics of adding content are not in the README, so a first contribution is a read of the guide and of the site. Two repository directories point at where the work happens: content/ and data/. There is also a scripts/ directory, and the .env.sample reveals a pipeline that is worth understanding before you touch it. Two variables point at design files rather than credentials, which is unusual and useful to know:

SKETCH_FILE=./RubyEvents.sketch # path to the sketch file used for extracting the event assets
SKETCH_STAMPS_FILE=./RubyEvents_Stamps.sketch # path to the sketch file used for extracting stamps

The rest of the .env.sample maps the optional integrations. GEOLOCATE_API_KEY loads geolocation, MAPBOX_ACCESS_TOKEN drives the map views in the Avo admin, OPENAI_ACCESS_TOKEN and OPENAI_ORGANIZATION_ID power a talk enhancement feature, RUBYVIDEO_GITHUB_TOKEN is described as useful for a profile enhancement feature, YOUTUBE_API_KEY is for scraping YouTube videos, and GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET enable GitHub login, with a developer OAuth login as the fallback. Every one of these is marked optional, and the comments say the app runs without them. That is the honest shape of the project: the core catalogue works with no third party keys, and the enrichment features light up one by one as credentials arrive. Note the leftover RUBYVIDEO prefix on the GitHub token variable, a reminder that the rename from RubyVideo.dev only partly reached the configuration.

Where RubyEvents is the wrong tool, and what a static build changes

Several cases do not fit. If you want a list of conferences with no server, this is the wrong shape, because the site is a Rails application with a database, a job queue, a search index and a client build, and the repository carries a Dockerfile, a Kamal setup and a dev container to prove it. If you need ticketing or registration, nothing in the project points that way. If you need editorial workflows with drafts, review and scheduled publication, the visible tooling is an admin interface plus a data directory, and the README does not describe a publishing workflow for non-technical editors. If you need a site that survives a viral spike, a single VPS with SQLite behind it is the architecture, so the ceiling is the machine rather than the code. The alternative worth weighing is a different architecture rather than a different project: generate a static site from a content folder and serve the output from a CDN. The static build does the expensive work once, at build time, and the result is a set of files that cost nothing to serve and cannot go down, while the Rails index does the work on demand and can accept new content without a deploy. Search is where the two diverge most sharply, since a static site needs a client side index or a hosted search service, and a Rails app with Typesense gets ranked results as a side effect of already holding the data. Choose the static build when the catalogue is small and mostly final, and the running index when content arrives continuously, needs ranking, and must be editable by people who do not use git. There is also a maintenance pattern to notice. The site relies on hosted services for search and, optionally, for geolocation, maps, YouTube and GitHub data, so a deployment inherits several rate limits and API contracts that a self-contained application would not. The README does not document a fallback path when one of those services is unavailable, and it does not document a backup or restore procedure for the SQLite database, which is the single file that holds the catalogue.

MIT licence, no releases, and a last push on 2026-10-20

The README states that RubyEvents.org is open source and available under the MIT License, with details in the License file, and the repository carries a LICENSE.md at the top level. The licence field in the repository settings is empty, so treat the file in the repository as the authoritative statement rather than the metadata. MIT is a permissive grant with no copyleft obligations, which suits a community project that others may fork and extend. On maintenance, the repository is not archived and the last push was on 2026-10-20, so work is landing on the main branch as of that date. There are no GitHub releases, which means there is no version to pin, no published container image and no changelog of upgrades. You deploy from a branch, so your upgrade cost is a pull, a bundle and yarn install, a Vite build, a container build and a test pass, and the risk of an unexpected change arriving on main is part of that cost. The repository also carries a CHANGELOG-adjacent habit of keeping open work visible on the site itself, with a page listing the remaining known TODOs, which tells you that the queue of work is public and additive rather than hidden in issue trackers. A fork that wants to move faster should copy that pattern and keep its own content directory as the source of truth.

Editorial conclusion

Adopt RubyEvents.org as a reference implementation for a community content index built on Rails with a search engine, a background job queue and a hot deploy story, and as a starting point if you want to run the same site on your own infrastructure. Do not adopt it if you need a static site, a ticketing system or a content model you can edit without a Rails console, because the application assumes a running server, a database and a search index. Verify three things first: the licence file, since the README calls the project MIT while the repository licence field is empty, the key set in .env.sample, because several features degrade to disabled without their API keys, and the SQLite assumption, since the deployment runs on a single Hetzner VPS with SQLite as the main database.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. rubyevents/rubyevents on GitHub