Repository navigation
[DEPR]: Local codejail #36639
Description
Activity
[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.
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.
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?
@robrap, I can take on that. It would be mostly the announcement and updating this ticket accordingly?
@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.
@MoisesGSalas are you working on this?
@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.
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.
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!
@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?
@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
- added a commit that references this issue
on Jul 25, 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.
@MoisesGSalas: For this DEPR, it is really about transitioning from local codejail to openedx-codejail, not from eduNext to openedx.
- We need both docs and config (Tutor) support.
- For docs, there is a darklaunch feature to aid in the transition.
- I pointed to darklaunch docs above in RTD, but they moved to https://github.com/openedx/xblocks-core/blob/582e24085b4c4aa30338eb917f72a905991a568c/xblocks_contrib/problem/capa/safe_exec/remote_exec.py#L21-L41.
- For Tutor support, it sounds like that may have been there from the beginning, since someone could simply use the openedx version in place of the eduNext version? Not sure which has been used by default for the newest named releases.
- If MIT is using local, maybe they'd be a good test case for readiness of the feature and docs. FYI: @pdpinch
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.
[Updates]
- @peter-fogg: Apologies, I meant to tag @pdpinch in my comment above, and I seem to be unable to edit it as well.
- @pdpinch: See comment above.
- All: The beauty of the darklaunch feature is that we can really test our readiness ahead of time, and ensure it is just a question of documentation.
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:
- A = local, B = remote
- A = remote1, B = remote2
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!)
As long as we can prove
openedx/codejailis fully supported in Ulmo or Verawood, we are ready to remove local codejail.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).
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.
- added a commit that references this issue
on Aug 19, 2026 - moved this from Transition Unblocked to Breaking Changes Unblocked in DEPR: Deprecation & Removal
on 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?
No, I think it's safe to drop local codejail in that case it sounds like.
Great, how can i get some eyes on this PR: openedx/xblocks-core#222? It should be most of the removal work.
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: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).FSIZEwhere 0 means no files can be created.CODEJAIL_EXTRA_PIP_REQUIREMENTSin the plugin.More information:
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.
See https://docs.openedx.org/projects/edx-platform/en/latest/references/featuretoggles.html#featuretoggle-ENABLE_CODEJAIL_DARKLAUNCH
Additional Info
No response
Task List
ubuntu-latestlike in this PR: build: updated ubuntu version to latest edx/edx-platform#75.