Where InkRider Runs Your Data (And What Never Hits Our Servers)

Before legal or IT signs off on code in Word, they ask one question: where does our data go?

InkRider is built so the default answer is: your machine and your document, not our cloud.

Two Runtimes, One Add-In

Runtime	Where code runs	Typical use
JupyterLite (local)	In the browser (Pyodide)	Pandas, charts, API calls that fit a pure-Python stack
Jupyter Server (remote)	Your laptop or VPC (Professional)	Databases on VPN, heavy libs, pinned corporate environments

You pick the runtime in settings. Switch when a workflow outgrows the in-browser kernel.

What Stays Local

• Notebook files and project data in the add-in virtual filesystem (IndexedDB in the browser).
• Secrets Vault credentials: injected into the kernel at session start, not stored in .docx XML` and not sent to InkRider backends. Colleagues use their own vault on their machine.
• Execution of your cells under your chosen runtime. We are not running your model training on shared infra.

Large assets can embed in the document (CustomXML) or sync via OneDrive paths you control, per your storage strategy.

What You Still Govern

• Who receives the Word file (email, SharePoint, client portal).
• Whether notebooks are embedded in the doc or kept in a repo.
• Notebook signing and XML integrity checks when you need tamper awareness.

InkRider adds automation inside a format you already audit. It does not replace your DLP, retention, or access policies.

Fit for Regulated Teams

Use Jupyter Server on infrastructure you operate when data cannot leave a network zone. Use JupyterLite when the dataset is small and browser-local execution is enough. Use drift indicators when mixed human and computed text must coexist.

The pitch is not "trust the cloud." It is keep Word, add code, keep control of where that code runs.

Try the interactive demo or a pilot on a non-production template. Security review gets easier when the architecture diagram is boring.