Repository navigation
[DEPR]: Local codejail #36639
Description
Proposal Date
2025-04-30
Target Ticket Acceptance Date
TBD
Earliest Open edX Named Release Without This Functionality
Ulmo - 2025-10
Rationale
The capability of using codejail for problems with code execution is not going away. This DEPR is for removing the ability to run this locally as part of edx-platform, in favor of running remotely in a new codejail-service.
Using the new service for code execution is more secure, most especially because if anyone were able to break out of the layers of security, they would not be executing code on the same box as the LMS, which has access to data which is important to keep secure. Keeping code execution in another service entirely also allows additional layers of security that would not be possible when colocated with the LMS, such as preventing all outbound network connections.
Removal
The local codejail allows unsafe execution (non-sandboxed) for configured courses. This functionality will likely not be carried over to the new remote service.
The darklaunch feature, which enables one to choose between local and remote, is a good starting place to find all of the local codejail code that can be removed. See this github search for locations.
Replacement
The replacement is the new codejail-service.
Note: 2U/edX is running this in production.
Courses on COURSES_WITH_UNSAFE_CODE: there is no replacement for running a course's code outside the sandbox. If a course was on the list because its code exceeded the default resource limits, use per-course limits on the service instead:
- Set
CODE_JAIL["limit_overrides"]in the codejail-service settings to a dict keyed by the full course run key, using the same limit names asCODE_JAIL["limits"](CPU,REALTIME,VMEM,FSIZE,NPROC). - The platform sends the course id with every execution. The key is matched exactly, not as a regex.
- A limit of 0 disables it, except
FSIZEwhere 0 means no files can be created. - Extra packages for the sandbox can be added with
CODEJAIL_EXTRA_PIP_REQUIREMENTSin the plugin.
More information:
- codejail-service deployment docs for the service settings.
- codejail library source for the limit names and override behavior.
- tutor-contrib-codejail to deploy the service with Tutor.
Deprecation
The legacy local calls could be marked as deprecated when someone moves this ticket forward.
Migration
A darklaunch capability was added so that the new remote codejail-service could be tested and tuned in production without causing issues. Once all is well, edx-platform configuration can be updated to switch users to the new service.
Additional Info
No response
Task List
- Complete readiness of new replacement codejail-service
- Make codejail-service Tutor plugin
- Duplicate requirements in new codejail-service. It currently uses this defined in edx-platform to avoid duplication.
- Remove local capability for codejail, including current darklaunch feature. Note: there are ideas for future darklaunch features for Python upgrades, but that must be handled differently.
- Consider whether this is the last remaining OS-specific functionality in edx-platform, and if we could update workflows to use
ubuntu-latestlike in this PR: build: updated ubuntu version to latest edx/edx-platform#75.
Activity
robrap commentedon May 23, 2025
[inform] This DEPR is in the Draft state. It can't move forward without a DEPR coordinator to help update it to match the updated DEPR template. No action is required, unless anyone wants to move this out of Draft.
MoisesGSalas commentedon Oct 30, 2025
To clarify a little bit more regarding the codejail-service plugin. We plan to provide support for the new codejail service in the current eduNEXT/tutor-contrib-codejail plugin. The idea would be to support both implementations during ulmo (edunext's and 2U's) and eventually transition to the openedx/codejail-service in verawood.
robrap commentedon Jan 8, 2026
Thanks @MoisesGSalas. Note that this DEPR was documented, but never announced, because it doesn't yet have an owner. Do you have interest in owning this DEPR and following up with legacy removal in Verawood?
MoisesGSalas commentedon Jan 15, 2026
@robrap, I can take on that. It would be mostly the announcement and updating this ticket accordingly?
robrap commentedon Jan 15, 2026
@MoisesGSalas: See the Task List under this issue's description. We need someone to take on responsibility for that DEPR work as a prerequisite to announcing.
feanil commentedon Mar 5, 2026
@MoisesGSalas are you working on this?
MoisesGSalas commentedon Mar 6, 2026
@feanil, I had this frozen for a while, but I can take on it next week. I would like little bit of clarification though:
When @robrap says "We need someone to take on responsibility for that DEPR work as a prerequisite to announcing." It doesn't mean fulfilling the checklist is a requirement for the announcement, right? It means that I will make sure it gets done by the Verawood release.
robrap commentedon Mar 6, 2026
That is correct, @MoisesGSalas. A requirement for announcing is simply to have someone willing to take the DEPR forward. Since you are willing to do that, you are free to start the process (via announcing) whenever you are ready. Thank you!
feanil commentedon Mar 11, 2026
@MoisesGSalas if you're doing the work, I can help with the DEPR part of the process of communicating this. It sounds like you're ready to start on this work? Do you want me to go ahead and do the comms?
MoisesGSalas commentedon Mar 11, 2026
@feanil, I posted: https://discuss.openedx.org/t/deprecation-removal-local-codejail/18587. If there's anything wrong with it let me know.
I also don't seem to be able to edit this ticket. Is there anything that I need to do?
10 remaining items
feat!: remove support for local CodeJail
feanil commentedon Aug 10, 2026
I don't think I currently have cycles to support Moises on this. If others do, they are welcome to take this but I think we need a few minds to make sure we don't break things as we move. Unlikely to be resolved by Willow currently.
robrap commentedon Aug 11, 2026
@MoisesGSalas: For this DEPR, it is really about transitioning from local codejail to openedx-codejail, not from eduNext to openedx.
Once the transition has been tested by someone using Tutor, assuming this was ready in Ulmo (or possibly Verawood if any other changes were made), we should be ready to delete the local=>service darklaunch feature (for release in the following named release). This deletion is what we (2U) want to do, to transition it to a service1=>service2 darklaunch feature, which could be used for eduNext=>openedx codejail move, or for Python upgrades (which is what we want it for), etc. At the same time, local codejail implementation code could also be removed to wrap up this DEPR. But before we contract, let's ensure that the expand phase was actually completed.
robrap commentedon Aug 11, 2026
[Updates]
timmc-edx commentedon Aug 11, 2026
Another approach would be to change the existing darklaunch so it makes a more generic A/B comparison, and broadening its settings so that it can do either of these:
It would be a bit more confusing to configure, but it's an option that allows both kinds of darklaunch to coexist.
(Although yes, I also just want local codejail gone!)
robrap commentedon Aug 11, 2026
As long as we can prove
openedx/codejailis fully supported in Ulmo or Verawood, we are ready to remove local codejail.MoisesGSalas commentedon Aug 12, 2026
Regarding Tutor: It was never possible to run local codejail in Tutor, that was actually the original reason for creating the remote service, so Tutor users won't need to migrate out of local execution. The only change they will experience is between remote service implementations. In Ulmo Tutor users can chose between https://github.com/edunext/codejailservice and https://github.com/openedx/codejail-service. In Verawood only the latter is available; Ulmo is the transition release.
IMO, the large majority of Tutor users won't need the darklaunch feature to make the move between remote services, so it would be fair to say we only need to add documentation and remove the current code? The tools to perform the migration that 2U used are in Ulmo and Verawood, we can validate with the MIT if they are sufficient and formalize the docs and simply start removing the code right? Afterwards a more flexible darklaunch can be reintroduced (the one Tim have been proposing in the forums).
pdpinch commentedon Aug 13, 2026
MIT switched from local codejail to the edunext codejail service some time ago, when we moved to containerized deployments. We are fine with the deprecation of local codejail.
Perhaps we should take a look at the darklaunch feature to evaluate moving from the edunext server to the openedx version, but I don't think that blocks the local codejail deprecation.
feat!: remove support for local CodeJail
robrap commentedon Aug 24, 2026
@pdpinch: [inform] The existing darklaunch feature is local codejail => codejail service only. There does not yet exist a darklaunch feature for service A => service B. There may someday.
robrap commentedon Sep 14, 2026
@feanil: Based on the above announcement and discussions, I don't see any blockers to marking this as "Breaking Changes Unblocked", so I made that change. Do you see any blockers? Otherwise, is @MoisesGSalas free to work on local codejail removal at this point?
feanil commentedon Sep 16, 2026
No, I think it's safe to drop local codejail in that case it sounds like.
MoisesGSalas commentedon Sep 21, 2026
Great, how can i get some eyes on this PR: openedx/xblocks-core#222? It should be most of the removal work.