The Exercism website: a Rails application with a deliberately closed contribution door

Public source, closed door, and the reason to read it anyway

The first thing the README says is a notice, and it is the most important thing in the file.

Please note: This repo is an internal repo. That means the source code is public, but we do not accept Pull Requests, we do not support the app being run locally, and we do not encourage people to fork or reuse this repository.

So the repository is not a community project in the usual open source sense. There is no contribution path, there is no support commitment for local development, and reuse is actively discouraged. The topic list reflects this with a single tag, community-contributions-paused.

That makes the question of who it is for a different one. It is not for contributors, because there is no contribution workflow. It is not for people who want to run their own Exercism, because reuse is discouraged and the local setup is unsupported. It is a public window onto the implementation of a large Rails application serving a community of people learning to program, and the audience is engineers who want to read it.

The project itself is described plainly: this is the website component of Exercism, a Ruby on Rails app backed by various other services. The homepage is exercism.org, the primary language is Ruby, and the licence is AGPL-3.0, with the licence file named LICENCE.md at the root.

The AGPL matters for anyone tempted to lift code from it, and it is worth pairing with the README's discouragement. AGPL-3.0 reaches network use: a modified version offered over a network comes with source obligations. That is a much heavier constraint than the MIT or Apache terms most people would assume from a Rails application, and it aligns with the maintainers' stated preference that you not reuse this repository.

The last push was on 2026-10-22, and the repository has no GitHub releases. So this is a codebase that is being worked on, published for reading, and deliberately not published for reuse.

The service list is the real architecture diagram

The prerequisites section lists what a local setup needs, and the list is more informative than any architectural description would be.

Ruby 3.3.0, with a note that for other Ruby versions you change the version in the Gemfile and the .ruby-version files. MySQL. MongoDB. Redis. AnyCable-Go, which is the Go implementation of the AnyCable websocket server. And Docker.

That is five stateful or infrastructure dependencies behind one Rails application, and it tells you a lot about what the application does. MySQL holds the relational core, MongoDB holds the document-shaped parts, which in a learning platform is a natural fit for exercise content, solution documents and anything with a flexible schema. Redis carries the ephemeral and queueing state. AnyCable provides the websocket layer that a live editor and a browser-based test runner need in order to report back without polling.

AnyCable is a specific and telling choice. The Rails 7 console section notes that the console has autocomplete that can be very frustrating, which is a detail that dates the Rails version, and the package manifest confirms the JavaScript side with @rails/actioncable and @hotwired/turbo-rails and @hotwired/stimulus, so the front end is the Hotwire stack rather than a separate SPA framework.

The JavaScript side is where the exercise tooling lives. The manifest lists CodeMirror with language modes for C++, CSS, Go, Java, JavaScript, PHP, Python, Rust and YAML, plus @exercism-specific packages for Arturo, Gleam, Jikiscript, Uiua and Wren, and highlight.js packages for Arturo, Futhark, GDScript, Jikiscript and Uiua. There is @exercism/javascript-browser-test-runner, @exercism/active-background, @exercism/html-to-image and @exercism/twine2-story-format.

That list is the clearest statement of what Exercism has become. It is not only a list of exercises in many languages. It also runs tests in the browser, supports a Twine-based story format, highlights several more niche languages, and uses html-to-image so a learner can capture and share their work.

Standing up the local stack takes Docker, localstack and opensearch

The setup instructions are honest about their own reliability. They are instructions to get things working locally, and while you are welcome to try and follow them, the README provides no guarantee of things working on your specific local setup.

The database comes first, and the SQL is given in full so you get a working setup rather than a schema to reverse engineer.

CREATE USER 'exercism'@'localhost' IDENTIFIED BY 'exercism';
CREATE DATABASE exercism_development;
ALTER DATABASE exercism_development CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
GRANT ALL PRIVILEGES ON exercism_development.* TO 'exercism'@'localhost';

Then the local AWS, because to run the app you must have a local version of AWS running. The project uses localstack and opensearch, and runs them via Docker, with the versions pinned and listed in .dockerimages.json.

docker run -dp 3042:8080 -p 3040:4566 -p 3041:4566 localstack/localstack:2.3.2
docker run -dp 9200:9200 -e "discovery.type=single-node" opensearchproject/opensearch:2.11.0

The pinned versions are the detail to note. localstack 2.3.2 and opensearch 2.11.0 are fixed images, and the README tells you to double check versions in .dockerimages.json. So the documented setup corresponds to a specific moment, and anyone following it later should check those pins before assuming the commands still work.

The port mapping on the localstack container is also more interesting than it looks: 3042 to 8080, and 3040 and 3041 both to 4566, which is the localstack edge port. That is a deliberate arrangement for reaching different localstack endpoints from the host, not an accident.

The setup script then configures the application against your setup.

bundle install
EXERCISM_ENV=development bundle exec setup_exercism_config
EXERCISM_ENV=development bundle exec setup_exercism_local_aws

And the README attaches a warning that carries more weight than a typical note: you will need to do this every time you reset dynamodb, which happens when Docker is restarted. So the local AWS state is not durable, and the setup has to be repeated after every Docker restart. Anyone planning to work against this stack needs to know that before they lose an afternoon.

The process manager differs per platform, and the port is fixed at 3020

Running the local servers is done through a Procfile, which executes the various commands needed to run Exercism locally. The recommendation differs by operating system.

On MacOSX the recommendation is hivemind, which can be installed via brew install hivemind.

hivemind -p 3020 Procfile.dev

On Unix systems the recommendation is overmind.

overmind start --port 3020 --procfile Procfile.dev

And on Windows the recommendation is WSL, so you follow the Unix instructions. The port is 3020 in both cases, so the two managers are interchangeable on that axis, and the difference between hivemind and overmind is in how they handle process output and restarts rather than in what they run.

The reason for a Procfile at all is worth noting. A Rails application of this size has several processes: the web server, the job queue worker, the websocket server and probably a scheduler. Running them through a single process manager with one Procfile is how you get all of them up together with one command, which is the difference between a workable local environment and a pile of terminals.

Two smaller setup notes close out the environment. The Rails 7 console has autocomplete that can be very frustrating, and the fix is to append a line to your irbrc file.

echo 'IRB.conf[:USE_AUTOCOMPLETE] = false' >> ~/.irbrc

And for editor support, the Solargraph gem is in the file, with solargraph.useBundler needing to be set to true in the configuration, plus two commands to prepare the yard documentation index.

The platform-specific dependency lists are also in the README. On Mac the main dependencies can be installed via homebrew, and the Unix instructions give an apt-get line for Ubuntu covering software-properties-common, libmariadb-dev, cmake, ruby-dev, ruby-bundler and ruby-railties, plus nodejs and yarn. Windows users are pointed at WSL.

Rubocop, Rails tests and a separate Jest suite for the browser tests

The code standards and testing sections are conventional for a Rails application with a JavaScript front end, and they tell you how a change gets checked.

Rubocop is enforced on pull requests, and the local invocation excludes the Metrics group.

bundle exec rubocop --except Metrics

Adding the -a flag autoupdates based on its suggestions. And to check the complexity of your code and ensure you are not adding things that are more complex to the codebase, you run without the --except flag.

bundle exec rubocop -a

The exclusion of Metrics by default is a signal about the project's priorities. The style cops are the ones you want running on every save, and the complexity metrics are the ones you look at deliberately when the codebase is already large.

The Ruby tests run through Rails.

bundle exec rails test

And there is a second, separate suite in Jest for the browser side, which matters because the JavaScript in this repository is not just a build step. It is the in-browser test runner that executes a learner's solution and reports the result back, which is the part of the product that no amount of Ruby test coverage would exercise.

yarn test [path/to/file]

Omitting the path runs all tests, and snapshots are updated with a different flag.

yarn test [path/to/file] -- -u

Snapshot testing in a browser test runner is a reasonable choice, since the output of a test run is structured and stable enough to compare, but it does mean a change to the runner's output format breaks snapshots across the suite.

One more piece of local tooling is documented, and it is the one piece with a real learning curve. If you need to create a new Git repo for use in the tests, the README gives a sequence of commands that creates a bare repository, clones it, writes a config.json, commits and pushes. That is because the platform exercises real git behaviour, so it needs a real repository rather than a fixture.

Where the Exercism website is the wrong thing to point at

The first wrong-tool case is a contributor. The README says pull requests are not accepted, and the topic tag says community contributions are paused. If your goal is to fix a bug or add a feature to exercism.org, this repository is not the route, and looking for one is a waste of time.

The second case is a team that wants to run their own instance of a learning platform. The README says the app running locally is not supported and that people are not encouraged to reuse the repository, so the setup instructions are a guided tour rather than a supported installation. The local AWS layer is stood up with localstack and opensearch, the DynamoDB state resets when Docker restarts, and there is no guarantee any of it works on your machine. That is fine for reading the code and not fine as a deployment path.

The third case is a team looking for code to lift. The AGPL-3.0 licence is the constraint that survives regardless of the README's tone. Anyone incorporating code from this repository into a network service inherits source disclosure obligations for that service, and the maintainers have made their preference clear. Read LICENCE.md and take the advice in the README together.

The fourth case is an engineer expecting a modern Rails application. The README refers to the Rails 7 console, the JavaScript is on the Hotwire and Stimulus stack with CodeMirror for editing, and the manifest still carries older transitive dependencies such as @rails/actioncable at 6.0.0 alongside Rails 7-era code. The GitHub Actions workflow, the AGENTS.md and CLAUDE.md files and the.codeclimate.yml configuration are the fingerprint of a project that has been running for a long time and accumulated tooling rather than rewritten.

What the repository is genuinely good for is narrower and still useful. If you are building a Rails application that serves a learning platform, a documentation site with an in-browser code editor and a browser-based test runner, this is a rare chance to read how one is put together. The AnyCable integration, the browser test runner packages, the per-language CodeMirror and highlight.js packages, the split between MySQL and MongoDB, the Procfile layout and the localstack plus opensearch approach to local AWS are all visible in the tree rather than described in a blog post.

The AGENTS.md and CLAUDE.md files at the root, along with the CODE_OF_CONDUCT.md, SECURITY.md,.husky/ directory and the.codeclimate.yml and.haml-lint.yml configurations, show the internal tooling around the code, and those files are part of the reading experience too.

Editorial conclusion

The exercism/website repository suits an engineer who wants to read how a large Rails application serving a community of learners is put together, since the whole codebase is browsable with its local setup documented. It does not suit anyone who intends to contribute to it or reuse its code, because the README closes both doors explicitly. Before reading it as a reference, check the Ruby version and the pinned local service versions in .dockerimages.json, since the setup instructions pin specific images and the README offers no guarantee that the steps work on an arbitrary machine.

Frequently asked questions

Official sources

1. exercism/website on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README