Local
Public Shippie tools are expected to keep primary user data on the device by default, with no hidden login, tracker, or third-party user-data store.
Documentation
If it is on Shippie, data movement is visible. Build tools with one-line local database, zero backend setup, secure backup as continuity, and deploy paths that disclose outside connections before publish. Quiet local tools stay visually quiet; Shippie only raises a signal when something extra is connected.
Local
Public Shippie tools are expected to keep primary user data on the device by default, with no hidden login, tracker, or third-party user-data store.
Build
Use one-line local database, local files, local AI, intents, and secure backup without provisioning a backend.
Connect
Tools can share local signals with each other and use encrypted Shippie relay when live collaboration needs it.
You don’t need an account, a download, or a credit card to use Shippie. Open a tool. If you like it, save it. Your data controls stay close by.
On Shippie, primary user data stays on the device by default. Reference data can come in, and user data should not go out unless you explicitly export, back up, sync, join an encrypted relay, or connect a disclosed service.
Tap "Your data" inside any tool to see what is stored on this device, what connections are disclosed, and which export, restore, backup, or wipe controls that tool supports. The default local path does not store app content on Shippie servers; optional backup, sync, relay, and private spaces are shown separately.
Tools open and work without an account. Sign in only when you want to ship your own tool, sync saved tools across devices, or join a private space someone invited you to.
Ship a local tool in under a minute. Pick the shortest path to a live URL, then come back to layer in haptics, local data, intents, secure backup, and proof — mostly automatic.
Three entry paths, same policy scanner. Pick the shortest one for your codebase.
Visit /new and drag in a built local tool. We unpack it, scan it for local-tool eligibility, wire the wrapper, and put it live.
# dist/, build/, out/, or a single HTML file all work shippie deploy ./dist # → live at https://your-app.shippie.app/
CLI and MCP use the same deploy API as the browser zip upload. If Supabase, Firebase, Auth0, analytics, ad code, insecure connections, or bundled secrets are detected, the deploy is blocked with conversion guidance. External services are allowed by default when they can be disclosed cleanly.
Hosted URL wraps are retired for marketplace publishing. Convert user data paths to shippie.local.db and shippie.local.files, then upload the built bundle.
For automated builds on every push. We clone, install, build, and upload — typically in 2–5 minutes. Slower than direct zip uploads, but you don’t have to think about it.
The maker entry point is @shippie/sdk. Store records with shippie.local.db.save(), list them with shippie.local.db.list(),
write attachments with shippie.local.files, and broadcast useful local signals
with Shippie intents.
import { shippie } from '@shippie/sdk';
await shippie.local.db.save('receipts', receipt);
const receipts = await shippie.local.db.list('receipts'); @shippie/sdk/wrapper is the runtime injected into every Shippie-hosted page. It
provides the device-ready shell, push subscriptions, ratings UI, offline coordination, and a
structured event spine that flows back to the marketplace.
Every export is opt-in. The base wrapper is <5kb gzipped. Add features by importing them.
Full reference moves into /docs/sdk in a later cut — until then, the README
in packages/sdk is the
source of truth.
The wrapper is the HTML rewriter that runs at the edge. It injects the PWA manifest, the service worker registration, the SDK runtime, and device-ready support — without touching your bundled code.
Wrapper config lives in a tiny shippie.json at the root of your deploy. App
name, theme colour, icon path, and any opt-in capability flags. Sensible defaults for every
field.
A private space is Shippie’s shared context for a tool: a room, class, household, team, trip, or match-day group. Builders do not write account systems to use it. They declare the roles their app understands, then Shippie generates signed invite links and QR codes that carry only that scoped access.
The public app can stay listed on the marketplace while each space stays private to the people holding its link. Shippie can count joins and archive a space, but the space content stays sealed to the members and devices that hold the keys.
The same edge worker runs locally via wrangler dev. D1 has a local SQLite mode,
R2 has a filesystem-backed mode, KV has an in-memory mode. Your dev loop hits the same
bindings the production worker does — no Docker, no cloud round-trips.
Connect a GitHub repo to a Shippie app and every push triggers a build. We clone the repo, install dependencies, run your build script, and upload the output to R2. Typical end-to-end time: 2–5 minutes. The cold runner is the floor; npm install variance is the spread.
If you need under-a-minute deploys for a GitHub-tracked project, set up a CI step that ships the
built artifact via shippie deploy ./dist. Same speed as the web upload.
Shippie apps can be remixable. If the maker has flagged it on, anyone can fork the source, tweak it for their niche, and ship the result back to the marketplace under a new slug — through the same local-tool scanner as the original. This is how good ideas become good ideas for everyone.
Every public app page shows an Open source badge and a Remix this button when three conditions are met:
sourceRepo (a public GitHub URL).license.remixAllowed on in their app profile.All three are per-app, controlled by the maker. A Shippie listing without that trio is hosted on Shippie but not fork-friendly — the maker is welcome to enable it later.
/new?remix=<slug> with the
source repo, license, and starter config pre-filled.<slug>-remix by default and you can rename it freely.# CLI shortcut after a one-click fork shippie deploy ./dist --slug my-recipe-saver --remix recipe-saver
Lineage is recorded automatically. Your remix page links back to the original; the original shows a count of remixes downstream. Credit travels with the code.
That’s it — the badge and the Remix button appear on your public page within seconds. Toggle it off at any time and the affordances disappear for new visitors; existing remixes continue to exist on their own.
One vibe-coded recipe saver becomes ten: a sourdough version, a vegan version, a restaurant-staff version, a five-ingredient version. The same code skeleton, niche-tuned by people closer to the niche than the original maker could ever be. Software diversity used to require a fork on a hidden engineering team’s back-burner. On Shippie it’s a button.
The whole platform — control plane, edge worker, SDK, CLI, container, AI iframe — lives at github.com/theprovider123/shippie. Fork it, deploy it, run it on your own Cloudflare account. Nothing is hidden behind a paid tier.
Two licenses, picked deliberately so the platform can federate and the SDK can spread:
| What | License | Why |
|---|---|---|
| Platform · edge worker · AI iframe · Hub | AGPL-3.0 | Fork and self-host freely; network-accessible modifications must publish under the same license. The platform is the part worth federating. |
| SDK · CLI · MCP server · shared types · templates | MIT | Link into your apps without constraint. The SDK is the part that should spread to every project, including closed-source ones. |
You’ll need a Cloudflare account, a domain you control, and the patience to register OAuth clients with GitHub and (optionally) Google. The hosted Shippie costs $5–10/month at our scale; your bill will be similar or smaller depending on traffic.
Walkthrough: see docs/self-hosting.md in the repo. Stale sections are flagged at the top — follow the Cloudflare-only path, not the legacy Postgres one.
Issues, PRs, and discussions live on GitHub. The repo has a top-level CONTRIBUTING.md and active maintainers. Small fixes get merged within days;
bigger architecture changes get a design-doc round first.