Skip to content

v1.2.0 - Versioned database migrations and a database that guards its data

Latest

Choose a tag to compare

@spacesdrive spacesdrive released this 16 Oct 08:36
· 44 commits to main since this release

Twiligent's database is now managed with versioned migrations, and the database itself enforces who owns what and which values are valid. This release also closes two security holes and makes CI and deploys more reliable.

Added

  • Versioned database migrations in supabase/migrations/, one table or one function per file, each with a rollback in supabase/rollbacks/
  • npm run db:status, db:check and db:push to see, preview and apply migrations, and npm run db:new to start a new one

Changed

  • The database refuses values the app never writes, such as an unknown platform or post status
  • Every table keeps an updated_at time
  • Removing an account also removes its scheduled posts; tracked items stay and lose only the account
  • Lists load from indexes that match their order, and new rows get random ids that cannot be guessed

Fixed

  • Security: a signed-in member could read their stored Instagram tokens and Reddit cookies, and write rows, directly through Supabase's public API. The tables are now closed to the browser.
  • Security: a scheduled post could name another member's Instagram account, and the scheduler would publish to it. A post can now only use your own Instagram account.
  • A token refresh and an analytics refresh at the same moment no longer put an old Instagram token back.
  • Accounts are listed in the order they were added, the same on every load.
  • CI and deploys no longer fail when npm skips a platform binary during the install.
  • Dependencies with known vulnerabilities are updated, including hono in the Worker and react-router in the app and the site.

Upgrading

If you run your own Twiligent, apply the migrations before you deploy this version:

npm ci
npx supabase login
npx supabase link --project-ref <your-project-id>
npm run db:check
npm run db:push

The first migrations describe the tables as they were and are safe on an existing database, so they bring any earlier setup to the same starting point. If a check stops the push because of an old row, the error names the rule; fix that row in the Table Editor and run npm run db:push again. Building the Worker now uses Wrangler 4, which needs Node 22 or newer. The same steps are in Upgrading an existing instance.

Full list of changes: CHANGELOG.md