6 min read
Remote Compute
Attach a Kaggle notebook or a Jupyter server to run Python and native model training on bigger hardware, and understand exactly what is sent, what is shared and what the limits are.
Why attach a kernel
By default Python runs in your browser (Pyodide). That covers NumPy, pandas and scikit-learn work, but native PyTorch or TensorFlow, large installs and heavy training need a real Python environment. You can attach a Jupyter server, including a Kaggle notebook, and the Studio routes its Python through it. Nothing is attached unless you choose to, and with no kernel attached everything keeps running in the browser.
Connecting
- Sign in to DLWAY.
- Open Settings → Compute (or the Compute runtime control in the editor) and paste the server URL.
- The Studio reuses the first running kernel, or starts the server's
python3kernel if none is running. There is no kernel picker yet.
Kaggle
Start a Kaggle notebook session and keep it running, open Run → Kaggle Jupyter Server, and copy the VS Code Compatible URL (not the Colab-compatible one). Treat the URL as a credential: it expires when Kaggle ends the session, and detaching DLWAY does not stop the Kaggle session or its quota use. Kaggle marks this feature experimental, so its behaviour can change independently of DLWAY.
Any Jupyter server
A compatible server needs token or query authentication, the Kernels REST API, the Contents API and the kernel WebSocket endpoint. Project sync additionally needs a writable Contents API. A Jupyter server configured as a Colab local runtime is still a standard Jupyter connection and can work if it permits the DLWAY origin.
What runs on the kernel
All routed Python surfaces share one kernel, one namespace, one set of installed packages and one working directory:
- Editor
.pyfiles, the terminal's Python and REPL, and pip - Editor
.ipynbRun: code cells execute in order and stream to the terminal - Copilot's
run_pythontool - PrepFlow: the graph is generated as native pandas and scikit-learn Python, executed remotely, and returned to the usual previews and materialize flow
- Pipeline Run code steps written in Python
- Model Builder Train: you choose browser TensorFlow.js or native TensorFlow and scikit-learn on the kernel
JavaScript, TypeScript and TensorFlow.js always stay in the browser.
Generated files
Model Builder and PrepFlow do not translate JavaScript into Python. Their saved graphs are the shared description: the browser target lowers a graph to TF.js, and the Jupyter target lowers the same graph to Python. The generated files appear in the editor as generated_model.py or generated/prepflow.py next to requirements-remote.txt. A generated script checks its imports and installs only the packages that are missing from the kernel.
Generated files never contain your dataset or a token. The Studio injects the current rows only into the transient execution request. If you run a generated Model Builder script elsewhere, it can read DLWAY_DATASET_PATH (CSV, JSON, JSONL or Parquet); a generated PrepFlow script reads DLWAY_PREPFLOW_INPUT.
What is sent, and who can see it
- A public HTTPS server is reached through DLWAY's authenticated relay, because browser CORS and WebSocket origin checks usually reject third-party web editors. In this mode your credential, your code, synced files and pulled content pass through DLWAY's backend while a request is processed. The relay refuses private, loopback, link-local and cloud-metadata addresses.
- A local or private server is reached directly from your browser and must explicitly allow the DLWAY origin.
- Connection details are kept only in the current tab's session storage. Use browser Python removes them.
- A remote kernel can execute arbitrary code and reach whatever its account can reach. Connect only servers you trust.
Syncing project files
With Sync project files on, a Python run first uploads changed editor text (and known deletions) to .dlway/<project-name> on the server and switches the kernel's working directory there. Uploads happen when code runs, not when you save. .git and node_modules are skipped. A run fails before it starts if more than 300 files or 4 MB of changed text would have to be transferred.
Remote edits are kept while the matching local file has not changed. Connecting, restarting, switching projects or reloading the tab clears the Studio's change cache, so the next run republishes current text. Distinct project names avoid collisions, because names are sanitised for the path.
Save to project pulls one text file back: enter its exact path from the Jupyter Contents root (usually starting with .dlway/<project-name>/). It is limited to 4 MB and overwrites the project file at that path without asking. Binary files and folders cannot be pulled yet.
Stopping, restarting and disconnecting
- Stop interrupts the shared kernel. This can also interrupt work you started from the provider's own page.
- Restart kernel clears Python memory and the sync cache. It does not delete remote files, uninstall packages, end the provider session or release quota.
- Use browser Python detaches DLWAY without shutting the kernel down.
- The kernel runs one request at a time. If the editor, Model Builder, PrepFlow, Copilot or a pipeline asks while it is busy, the new request is rejected with a busy message instead of replacing the running one.
- A dropped connection reports the run as disconnected and tries to find a usable kernel for the next run. Code is never retried automatically, because it may already have had side effects. Reconnecting does not guarantee the same in-memory state.
- Reloading the same tab restores the connection; a new tab or a later browser session does not.
Limits
- A normal execution streams for up to 120 seconds, and relayed requests are capped at 290 seconds. Provider code may keep running after the stream is lost, so long training should use the provider's own jobs and checkpoints.
input()is disabled.- Streams, plain-text results and PNG images are shown. Widgets, HTML and other rich output are not.
.ipynbRun executes code cells as a batch and does not write results back into the notebook.- There is no remote shell, file browser, GPU provisioning or scheduler.
- PrepFlow image transforms that read browser-only media cannot run on a hosted kernel, and the run refuses with a list of the affected steps. Model Builder refuses media-reference image manifests remotely too; materialize the images to numeric features first, or train in the browser.
Related
Visual Model Builder, PrepFlow, Training and metrics and Privacy and storage.