bytedeck

Where bytedeck comes from

Bytedeck is a learning management system whose README opens by stating it originated from Timberline Secondary School's Digital Hackerspace. The project is built with Django and uses a multitenant architecture, which means a single deployment can host many separate sites, each called a deck, with their own data and configuration. The documented setup assumes a Debian-based Linux distribution such as Ubuntu, though the README notes it can work anywhere Docker runs. The install path relies on Docker to avoid manual tool setup, and the instructions walk through installing the Docker engine, confirming that docker compose works, and ensuring Python 3.12 is available, because a different Python version is said to cause dependency errors from small changes between versions. After cloning or forking the repository, the operator copies an example environment file to a local .env file that both docker compose and Django read for settings. The README stresses that for a non-local deployment the DOMAIN_ROOT should be set to the fully qualified domain name. The combination of Docker, a pinned Python version, and an environment file keeps the first-run experience close to a standard Django deployment while hiding the multitenant complexity behind the deck abstraction. The instructions stress that for a non-local deployment the DOMAIN_ROOT should be set to the fully qualified domain name, a reminder that the system is built to serve real tenants rather than only local experiments.

Running and creating a tenant

Once the environment file exists, the README describes building the containers and initializing the database through migrations and seed data with a management command such as initdb. The Django development server is then started, and the app is reached at localhost on port 8000. The README is careful to note that the multitenant design requires a domain name, so the 0.0.0.0 address printed by Django will not work and localhost must be used instead. Creating a tenant, which is a new Bytedeck site, is done through a decks new page in the browser. Default credentials for the admin are defined in the environment file, with admin and a password set by DEFAULT_SUPERUSER_PASSWORD and TENANT_DEFAULT_SUPERUSER_PASSWORD. The owner login is delivered through a generated email file in the _sent_mail directory that contains a confirmation link and the owner's credentials. The README also documents a generate_content management command that seeds realistic sample data, such as 100 fake students and five campaigns of ten quests each, so a developer can see the system populated without manual entry. Redis, Celery, and Celery beat containers are started to handle background work, and docker compose logs shows errors when containers run in the background. The README also explains that for local Google sign in the developer must map localhost to a localhost.net address so the OAuth redirect is accepted, a small but necessary detail for testing authentication.

Tooling and contribution notes

The README shows that Bytedeck carries standard continuous integration signals, including a build and test workflow and a Flake8 linting workflow on the develop branch, plus a code coverage badge from Codecov. The develop branch is described as the main branch of the repository, which is a useful detail for anyone forking the project because they should base work there rather than on a default master. The environment-driven setup means most configuration lives in the .env file, and the documentation points contributors to a separate CONTRIBUTING.md for the rules a pull request must satisfy before it is accepted. The build instructions reference a venv path for local development as an alternative to running everything inside Docker, and they include the small quirk of installing wheel first to avoid errors in a fresh virtual environment. The README's tone is practical and school-oriented: it explains not only the commands but the reasoning, such as why localhost matters for the tenant router and why a hosts file mapping is needed for Google sign in during local development. For a reader evaluating the system, these details suggest a project that documents its rough edges rather than hiding them. The README also notes the develop branch is the main branch of the repository, a detail that matters for anyone forking the work to base changes in the right place.

Editorial conclusion

Bytedeck is released under the GPL-3.0 license, is written in Python, and was last updated on GitHub on 2026-08-24 with 24 stars recorded.