JDoodle for builders

Your product needs to run code somebody else wrote. A coding course, an interview platform, a documentation site with live examples, a grader.

The hard part was never the editor. It is that running a stranger's program on your own machines means sandboxing, resource limits, keeping dozens of language toolchains current, and being the one who is paged when a submitted program tries something it should not.

That is the part you are handing over.

• An embed

  We render the editor in your page. Your scripts set the code, run it, read back what the user wrote, and receive the output.

  Good for anything where a JDoodle editor in your page is what you wanted, including grading, without a backend of your own.

• The API

  You render the interface, or none at all. Call it over REST for a result, or over WebSocket to stream output and answer a program while it runs.

  Good for your own editor, a terminal, an interactive exercise, and anywhere the interface has to be yours.

What you get either way

• REST and WebSocket. REST goes through your server and returns the finished result. WebSocket connects the user's browser straight to us with a token your server issues, so interactive programs feel immediate without your server relaying every line.
• Isolation. Submitted programs run on our machines, not yours.
• Limits. Runs are bounded in time and memory, so a loop that never ends is our problem.
• Languages kept current. Versions are maintained for you, including old ones your users still depend on.
• No infrastructure. Nothing to provision, patch, or scale on a deadline.

Where to start

Decide between the API and an embed first. Both run code and both hand you the result, so the question is whether you are happy for us to render the editor, not whether you need grading. Everything after that is a normal integration.