SubmitFleet

One product profile. Coordinated submissions. Proof of what went live.

SubmitFleet is an open-source, self-hostable engine for submitting legitimate products to launch sites and directories. It keeps one approved product profile, plans a bounded campaign, asks the owner to approve exactly what will be sent, runs durable workers, and records receipts and verified listings. The same core serves a CLI, a TUI, an HTTP API, an MCP server and a mobile dashboard.

Status

Live at https://submitfleet.pwa.pit.world.

• Accounts: sign up with a passkey, email + password, or an emailed link. Each account gets its own workspace. submitfleet login signs the CLI in through the browser (OAuth 2.1 + PKCE).
• Catalog: 339 launch sites and directories (the CC0 awesome-submitlist catalog), 203 free to list, with price, eligibility, audience, link type and traffic for each.
• Assisted submissions: for every destination SubmitFleet prepares each form field from your approved product facts, links the submit page and tracks submitted, live (with the listing URL), rejected or skipped. Destinations are ranked by fit, and niche or platform-only directories that do not match your product are left unchecked.
• Automatic submissions: only where a destination's API permits it and an adapter has been proven against it. Today that is 0 of 339 (submitfleet coverage report); the TinyLaunch adapter is contract-tested but has not made a live submission yet.

What the engine enforces

• The release gate. A destination counts only if it is a launch site or directory, verified free with fresh evidence, permission-reviewed, unattended (not assisted, not always-captcha), has an installed adapter with contract tests, owner-authorized live-submission evidence, reconciliation (or a documented limitation), healthy status and an accepted quality review. Counts are of independent listing groups, so aliases, mirrors and language paths never multiply coverage. Imports from public lists are discovery input only and can never enable execution.
• Strict campaigns. --min-executable-destinations defaults to 100. A campaign with fewer executable targets returns coverage_insufficient with the real count and every blocker, and cannot be approved or run. The owner may plan a smaller campaign explicitly; the engine gate is unchanged.
• Approvals bound to scope. The owner approves a hash of the exact targets, accounts, payloads, product facts, dates and spend limits. Any material change invalidates it. Agents (and the MCP server) can request approval but there is no agent path to grant it; the CLI only approves from an interactive terminal.
• Free only by default. Listing spend is fixed at $0. Paid, conditional-free and backlink-required routes are excluded. An adapter that meets an unexpected payment stops for a human.
• Durable, honest execution. Intents are persisted before any external write. Workers claim atomically with leases and fencing; per-account queue limits and cooldowns are enforced inside the claim. A timeout after a possible write is uncertain and is reconciled before anything is retried. Submitted, scheduled, under review and published are separate states. The event history is append-only.
• Bounded spend. Operating costs are reserved atomically before dispatch and settled after, so parallel workers cannot overspend.
• Stops. Global pause, campaign pause, account disconnect and destination disable all stop new writes. Cancel stops unsent work and never claims remote deletion.
• Secrets. Account credentials are sealed to your workspace key vault (a passphrase only you hold; the server cannot open them) and run only while you have unlocked it. They never appear in model context, reports or logs. Workspaces are isolated.
• Reports. Original target set, exclusions, receipts, listing URLs, unresolved jobs, effort and itemized cost, in Markdown, JSON or CSV. Missing analytics or effort stay unknown, never zero.

Quick start (self-hosted)

pnpm install && pnpm build
node dist/cli.js init                 # workspace, secret key, owner API key (shown once)
node dist/cli.js catalog seed
node dist/cli.js coverage report      # exit 3 while below 100
node dist/cli.js products add https://your-product.example --name "Name" --tagline "..." \
  --description "..." --logo logo.png --field tinylaunch.category_id=9
node dist/cli.js products approve PRODUCT_ID
node dist/cli.js vault init                # passphrase + one-time recovery key; credentials are sealed to it
node dist/cli.js accounts connect tinylaunch --email [email protected]
node dist/cli.js campaign plan --product PRODUCT_ID --free-only --min-executable-destinations 100
node dist/cli.js campaign preview CAMPAIGN_ID
node dist/cli.js campaign approve CAMPAIGN_ID
node dist/cli.js campaign run CAMPAIGN_ID
node dist/cli.js worker               # or: serve (API + dashboard + worker)
node dist/cli.js report export CAMPAIGN_ID --format markdown

Assets (logos) are read only from $SUBMITFLEET_HOME/assets. Run submitfleet help for every command. Exit codes: 0 ok, 1 error, 2 usage, 3 gate not met, 4 jobs waiting for a person.

This is the beginning of the README. Read the rest at the original. Read the full README ↗