en
Jupyter Notebook as a Tor Hidden Service for Private Data Science
Data science and research workflows often involve sensitive data: medical records, financial data, confidential business information, or research findings not yet ready for publication. Running Jupyter notebooks on a server accessible over the public internet creates unnecessary exposure - the notebook server must be protected by authentication, HTTPS, and firewall rules that add operational complexity and attack surface. An alternative is to run Jupyter as a Tor hidden service: accessible only through Tor Browser, with no public port exposed, and protected by both Tor's encryption and Jupyter's token authentication. This guide covers deploying Jupyter in this configuration, accessing it from multiple devices through Tor Browser, managing large datasets securely, and integrating common data science libraries in a privacy-preserving workflow.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
Jupyter Deployment for Hidden Service Access
Install Jupyter on the server with pip install jupyterlab or in a conda environment. Configure Jupyter to listen only on loopback: jupyter lab --ip=127.0.0.1 --port=8888 --no-browser. Set a strong password: jupyter lab password (hashes and stores the password in jupyter_lab_config.json). Configure the Tor hidden service in /etc/tor/torrc: HiddenServiceDir /var/lib/tor/jupyter/ and HiddenServicePort 80 127.0.0.1:8888. After starting Tor, the .onion address is available in /var/lib/tor/jupyter/hostname. Access the Jupyter interface at http://youraddress.onion from Tor Browser. The notebook token or password prompt appears - enter your configured password. For production use, run Jupyter as a systemd service so it starts automatically and persists across reboots.
Dataset Access and Storage Configuration
Large datasets accessed from Jupyter should be stored on the server with appropriate permissions. For datasets too large for the VPS disk, mount remote storage via SSHFS (over Tor: sshfs -o ProxyCommand='ncat --proxy 127.0.0.1:9050 --proxy-type socks5 %h %p' user@storageserver.onion:/data /mnt/datasets). Organize data in directories that Jupyter can access: set the notebook directory to a root that includes both notebooks and data directories. For sensitive datasets, encrypt at rest using LUKS (full disk encryption) on the VPS, unlocking on boot via a stored passphrase or manual unlock. Do not store raw sensitive data in Jupyter notebooks themselves (it appears in notebook output and git history) - load data from files and use .gitignore to exclude data directories from version control.
Multi-User Jupyter with JupyterHub
JupyterHub provides multi-user Jupyter notebook servers: each user gets their own notebook environment while sharing server resources. For a research team accessing shared notebooks over Tor, JupyterHub is more appropriate than single-user Jupyter. Configure JupyterHub with PAM authentication (Linux system accounts) or OAuth (for integration with existing auth systems). The hidden service configuration is identical: point the .onion service to JupyterHub's port (default 8000). Each user logs in with their system account credentials and gets an isolated notebook environment. JupyterHub requires more resources: plan for at least 1GB RAM per concurrent user plus server overhead. Spawner configuration (DefaultSpawner for simple setups, DockerSpawner for isolated containers) determines the user isolation level.
Kernel Management and Resource Limits
Jupyter kernels (Python, R, Julia, etc.) run as processes with access to server resources. Without resource limits, a single notebook with a runaway computation can exhaust server CPU and memory, affecting other users or services. Implement resource limits: for single-user Jupyter, configure kernel timeout (idle kernels that have been idle for 1 hour are shut down automatically) with jupyter_lab_config.py: c.MappingKernelManager.cull_idle_timeout = 3600. For JupyterHub, configure user resource quotas with the available spawner memory/CPU limit settings. Use tmux or screen to keep Jupyter running when your Tor Browser session disconnects - the notebook computations continue even if the browser connection drops. nohup jupyter lab &> /var/log/jupyter.log & launches Jupyter persistently.
Version Control and Collaboration Over Tor
Integrating git version control with Jupyter over Tor: install jupyterlab-git extension (pip install jupyterlab-git) which adds a git interface in the JupyterLab sidebar. Configure git to route through Tor for remote repositories: git config --global http.proxy socks5://127.0.0.1:9050 and git config --global https.proxy socks5://127.0.0.1:9050 for HTTPS repos, or use .onion-hosted git servers (Gitea on a .onion) as remotes without needing Tor proxy configuration. For collaboration without a shared git server, use nbconvert to export notebooks to HTML or PDF for sharing via encrypted channels, or share notebook files via Syncthing over Tor between collaborators. JupyterBook can generate a static documentation site from notebooks, publishable as a separate .onion hidden service for public-facing research documentation.
Related Services
Why Anubiz Host
100% async — no calls, no meetings
Delivered in days, not weeks
Full documentation included
Production-grade from day one
Security-first approach
Post-delivery support included
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.