How to share a Deepnote notebook

Deepnote is built around collaboration inside a workspace — real-time editing, shared environments, comments on blocks. It is very good at that. The friction appears at the workspace boundary, which is also where most sharing requests come from.

The access model

Workspace members get a role and see the projects that role grants. This is the primary unit of access, and it means "let this person see the notebook" often turns into "add this person to our workspace," which is a billing and governance decision rather than a sharing one.

Project collaborators are named people invited to a specific project. Narrower, still an invitation with an account behind it.

Published apps. A notebook can be published as an app: the outputs render, the code is hidden, and there is a link. This is the closest thing to "send someone the results," and the setting that matters is the visibility on that link — check it deliberately, because the difference between "anyone in the workspace" and "anyone with the link" is the difference between internal and published.

Where this leaves a common request

An external reviewer, a client, or an executive needs to read one analysis. They should not be a workspace member. A permanently live public app link is more exposure than the request warrants, and it also keeps re-executing against whatever the notebook currently is — so the thing they read on Monday may not be the thing you approved on Friday.

What that reader wants is a dated, frozen copy of the analysis at a URL, with a way to ask about one figure.

Export and publish

Export the notebook as .ipynb and render it:

jupyter nbconvert --to html --execute --no-input analysis.ipynb --output report.html

--execute regenerates the outputs, --no-input drops the code so it reads as a document. Interactive charts survive — Plotly, Altair, Bokeh and folium are client-side JavaScript, so hover and zoom keep working provided the library is embedded rather than fetched from a CDN at view time.

Then publish it and hold onto the id:

curl -fsS -X POST "https://commareports.com/api/v1/reports" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html report.html \
        --arg title "Pricing experiment — readout" '{title: $title, html: $html}')"

PATCH the same id on later runs and every version is kept as a revision at one URL. A routine can drive the re-run and republish on a schedule if the analysis is a standing weekly.

What the frozen copy gives you

A stable subject for the conversation. A live app changes under the reader's feet; a revision does not. When someone comments on the elasticity estimate, everyone else is looking at the same estimate.

Access without seats. Visibility is a setting on the report — private, team, domain-gated or link — so "anyone at client-co.com" works with no workspace invitation and no public link.

A history that outlives the notebook. Deepnote's block comments live with the notebook and do not travel to any export. Anchored threads on a published report persist across revisions, so the reasoning from three runs ago is still attached to the figure it was about.

When to just use Deepnote

Keep the work in Deepnote and invite the person when they are going to do something — edit a query, change a parameter, co-author the analysis. That is the product's strength and no static export competes with it. Export and publish when the audience reads, reviews, or signs off.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Create your first report →

Related