When you build a tool that works, the next question is always: how do I get it to someone else?
This sounds simple. It is not. The answer depends on who the recipient is (developer or non-technical user), where the data lives (local or remote), and whether a human or an AI agent will be the one calling the tool. Over the past year of building local-first AI tools on SQLite, vLLM, and Cloudflare Tunnel, I have used seven distinct methods to share what I build — and each one trades off something different.
This post maps those seven methods to the tools I actually use: GitHub, Claude Code, Google Workspace, Cloudflare, Notion, and Tailscale. No hypothetical architecture. Every row in the table below corresponds to something running in production.
Before the seven: what are you sharing?
The seven methods are delivery mechanisms. Before choosing one, it helps to ask what the thing being delivered actually is. In practice, I share three kinds of artifacts, and each has a different risk profile:
Deterministic code — a FastAPI endpoint, a CLI tool, a GAS script. Same input, same output. The risk is bugs. You can read the code and verify what it does before running it.
An AI agent — a Nemotron CLI session, a Claude Code skill, an MCP-connected workflow. Same input, different output every time. The risk is unpredictable behavior. You cannot fully verify what the agent will do, only constrain it. This is the artifact that Cloudflare OS's Gatekeeper model was designed to contain.
A database (+ viewer) — a large SQLite corpus, a Google Sheet, a Notion workspace. Not executable, but stateful and mutable. The risk is data leakage and integrity loss. The viewer (search UI, dashboard, Notion page) and the data are logically separate but practically inseparable — you almost never share one without the other.
These three do not have clean boundaries. A WebUI is deterministic code backed by a database, operated by a human. An MCP server wraps deterministic code that an AI agent calls to access a database. But when deciding how to share something, knowing whether the core artifact is code, an agent, or data clarifies which of the seven methods fits.
The seven methods
Lightweight ──────────────────────────────────→ Heavyweight
⑤ CLI/Script ① Library ⑦ Container ③ WebUI ② API ⑥ MCP Server
(pip install) (import) (docker run) (browser) (HTTP) (AI discovers)
④ Shared DB sits underneath all of the above
The left side is lighter to set up, requires less infrastructure, and assumes the recipient has some technical ability. The right side is heavier, but accessible to non-technical users and — critically — to AI agents.
One axis cuts across the whole spectrum: who integrates? With everything on the left (①⑤⑦), a human reads the README, understands the interface, and writes the glue code. With ⑥ (MCP), an AI reads the schema and integrates on the fly. With ② (API), it can go either way — a human writes a client, or an AI calls the endpoint through a tool. This distinction between human-integrated and AI-integrated sharing is new. A year ago it did not exist. It is now the most consequential design decision in the stack.
---
① Library sharing
What it is: Packaged code that someone else imports into their own project.
Tools involved: GitHub (private org repo) → recipient clones or installs.
How I actually do it: When I build a utility — a SQLite FTS5 wrapper, a Cloudflare Tunnel health-check module, a TOML config loader — I push it to a GitHub org repo. A colleague clones it, reads the README, and imports what they need.
The key step is distillation. Before sharing, I use Claude to compress the codebase: strip test fixtures, collapse verbose modules, remove credentials, add a minimal README. The recipient gets a clean package, not a dump of my working directory.
What it trades off: The recipient needs to understand the code well enough to integrate it. There is no UI, no running service, no "just click here."
Update model: The recipient runs git pull when they want to update. Ownership stays with the original author. This is explicit, user-initiated updating — the opposite of over-the-air.
---
② API-based integration
What it is: A running service that exposes HTTP endpoints. Others call it without seeing the internals.
Tools involved: FastAPI on VPS (Ubuntu) → Cloudflare Tunnel → public URL.
How I actually do it: HoureiLLM (semantic search over 241,879 articles across 8,928 Japanese laws) and PatentLLM (FTS5 over a US patent corpus) both run as FastAPI services behind Cloudflare Tunnel. Anyone with the URL can search. The caller does not need Python, SQLite, or any of my dependencies. They send a query, they get JSON back.
The Nemotron-9B inference server works the same way: vLLM exposes an OpenAI-compatible API on port 8000, and the CLI tool I built connects to it over HTTP. The API boundary means I can swap the model, change the hardware, or rewrite the server — and the CLI does not care.
What it trades off: The service must be running. If my VPS goes down, the API goes down.
Update model: The provider updates silently. The consumer does not know and does not need to know. This is over-the-air by default — and that is both the strength (zero friction) and the risk (breaking changes arrive without warning).
vs. MCP (⑥): An API requires a human to read documentation, understand the schema, write a client, and handle errors. MCP wraps the same HTTP transport in a protocol that AI agents can discover and call without human integration work. The underlying mechanics are similar; the integration subject is different. I separate them because that difference — human-integrated vs. AI-integrated — changes the sharing model fundamentally.
---
③ WebUI application
What it is: A browser-based application that non-technical users can operate.
Tools involved: FastAPI + Jinja2 + vanilla JS → Cloudflare Tunnel → browser.
How I actually do it: Recycle Paperless, the route-optimization PWA for recycling logistics, is a WebUI. Drivers open it on their phones, input collection data, and the admin dashboard shows real-time progress. The drivers do not know (or need to know) that the backend is FastAPI + SQLite WAL on a Chromebook.
This is where sharing stops being about code and starts being about experience. A WebUI has to handle edge cases, show loading states, work on mobile, recover from network drops. In my experience the engineering effort runs several times that of exposing the same functionality as an API.
What it trades off: Development cost and maintenance burden. Every browser quirk, every mobile viewport, every offline scenario is your problem.
A note on hosting: The Chromebook running Recycle Paperless is, architecturally, a server. My RTX 5090 machine running vLLM is a server. In a world where consumer hardware can run inference and serve applications, any PC becomes a potential host. This changes the economics: instead of paying a cloud provider, you are paying your electricity bill. Cloudflare Tunnel makes these personal-hardware servers reachable without a static IP. The server does not need to be in a data center. It just needs to stay on.
---
④ Shared database
What it is: A database that multiple tools or people read from (and sometimes write to).
Tools involved: SQLite files on VPS, accessed via API (②) or SSH (Tailscale).
How I actually do it: The PatentLLM database is a shared resource. The search UI reads it. Analysis scripts read it. Claude Code reads it (when I point a session at the VPS via Tailscale SSH). The database is the single source of truth; everything else is a view on top of it.
For lighter data, I use Google Sheets via Clasp → GAS. A shared spreadsheet becomes a pseudo-database that non-technical stakeholders can read and update. Clasp scripts automate the ingestion and transformation.
Notion serves a similar role for structured project data. Claude accesses it via MCP, and team members access it through the Notion UI. Same data, different interfaces.
What it trades off: Concurrency and access control. SQLite with WAL mode handles moderate read concurrency well, but write contention requires discipline. Google Sheets has its own limits. Notion's API has rate limits that matter for automation.
Dependency chain:
- SQLite: VPS disk → Tailscale SSH or FastAPI → consumer
- Google Sheets: GDrive → Clasp/GAS → consumer
- Notion: Notion API → MCP → Claude / Notion UI → human
---
⑤ CLI tools and scripts
What it is: A command-line tool that someone installs and runs locally.
Tools involved: Python script → recipient runs with python tool.py or pip install.
How I actually do it: The Nemotron CLI I built is a 200-line Python script with one dependency (httpx). I hand someone the file, they point it at their vLLM server, and they have a full async streaming chat with conversation history, file loading, and system prompt customization.
This is the lightest form of sharing that includes AI. No server, no account, no subscription — just a script and a model.
Claude Code's .claude/skills/ folder is a variant of this. Skills are not just prompts; they are folders containing scripts, data, and instructions that Claude discovers and uses. Sharing a skill folder via GitHub is sharing a CLI toolkit that an AI agent operates instead of a human.
What it trades off: The recipient needs a compatible environment. Python version, OS, GPU drivers (if running inference). The "it works on my machine" problem is real.
Update model: Once I hand over the script, the recipient owns it. There is no update channel unless they git pull from the original repo. Ownership transfers at the moment of handoff. This is the opposite of an API (②), where the provider retains full control. Cloudflare OS's Blueprints look similar in this respect: a Blueprint is a copy of the code that the recipient forks, and as of this writing the documentation describes no versioning, tagging or changelog mechanism that would carry updates back to the fork. Neither approach has solved over-the-air updates for shared code that runs on someone else's machine.
---
⑥ MCP Server
What it is: A service that AI agents can discover and call without human integration work.
Tools involved: MCP server → Claude Code / Claude.ai → AI calls tools automatically.
How I actually do it: Notion and Google Drive are connected to Claude via MCP. When I ask Claude to "update the project status in Notion," it calls the Notion MCP server, finds the right page, and makes the edit. I did not write integration code. The MCP server handles tool discovery, authentication, and execution.
The interesting frontier is making my own services available as MCP servers. If HoureiLLM exposed an MCP interface, anyone with Claude Code could say "find statutes related to tenant rights" and get vector search results without knowing the API exists. The AI discovers the tool, reads the schema, and calls it.
What it trades off: You are delegating tool selection to the AI. When Claude chooses which MCP tool to call, you cannot always predict the path it will take. Debugging requires reading tool-call logs rather than tracing HTTP requests.
Why this is separate from ②: An API and an MCP server can expose the same functionality over the same transport. The difference is the integration subject. With an API, a human reads docs, writes a client, handles auth. With MCP, an AI reads the schema and writes the integration on the fly. This means MCP sharing scales differently — adding a new consumer costs zero human effort. But it also means you cannot predict how the consumer (the AI) will use your tool.
---
⑦ Container image
What it is: A Docker image that packages your tool with all its dependencies.
Tools involved: Dockerfile → registry → recipient runs docker run.
How I actually do it: For tools that have complex dependencies (system libraries, specific Python versions, CUDA toolkit), I package them as Docker images. The recipient pulls the image and runs it. The environment is identical to mine.
This sits between ① (library, recipient integrates) and ③ (WebUI, recipient opens a browser). The container runs locally but is self-contained.
What it trades off: The recipient needs Docker. The images can be large (especially with ML dependencies). And containers add a layer of indirection that makes debugging harder — you are inside the container's filesystem, not your own.
---
The layer beneath: shared workspace
The seven methods above are all ways to share artifacts — finished (or at least functional) things. But there is a layer underneath: sharing the workspace itself.
When multiple developers SSH into the same VPS via Tailscale, edit the same codebase with vim, and coordinate via git branches, they are not sharing an artifact. They are sharing a development environment. The code is not yet a deliverable — it is a work in progress that multiple people are simultaneously shaping.
This is not one of the seven methods because it is not a delivery mechanism. It is the process that produces what gets delivered. But it matters for the taxonomy because Cloudflare OS's multiplayer Gadgets — every Gadget is backed by a Durable Object, which is what makes real-time collaboration cheap there — and GitHub's PR-based collaboration are both trying to formalize this layer, and they make very different trade-offs. Tailscale SSH gives you a shared Unix environment with full power. GitHub gives you async code review with version control. Durable-Object-backed multiplayer gives you real-time sync inside a sandbox. Each constrains the collaboration differently.
---
The dependency map
Every method depends on a combination of infrastructure services. Here is how they connect:
GitHub ─────────── code storage, version control, org permissions
│
├─→ ① Library (clone/fork, git pull to update)
├─→ ⑤ CLI (clone, run locally)
└─→ ⑦ Container (Dockerfile in repo, build and push)
Claude Code ────── AI-powered development and execution
│
├─→ ① Library (Claude distills code before sharing)
├─→ ⑤ CLI/Skills (.claude/skills/ shared via GitHub)
└─→ ⑥ MCP (Claude discovers and calls MCP servers)
Cloudflare ─────── network layer, access control, and hosting
│
├─→ ② API (Tunnel exposes FastAPI services)
├─→ ③ WebUI (Tunnel exposes browser apps)
└─→ ④ DB (Tunnel provides access path to SQLite on VPS)
Google Workspace ── collaborative data and automation
│
├─→ ④ DB (Sheets as lightweight shared database)
├─→ ⑥ MCP (GDrive connected to Claude via MCP)
└─→ ⑤ CLI (Clasp → GAS scripts for automation)
Notion ─────────── structured project data
│
├─→ ④ DB (project data, accessed by team via UI)
└─→ ⑥ MCP (Claude reads/writes Notion via MCP)
Tailscale ────────── secure access to infrastructure
│
├─→ shared workspace (multiple devs on same VPS)
├─→ ④ DB (SSH to VPS, direct SQLite access)
└─→ maintenance (systemctl, vim, git pull, deploy)
A note on each PC as a host: In this map, Cloudflare Tunnel and Tailscale together turn any machine into a reachable server — a Chromebook, a gaming PC with an RTX 5090, a mini PC under a desk. The seven methods do not require a data center. They require a machine that stays on, a network path (Tunnel for public, Tailscale for private), and the ability to run a process. When your colleague's idle GPU could run your inference job, or your Chromebook could serve a PWA to field workers, the boundary between "personal computer" and "server" dissolves. The sharing methods stay the same. The hosting model changes.
When to use which
| Your situation | Best method | What you are sharing |
|---|---|---|
| Sharing a utility with a developer | ① Library via GitHub | Deterministic code |
| Running a service others query | ② API via Cloudflare Tunnel | Code + database |
| Non-technical user needs to interact | ③ WebUI via Tunnel | Code + database + experience |
| Multiple tools need the same data | ④ Shared DB | Data (+ viewer) |
| Quick tool for a technical recipient | ⑤ CLI/Script | Code or agent |
| AI agents need to call your tool | ⑥ MCP Server | Code, wrapped for AI |
| Complex dependencies, exact reproducibility | ⑦ Container | Code + environment |
| Co-developing something not yet finished | Tailscale SSH + git | Workspace (not an artifact) |
The question is never "which one is best." It is "which combination covers your team." A solo developer might use only ①⑤ and never touch ③⑥. A team with non-technical stakeholders needs ③④⑥. An organization with compliance requirements might need Cloudflare OS's Gatekeeper model on top of ②③⑥ — specifically because those methods involve AI agents touching shared data, and the risk profile of agent-operated tools is fundamentally different from human-operated ones.
The seven methods are not a ladder. They are a palette. But the palette has a new color that was not there a year ago: the AI-integrated channel (⑥), where the consumer of your tool is not a person but an agent. That color changes what "sharing" means — and we are still figuring out how.
---
I build local-first AI tools on SQLite, vLLM and Cloudflare Tunnel. Related work: PatentLLM (US patent search on FTS5), HoureiLLM (semantic search over 241,879 articles of Japanese statute law), and a 200-line async Nemotron CLI. Descriptions of Cloudflare OS in this post reflect the repository documentation as of 2026-08-16.