Hosting & Infrastructure
Overview
Hosting & Infrastructure covers the operational layer of Open edX — deployment tooling, database and cache configuration, Celery task queues, storage (S3), CDN, monitoring, and scaling. This is the domain of platform operators and DevOps engineers.
The Open edX community has standardized around Tutor (maintained by Edly/overhangio, not in the openedx org) for Docker-based deployment. Tutor replaced the earlier configuration repo (Ansible-based) as the primary deployment mechanism.
Current State (2026)
- Tutor: Docker Compose / Kubernetes-based deployment; the dominant deployment approach in the community; managed via
tutor configand Tutor plugins - Databases: MySQL for relational data; MongoDB for course content; Redis for Celery broker and caching; Elasticsearch for search
- Celery: Background task processing via Celery with Redis or RabbitMQ as broker; used for email, report generation, grade computation
- Storage: Static assets and user uploads typically stored in S3-compatible object storage
- CDN: Video and static assets served via CDN (CloudFront or equivalent)
- Monitoring: Prometheus + Grafana common;
edx-django-utilsprovides DataDog/New Relic integration hooks
Architecture
- Service topology: LMS, Studio,
course-discovery,credentials,forum,ecommerce(if used) as separate Django services; each with its own database - Tutor orchestration: Tutor manages service configuration, networking, and deployment; plugins extend the base deployment
- Kubernetes: Tutor supports both
tutor local(Docker Compose) andtutor k8s(Kubernetes) deployment modes - Codejail: Isolated Python execution for graded problems; runs as a separate container/service with strict sandboxing
Relevant Repositories
| Repository | Role in This Feature | Activity Level | Notes |
|---|---|---|---|
| openedx/openedx-platform | Django settings, wsgi, celery config | High | Main service |
| openedx/edx-django-utils | Monitoring, caching utilities | Medium | Operational tooling |
| openedx/codejail | Sandboxed Python execution | Low | Security isolation |
| openedx/codejail-service | Codejail as a microservice | Low | Containerized codejail |
| openedx/xqueue | External grader queue (legacy) | Low | For custom graders |
Note: Tutor (overhangio/tutor) is not in the openedx org but is the de facto standard for deployment.
Recent Changes
- Tutor (maintained by Edly/overhangio) continues to be the community deployment standard
configuration(Ansible-based) repo effectively deprecated
History
Origin
- Year introduced: 2012 (edX.org infrastructure was custom; community deployment was more ad-hoc)
- Initial implementation: Ansible-based configuration in the
configurationrepo; custom AWS infrastructure for edX.org - Context: edX.org ran at massive scale; community deployments (xMOOC, national platforms) needed their own deployment tooling
Key Milestones
| Year | Milestone | Teams / People Involved |
|---|---|---|
| 2013 | configuration repo (Ansible) open sourced | Unknown |
| ~2019 | Tutor project begins (by Régis Behmo / Edly) | Régis Behmo |
| ~2021 | Tutor becomes the recommended deployment approach | Unknown |
| ~2022 | configuration repo deprecated in favor of Tutor | Unknown |
People Who Shaped This Area
- Engineering: Régis Behmo (Tutor creator, Edly); others unknown
- Product: Unknown — open question for interview
- Design: N/A (infrastructure area)
Open Questions
- [ ] What was the original edX.org infrastructure like (AWS services, AMI-based, etc.)?
- [ ] What drove the community to build Tutor rather than improving the Ansible configuration?
- [ ] How does the multi-service architecture affect operations complexity?
- [ ] What monitoring and alerting setups are used in production deployments?
- [ ] What are the most common infrastructure failures in Open edX deployments?