Skip to content
Starterdough
Menu
Public demo. Sample use only; demo accounts and data have a scheduled daily reset. The source kit is a separate $99 one-time purchase at starterdough.dev. Privacy · Terms

Changelog

What shipped

Release notes for Starterdough, newest first.

Current version: v1.2.0

  1. v1.2.0

    Product seams, one-machine serving and settings in a dialog

    What the first product built on the kit asked for. More of the places your product plugs in are files of its own, so code that used to edit a kit file stops conflicting with releases. Start with Breaking in CHANGELOG.md: a development API listens on loopback alone, apps/api’s start script reads no .env, settings pages lost their layouts, and the job registry’s exports are functions. One migration, for the job queue.

    • More product files. Raw HTTP routes and their body limits, environment variables, CSP sources, a step when a session ends, at shutdown and at sign-out, commands in the palette, sections of the settings dialog, copy for your contract’s refusals, your dependencies, licence notices, decisions, the API image’s Debian packages and seed data each have a file the kit never changes. So do worker loops, procedures a public demo refuses, organization roles of your own and which workspaces a member sees.
    • bun run serve. The whole app on one machine without Docker, behind one origin that tailscale serve publishes to your devices, and a desktop or mobile shell that asks which server to use, so one installer serves every deployment.
    • Visitors, not addresses. The procedure limiter counts people once it knows who is calling, and the web server signs each visitor’s address for the API, so rate limits and sign-in checks count the visitor rather than the web container.
    • Deployments. Close sign-up (an invitee still gets in), run production with email in the API’s log, answer sessions from a signed cookie, and cap teams per organization with MAX_TEAMS. A deploy stops your own database writers while it migrates.
    • Database. Id lists that stay fast under stale statistics, transactions that retry after a deadlock, indexes built without blocking writes, db:generate --check and --undo, time zones Postgres can read, and LISTEN that survives a dropped connection.
    • Jobs. Priorities, a dedupe key, bulk enqueue, a time budget per kind, progress, and leases that let the sweep take back only a dead worker’s jobs. A job queued anywhere wakes every worker, and a stopping worker gives its jobs back.
    • The app. The sidebar holds the app and a dialog over the page holds its settings. The organization’s name opens a menu that switches organizations, and its workspaces are listed under the navigation. @repo/ui gains a slider, toggle groups, a context menu, resizable panes, a drawer a swipe closes and touch gestures.
    • Tests. Database suites claim their ids and sweep what an interrupted run left, test:db:all runs every one, test:e2e:full runs signed-in browser suites against the real API, component specs run in WebKit too, and smoke:desktop runs the shell against a stub API.
    • Fixed.
      • Images the API serves render on another origin, and no page reports a CSP violation.
      • A first visit no longer offers an update, and a rate-limited session lookup no longer signs anyone out.
      • An invitee without an account arrives at the invitation after signing up.
      • An expired invitation stops holding a seat on a database that does not run UTC.
    • Security and dependencies.
      • vite 8.3.4 for three advisories in its editor launcher.
      • Hono 4.13.13 and certifi 2026.10.19.
      • Every other dependency moves to its newest release in range, Tauri 2.12 among them.
  2. v1.1.0

    Teams, API keys, webhooks and product files of your own

    Your product gets files, a migration history and a version of its own, none of which a kit release touches, so what you put there no longer conflicts with an upgrade. Start with Breaking in CHANGELOG.md: this release carries four migrations, and each entry there asks something of you when you merge.

    • Product files the kit never changes. Each place your product plugs into the kit is a file or folder of its own: schema, contract, router, permissions, emails, jobs, labels, the sidebar and workspace tabs, site content, product docs and deploy hooks. The new “Where your code goes” guide lists them.
    • Two migration histories. bun run db:generate writes yours to packages/db/drizzle-product, bun run db:migrate applies the kit’s history and then yours, and says how many of each it applied. bun run db:move-product-migrations moves the migrations you generated on 1.0.0, and bun run db:kit-drift prints the SQL a change to a kit table needs.
    • version is yours, kitVersion is the kit’s. /health, the OpenAPI document, the site and the desktop builds report your product’s version; /admin/system also shows the kit release.
    • Teams are access boundaries. A workspace scoped to a team, its documents, jobs, search results and uploads reach only the team’s members and the organization’s owners and admins. Members delete only what they uploaded, and a team that still has workspaces cannot be deleted. One tenant guard runs before every organization procedure, and a test fails for one that skips it.
    • Organization API keys. Owners and admins create scoped keys under Organization → API keys. A key is shown once and stored only as a hash, belongs to the organization, can expire or be revoked, and is rate-limited. It works on the REST and RPC procedures whose contract opens them to keys, and the OpenAPI document names the grant each one needs.
    • Outbound webhooks. Signed events for members, workspaces, documents, jobs and subscriptions, delivered from the job queue and retried over about 21 hours, with a delivery log, redelivery and secret rotation per endpoint. Private and loopback addresses are refused, redirects are never followed, and every attempt ends within 10 seconds. WEBHOOKS_ENABLED=false switches them off for a whole deployment.
    • An audit log customers can use. Its own page with action and date filters and a CSV export, a view across organizations for platform administrators, and entries that name the API key that acted.
    • Stored files, plan features, yearly billing and product jobs. Register kinds of file your product keeps (attachments, avatars, exports), uploaded the way documents are and deleted with the row that owns them. Gate a procedure on a plan feature from the catalog, which now drives limits, /pricing and billing too. Offer a yearly price for a flat-priced plan. Declare job kinds and recurring schedules of your own.
    • Email in the user’s language. Verification, password-reset, email-change and account-deletion mail follow the language the app shows, in English and German; an invitation follows the inviter’s.
    • Deploys and operations. The server’s SSH host key is pinned, DEPLOY_PATH is required, and a deploy refuses a checkout that does not run this product’s Compose project. It checks the server’s clock, takes a restore point before it stops anything, runs your pre- and post-deploy hooks, and smoke-tests the public URLs. abandon gets a failing migration out of the way of its fix. Server status, Server logs, Server backup and Admin bootstrap work without a shell.
    • What a build publishes. The site ships draft samples in place of the kit’s release notes, the docs build publishes your product’s documentation (DOCS_CONTENT=kit builds the developer manual), and a production build refuses legal pages that still hold template placeholders.
    • Security. Better Auth 1.7.7 fixes three advisories (the kit as shipped was not exposed). TRUSTED_ORIGINS=null stops the API at start-up, the off-site backup credentials reach only the backup service, the GitHub Actions move to their node24 releases, and the base and service images are pinned to patch releases.
    • Fixed. A live restore leaves the database holding exactly what the backup holds, a dialog taller than the window scrolls inside it, a fresh bun install no longer rewrites bun.lock, and the AI service reads UTF-16 text without a byte order mark.
  3. v1.0.0

    Documents, AI, operations and SvelteKit 3

    The first tagged release, and the first one to upgrade from. Start with Breaking in CHANGELOG.md.

    • Upgrades follow release tags. UPGRADING.md starts you on the newest release and renames each one on a kit-renamed branch before main merges it, so a renamed fork conflicts only where you and the release changed the same lines. This release carries four migrations. Three need steps before you deploy (see Breaking), and bun run db:migrate applies whichever your database lacks.
    • Licence 1.1. LICENSE.md names the two licences sold, Solo (one Invited Account) and Team (up to five, plus a 45-minute onboarding call). Purchases from 8 October 2026 get an Update Period of 12 months from the purchase; earlier ones keep the update terms they were sold with.
    • SvelteKit 3. The web app runs on SvelteKit 3.0.1 and Svelte 5.57.2. $lib is now #lib, environment variables are declared in apps/web/src/env.ts, and an installed Node.js must be 22.17 or newer. UPGRADING.md lists the changes your own code needs.
    • Documents, jobs and AI. Presigned uploads to local disk or S3/R2/MinIO, a Postgres job queue that runs inline or as a separate worker, an AI-credit ledger, and Documents and Jobs pages. The FastAPI service extracts text (with OCR), summarizes and embeds, locally or through any OpenAI-compatible endpoint. Workspaces get pgvector search and storage quotas.
    • A home page. /app shows a getting-started checklist that hides once every step is done: verify the address and add a passkey or two-factor authentication. It also shows the organization’s member and AI-credit counters and its workspaces, and the checklist asks for a first workspace and an invited teammate too.
    • Setup. bun run setup writes every local .env, bun run doctor checks prerequisites and configuration, bun run verify runs lint, typecheck and test in CI’s order, and bun run rename renames the kit to your product. QUICKSTART.md is the one setup guide; AGENTS.md gives coding agents the layout, the commands and the rules the code relies on. bun run seed loads demo data: an organization, a team, workspaces, documents and jobs.
    • Operations. A provisioning script for a fresh VPS, GHCR images, SOPS-encrypted secrets, nightly backups with an off-box copy and a restore drill, and a runbook. Deploys are opt-in (set DEPLOY_ENABLED to true if you already deploy from Actions), wait for CI to pass, keep no deploy key or token on the server, and can be recovered after an interrupted rollout. Requests get structured logs and OpenTelemetry traces.
    • Public demo mode. PUBLIC_DEMO_MODE adds a demo banner and a noindex tag, and infra/demo runs a demo next to production on the same host. Uploads, search, starting or retrying jobs and billing actions are refused, and “Enter the demo” builds each visitor a private sample organization, so nothing one visitor does reaches the next.
    • Security. Forged requests are refused on /rpc and /api/v1, the app’s script-src has no 'unsafe-inline', request bodies are bounded at every layer, failed queries no longer log their parameters, and backups verify what they restore. An account can no longer get past plan limits by owning more organizations.
    • Billing. Entitlement ends three days past the period end, or after the dunning window once a payment is past due; a daily job reconciles subscriptions with Stripe; a downgrade below current usage is refused; webhook deliveries are deduplicated; the pricing page’s plan reaches checkout.
  4. v0.3.0

    Billing, admin and the frontend platform

    The parts that turn a scaffold into a product.

    • Billing. Stripe through the Better Auth plugin, with the organization as the customer. A browser-safe plan catalog renders the pricing page, the in-app billing page and drives the API’s limits. Checkout, customer portal, cancel and restore; per-seat plans follow the member count; trials, dunning emails and a payment-failed banner. Everything stays dormant until Stripe keys are set.
    • Admin. Platform administrators (a role on the user, independent of organization roles) get user search, ban and unban, role changes, session revocation and one-hour impersonation; a tenant list with members, workspaces and subscription state; feature flags with a global default and per-organization overrides; and a system page with version, uptime, counts, database and migration state, and service health. The first admin is created from the command line.
    • Component kit. shadcn-svelte components generated into the shared UI package, alongside the hand-written primitives. Design tokens as light-dark() pairs, so every surface follows the operating system without JavaScript; the app adds a Light/Dark/System toggle.
    • Forms and data. sveltekit-superforms in SPA mode with Zod 4, validating the contract’s own schemas; TanStack Query with keys, fetchers and types derived from the contract.
    • App shell. Skip link, responsive sidebar, command palette (Ctrl/⌘K), toasts, dialog confirmations, skeletons and empty states, error boundaries with a reference id, and an “Install app” button when the browser offers it.
    • PWA. A service worker that precaches the build and serves a prerendered offline page, registered in production browsers only.
    • Deployment switches. Sentry error tracking and PostHog analytics, both off until a key is set; PostHog loads only after the visitor accepts a consent banner.
    • Accessibility. axe (WCAG 2.2 AA) runs on the public pages in the end-to-end suite; the authenticated pages passed the same checks in both color modes.
  5. v0.2.0

    Authentication, organizations, teams and workspaces

    Accounts and tenancy, end to end.

    • Email flows. Sign-up with email verification, password reset, change email confirmed from the old address, and account deletion confirmed by email. Emails print to the API console in development and go through Resend when a key is set.
    • Social sign-in. GitHub and Google switch on when their credentials are present. The sign-in page asks the API which providers are live instead of keeping a second configuration.
    • Two-factor and passkeys. TOTP with backup codes, and WebAuthn passkeys, managed from the security settings. Sessions can be listed and revoked.
    • Rate limits. Better Auth’s own per-IP limits on the auth routes, plus a limiter on every procedure.
    • Session guard. One universal load protects the app routes in server rendering and in the static SPA, so the same code redirects to sign-in on every target.
    • Organizations. Create and switch organizations; members with owner, admin and member roles; email invitations that expire after seven days; teams that group members.
    • Workspaces. The product container, scoped to an organization and optionally to a team, with unique slugs per organization and a reserved list for the app’s own routes.
    • Access control. Roles and permissions are defined once and used by the auth server, the auth client (to hide what a role cannot do) and the API router (every workspace procedure refuses non-members).
    • Plan limits and audit log. Workspace and seat limits enforced server-side and reported to the UI; an audit log records who did what per organization.
  6. v0.1.0

    Foundation

    The scaffold: one Bun workspace, one HTTP API, every surface a thin client of it.

    • Workspace and toolchain. Bun as runtime, package manager and test runner; Turborepo for build, check and test; Biome as the only linter and formatter; shared versions pinned once in the root catalog. Internal packages are consumed from source, with no build step.
    • Shared packages. The oRPC + Zod API contract, the typed client, the Better Auth server instance and Svelte client, the Drizzle schema with the generated auth tables and the first migration, plan catalog, email provider abstraction, validated environment, and the shared UI package with the Tailwind tokens.
    • API. Hono on Bun with Better Auth mounted at /api/auth/*, the oRPC router exposed as POST /rpc/* and as plain REST under /api/v1/*, and an OpenAPI 3.1 document at /api/v1/openapi.json.
    • Application. SvelteKit 2 with Svelte 5, building for Node, Cloudflare Workers or as a static SPA from one ADAPTER variable; SSR and SPA share every route.
    • Public sites. This Astro site and the Starlight documentation, both fully static.
    • Native shell. A Tauri 2 project that wraps the static build with no IPC data layer. The shell talks to the API over HTTPS exactly like the browser.
    • Compute service. An internal FastAPI service managed with uv, reachable only from the API with a service token.
    • Infrastructure. Docker Compose for the whole stack (Postgres, API, web, AI service, Caddy), a Caddy configuration for public subdomains or a single origin, and a development compose file for Postgres.