# code-dot-org: the Rails, Sinatra and Blockly stack behind Code Studio > The code-dot-org repository holds the Code.org website and the Code Studio learning platform, split into a Ruby on Rails dashboard, a Sinatra marketing site, and a large JavaScript applications tree that carries the Blockly based puzzle engine. It is one of the largest open source educational codebases in use by schools, and its build runs through Rake, Docker Compose and a MySQL, Redis and MinIO stack. **code-dot-org/code-dot-org** — The code powering code.org and studio.code.org - Repository: https://github.com/code-dot-org/code-dot-org - Website: http://code.org - Stars: 902 · Forks: 537 - Language: JavaScript - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/code-dot-org-code-dot-org ## Three servers, one JavaScript applications tree The repository is described as the code powering code.org and studio.code.org, and the readme is upfront that Code.org is a non-profit dedicated to expanding access to computer science education. The split into servers is the first thing to understand, and the readme's directory guide is clear about it. The dashboard directory is the server for the Code Studio learning platform, a Ruby on Rails application responsible for courses, tutorials and puzzle configurations, user accounts, student progress and projects, and the levelbuilder content creation tools. Levelbuilder is worth noting on its own, because it is how the curriculum itself is authored, which means the content pipeline is part of the application rather than a separate system. The pegasus directory is the server for the code.org website itself, a Sinatra application serving code.org, hour of code dot com and csedweek dot org. The apps directory is described as the JavaScript engine for all of the tutorials, puzzle types and online tools. It gets built into a static package that is served through dashboard. The stated goal is that all JavaScript code ultimately lives there, so it benefits from linting, JSX and ES6, and the readme says there are currently some exceptions to that rule. What sits inside apps is the part that makes the platform what it is. The Hour of Code tutorials including Star Wars, Minecraft, Frozen and Classic Maze, the tools such as Artist, Play Lab and App Lab, and the core puzzle types Maze, Farmer, Bee, Bounce, Calc and Eval. The topics list includes blockly, which tells you the visual programming environment is the centre of the whole thing. The rest of the tree is infrastructure: aws for deployment configuration and scripts, bin for developer utilities, cookbooks for configuration management through Chef, shared for source and assets used across the application, and tools for git commit hooks. ## Running the stack locally with Rake and Docker Compose The quick start is four steps. ```bash rake build bin/dashboard-server ``` The first command builds the application, and the second launches the development server, after which you open http://localhost-studio.code.org:3000/ in a browser. The setup guide at SETUP.md is step one of the sequence, and running rake on its own from the repository root prints every build command available, which is the quickest way to see what the Rakefile can do. The Docker path is the more complete environment, and its structure tells you what the dashboard actually depends on. The compose file is assembled from several includes. ```yaml include: # Services the dashboard server depends on - path: ./docker/developers/docker-compose.mysql.yml - path: ./docker/developers/docker-compose.redis.yml - path: ./docker/developers/docker-compose.minio.yml # The dashboard server itself - path: ./docker/developers/docker-compose.dashboard.yml ``` So the backing services are MySQL for the relational data, Redis for caching and MinIO as an S3-compatible object store for file uploads, which is what a learning platform needs to store student project images and work. The developer documentation for this environment lives at docker/developers/README.md. The compose file also prints the locals.yml values you need to point the host application at the contained services, including db_writer, db_endpoint_writer, db_credential_admin with a username and password, cloudfront_key_pair_id and cloudfront_private_key set to a local override, slack_bot_token, properties_encryption_key, and the aws_s3 settings with aws_s3_endpoint pointing at http://localhost:9000 and an aws_s3_emulated flag. There is a locals.yml.default at the repository root that those values are copied from. That list is the real cost of running this locally. The application talks to a CDN, to Slack, to S3 and to a database, and the local environment stubs each of them rather than removing the dependency. The repository pins its toolchains explicitly, with .ruby-version, .nvmrc, .python-version and a .haml-lint.yml alongside .eslintrc.js, which tells you a Rails, a Node and a Python stack are all in play. ## A Python side that runs inside the browser The pyproject.toml is short but revealing. The project is named code-dot-org at version 1.0, requires Python 3.12 or newer and below 3.14, and the comment above the requirement explains why: pydantic-core 2.27.1 uses PyO3 0.22.6, which only supports up to Python 3.13. That comment is the kind of detail that usually only appears after a build broke. The dependencies are five local packages, and the comment above them gives an instruction that tells you about the repository's discipline: register local Python packages from /python in three places, this list, in [tool.uv.sources] and in [tool.uv.workspace]. And then, Do not add dependencies here, add them to a pyproject.toml in a /python sub-dir. The five packages are pycdo, neighborhood, pythonlab_setup, theater and unittest_runner. The uv workspace members list confirms the layout, pointing at python/pycdo, python/pythonlab/pythonlab_setup, python/pythonlab/unittest_runner, python/pythonlab/neighborhood and python/pythonlab/theater. Two of these names hint at what they are. pythonlab is Python Lab, the in-browser Python environment in Code Studio, and the setup, unittest runner and neighborhood packages are its pieces. theater, judging by the dev dependency comment, renders real gifs, since theater's tests render real gifs and Pyodide supplies pillow at runtime so theater does not depend on it, but CI runs pytest from this environment. So there is a second language running in the browser here, alongside the Blockly JavaScript. The dev group pulls in pytest, pytest-mock, ruff at 0.8 or newer, ipython, coverage and pillow. Linting is ruff with a line length of 100, and the tool is managed through uv, with a uv.lock at the repository root. This is a big deal for how you read the codebase. A developer who opens this repository expecting one application finds a Rails server, a Sinatra server and a Python runtime that executes inside students' browsers, all coordinated by Rake. ## The documentation a contributor is expected to read first The readme has a Documentation section that reads like a table of contents for a project with a real onboarding problem, and it says something specific about what to read first. ARCHITECTURE.md is listed first, with the instruction in particular please review and adhere to our Architectural Tenets. That is a strong signal that the codebase has architectural rules rather than conventions, and the tenets are anchored in the document. SETUP.md covers getting everything running, TESTING.md is about how to be sure nothing broke, and STYLEGUIDE.md holds the code style conventions. The readme also points to the LICENSE and NOTICE files and to a docs folder with many more topical guides, and it notes that several sections of the repository have their own documentation, starting with apps/README.md. The contribution route is CONTRIBUTING.md, and the readme says the project is welcoming about where to start. Two more files at the root extend the picture. AGENTS.md and CLAUDE.md sit alongside the human documentation, which tells you the project expects coding assistants to work in the repository and has written guidance for them, and skills-lock.json suggests those skills are versioned. There is a conventions file that is easy to miss and worth noticing: .haml-lint.yml plus .haml-lint_todo.yml. The presence of a todo file for the linter is a convention some projects use to track known violations separately from new ones, and here it pairs with the ESLint configuration for the JavaScript side. Other structural signals worth noting: a codecov.yml for coverage, a Vagrantfile and a docker-compose.yml for other environment shapes, a skaffold.yaml for deployment workflows, a .drone.yml for continuous integration, an openspec/ directory, an experimental/ directory, a frontend/ directory, a k8s/ directory, and a config.yml.erb with a locals.yml.default, which together describe a system that has been configured for several deployment targets. ## Release naming and a default branch called staging The release naming tells you how this project ships. The listed releases are v2026-10-19.0, v2026-10-17.0 and v2026-10-16.0, dated the same days they carry. That is a date-based version, and it means releases are cut frequently. Three releases in four days is the observed pattern, and the versioning is a contract: the version string tells you exactly which day the code went out, so a classroom can pin a specific build and reproduce what students saw. For a platform used by schools, that matters more than usual. A teacher who has run a class on one year's puzzle set and returns the following autumn should be able to pin the version that matches their lesson plans, and a date-based version makes that pinning obvious. The default branch is called staging, which is a slightly unusual choice for a project of this kind. It suggests that staging is the integration branch where work lands, and that release tags are cut from it, rather than the more common main or develop naming. Whatever the branch topology, the practical guidance for a contributor is the same: read CONTRIBUTING.md and ARCHITECTURE.md before touching anything. The repository also carries a deployment.rb at the root and an aws/ directory described as configuration and scripts that manage our deployments, alongside the k8s/ directory and the skaffold.yaml. So deployment is configured in the repository rather than in a separate infrastructure repo, which is convenient for a small infrastructure team and a burden for anyone who only wants to change a puzzle. ## Where this repository is the wrong tool The limits are worth stating plainly, because the scale of the codebase can mislead. The first is that this is not a component you can adopt. There is no npm package, no gem, no pip package that gives you a Blockly puzzle environment or a lesson platform. You get the whole product: two web servers, a build system, a Chef-managed deployment layer, a Kubernetes configuration, a Python runtime that executes in browsers, and a database schema. If what you want is to teach Blockly to your own students with your own content, you are looking at forking a very large codebase rather than installing something. The second is the local setup cost. Standing up the dashboard means MySQL, Redis, MinIO, a Rails app with a Ruby version pinned, a Node toolchain, a Python toolchain, and a locals.yml with credentials for a CDN, Slack and S3. The compose file exists and automates the services, but the application still expects to talk to all of those, and a first contribution to the project involves a lot of setup before a change to a puzzle can be seen in a browser. The third is the licence, and it is the one to check first. The licence field on the repository says Other, a custom licence GitHub cannot classify, and the root carries a LICENSE file and a NOTICE file. For a non-profit educational project with an open source tradition that is unusual, and for anyone planning to reuse the puzzle code, the tutorials or the curriculum in a commercial product, the terms need to be read directly rather than assumed from the metadata. This is not legal advice. The alternative approach depends on the goal. For teaching Blockly itself, a small standalone Blockly page with a few custom blocks is a fraction of the work and gives you exactly what you need. For building a learning platform, the honest question is whether you need the curriculum, the progress tracking, the accounts and the content authoring tools, or only the puzzle engine, and this repository is the expensive answer to all of those at once. ## Conclusion code-dot-org suits an educator or a developer who wants to read how a real, classroom-scale learning platform is built, and who wants to run the puzzle engine locally rather than through the hosted site. It does not suit a team looking for a small library to embed, since this is a whole product with a Rails, Sinatra, JavaScript and Python surface, and it is not a lightweight way to teach Blockly, because standing up the dashboard needs MySQL, Redis, MinIO and a set of credentials. Before attempting a local setup, read ARCHITECTURE.md and its architectural tenets, since the repository asks contributors to adhere to them, and check the .ruby-version, .nvmrc and .python-version files, which pin the three toolchains this codebase expects. ## FAQ ### What is in the code-dot-org repository? It holds the Code.org website and the Code Studio learning platform. The dashboard directory is a Ruby on Rails app for courses, tutorials, puzzle configurations, user accounts, student progress and the levelbuilder content tools, pegasus is a Sinatra app for code.org and the Hour of Code sites, and apps is the JavaScript engine for the tutorials, puzzle types and online tools. ### How do I run Code Studio locally? Follow SETUP.md, then run rake build and bin/dashboard-server, and open http://localhost-studio.code.org:3000/. The Docker environment described in docker/developers/README.md adds MySQL, Redis and MinIO via compose includes, and locals.yml must point at those services. ### What are the apps in code-dot-org? The apps directory is the JavaScript engine for tutorials, puzzle types and online tools, built into a static package served through dashboard. It contains the Hour of Code tutorials including Star Wars, Minecraft, Frozen and Classic Maze, tools such as Artist, Play Lab and App Lab, and core puzzle types including Maze, Farmer, Bee, Bounce, Calc and Eval. ### What licence does code-dot-org use? The licence field on the repository says Other, a custom licence GitHub cannot classify, and the root contains LICENSE and NOTICE files. The terms need to be read from those files rather than inferred from the repository metadata. ### What Python version does code-dot-org need? The pyproject.toml requires Python 3.12 or newer and below 3.14, with a comment explaining that pydantic-core 2.27.1 uses PyO3 0.22.6, which only supports up to Python 3.13. The repository also pins .ruby-version, .nvmrc and .python-version. ## Sources - [code-dot-org/code-dot-org on GitHub](https://github.com/code-dot-org/code-dot-org) - [Issues](https://github.com/code-dot-org/code-dot-org/issues) - [Project website](http://code.org) - [README](https://github.com/code-dot-org/code-dot-org/blob/staging/README.md) - [Releases](https://github.com/code-dot-org/code-dot-org/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/code-dot-org-code-dot-org