Documentation

Local tools that know each other.

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.

Whitepaper · the long read

Build on Shippie

The category: cloud platforms deploy cloud apps, Netlify deploys static sites, Shippie deploys local tools. Start here if you want the why before the how.

Read the whitepaper →

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.

For users

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.

Where data lives

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.

Your data — where it lives, who sees it

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.

No signup needed (most of the time)

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.

For builders

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.

Getting started

Three entry paths, same policy scanner. Pick the shortest one for your codebase.

Drop a zip in the browser

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/

Push from the CLI or MCP

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.

Convert a hosted app

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.

Connect a GitHub repo

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.

SDK

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.

Wrapper

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.

Private spaces

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.

Local Runtime

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.

GitHub auto-deploys (the honest version)

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.

Remix

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.

What "remixable" looks like

Every public app page shows an Open source badge and a Remix this button when three conditions are met:

  • The maker has published a sourceRepo (a public GitHub URL).
  • The maker has selected an OSI-recognised license.
  • The maker has flipped 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.

How to remix someone else’s app

  1. Open the app’s page and click Remix this.
  2. Shippie sends you to /new?remix=<slug> with the source repo, license, and starter config pre-filled.
  3. Fork the repo on GitHub (one click), make your changes, then ship it: zip upload, CLI, or re-connect the fork for auto-deploy. The remix lands at <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.

How to enable remix on your own app

  1. Open your app in the maker dashboard.
  2. Under Profile, set the Source repo to a public GitHub URL.
  3. Pick a License (MIT, Apache-2.0, AGPL-3.0, etc.).
  4. Tick Allow remixes.

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.

Why this matters

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.

Open source

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.

License positions

Two licenses, picked deliberately so the platform can federate and the SDK can spread:

WhatLicenseWhy
Platform · edge worker · AI iframe · HubAGPL-3.0Fork 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 · templatesMITLink into your apps without constraint. The SDK is the part that should spread to every project, including closed-source ones.

Self-hosting

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.

Contributing

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.