Deepnote + VPS Guide 2026: SSH, Databases and Remote Compute

A VPS can complement Deepnote by hosting a database, API, model endpoint, scheduler or other long-running service. It does not automatically add its CPU and RAM to a Deepnote notebook: notebook code still runs on Deepnote unless you explicitly send work to the remote server.

Choose the right integration

Goal	Recommended approach	Important limitation
Query PostgreSQL/MySQL on a VPS	Deepnote's native database integration	Use SSL or the built-in SSH option
Reach a private API or service	SSH Tunnel integration	Listed as an Enterprise feature in current docs
Run a command on the VPS	SSH key integration + ssh	You must transfer inputs and collect outputs
Serve a trained model	Run an authenticated HTTPS API on the VPS	Do not expose an unprotected development server
Store large files	Object storage integration	A VPS filesystem is not shared storage by default

When a VPS helps

• Keep PostgreSQL, MySQL, ClickHouse or another data service running independently of notebook sessions.
• Host an API used by several notebooks or applications.
• Run scheduled jobs, queues and workers outside the interactive notebook.
• Use a fixed IP address or a server in a required region.
• Control system packages and services that are not suitable for a notebook environment.

If the only goal is a faster notebook, first compare Deepnote's available machines. A separate VPS adds networking, authentication, monitoring and data-transfer work.

Option 1: connect Deepnote to a VPS database

Deepnote provides native integrations for PostgreSQL, MySQL/MariaDB, MongoDB, ClickHouse and other data sources. For PostgreSQL:

1. Install and secure PostgreSQL on the VPS.
2. Create a dedicated database user with only the required permissions.
3. In Deepnote, open Integrations, create a PostgreSQL integration and enter the connection details.
4. Require SSL, or configure the integration's SSH connection through a bastion.
5. Connect the integration to the project and test with a read-only query.

Deepnote documents fixed outbound IP addresses for allowlisting on eligible plans. Do not open a database port to the entire internet merely to make the first connection work.

Option 2: run remote commands over SSH

Deepnote's SSH key integration stores a private key as an integration variable. Once connected to a project, it can be loaded into ssh-agent and used to reach a remote machine.

On the VPS, create a non-root user and add a dedicated public key:

sudo adduser deepnote-runner
sudo install -d -m 700 -o deepnote-runner -g deepnote-runner /home/deepnote-runner/.ssh

Add only the public key to authorized_keys. Keep the private key in Deepnote's integration store, not in a notebook cell or Git repository.

From Deepnote, use the pattern shown in its SSH-key documentation to load the integration key, then connect to the restricted user. For repeatable jobs, invoke a versioned script rather than pasting a long command over SSH.

Option 3: expose a service through an SSH tunnel

For private APIs, experiment trackers or unsupported databases, Deepnote documents a standalone SSH Tunnel integration on the Enterprise plan. The tunnel exposes a local host and port to the project through environment variables.

This architecture avoids a public application port:

Deepnote project -> encrypted SSH tunnel -> VPS private service

For supported databases, prefer the SSH settings in the native database integration. They reduce custom connection code and handle the tunnel when an SQL block runs.

Option 4: call a model or worker API

For CPU or GPU work, deploy a worker or inference API on the VPS and call it from Deepnote. Production requirements include:

• HTTPS with a valid certificate;
• token or mutual-TLS authentication;
• request size and rate limits;
• job IDs for work that outlives an HTTP request;
• structured logs and health checks;
• private object storage for large inputs and outputs.

Avoid sending secrets or sensitive datasets in command-line arguments because they can appear in process listings and logs.

VPS provider comparison

Provider	Good fit	Billing	Tradeoff
LightNode	Temporary workers and broad region choice	Hourly	Self-managed; regional specs vary
DigitalOcean	Developer docs and simple managed services	Hourly/monthly cap	Smaller region list than some rivals
Vultr	Many compute types and locations	Hourly/monthly cap	Backups and licenses can cost extra
Hetzner	Cost-sensitive EU workloads	Hourly/monthly cap	Account verification and fewer regions

Choose based on latency to Deepnote and your data source, not latency to your laptop. Confirm outbound-traffic charges before moving large datasets.

Security checklist

• Use a dedicated non-root account and key for Deepnote.
• Disable SSH password login after key access is tested.
• Restrict inbound ports with both the provider firewall and the host firewall.
• Use TLS for databases even when credentials are strong.
• Put secrets in integrations or environment variables, never in committed notebooks.
• Patch the OS and runtime regularly.
• Back up the database off-server and test a restore.
• Remove keys and firewall rules when a project ends.

Cost control

Hourly billing saves money only if unused servers are destroyed, not merely forgotten. Automate snapshots where required, export durable data, then delete temporary workers. Set provider budget alerts and monitor bandwidth, storage and public-IP charges as well as compute.

FAQ

Can Deepnote connect to a VPS over SSH?

Yes. Deepnote documents SSH key, database SSH and standalone SSH Tunnel integrations. Availability depends on the workspace plan and integration type.

Can a VPS increase Deepnote's notebook RAM?

Not directly. Code runs on Deepnote unless you design a remote worker, database query or API call that executes on the VPS.

Should I run Jupyter on the VPS and connect it to Deepnote?

That creates two notebook environments and is usually unnecessary. Use Deepnote for collaboration and expose a specific database, API or worker from the VPS.

Is a public database port safe?

It increases risk. Prefer a native SSH connection, private networking or a strict IP allowlist, and require encrypted database connections.

Final recommendation

Use Deepnote as the collaborative analysis layer and give the VPS one clear responsibility: database, API, worker or scheduler. The clean boundary improves security, reproducibility and cost tracking compared with treating the VPS as undefined “extra compute.”