Tale v0.5.0

0.5.0 is a breaking minor: it requires a fresh deployment. There is no upgrade path between 0.4.x and 0.5 — in either direction. If you operate a 0.4.x instance, read the breaking changes below before touching anything.

Highlights

0.5 moves Tale's application backend off Convex onto Postgres (#3107). The platform now runs as a Node service pair — backend-api and backend-worker — backed by Postgres and an object store: background jobs run on pg-boss instead of the Convex scheduler, live updates arrive over an SSE hint bus instead of WebSocket subscriptions, and the schema is owned by versioned SQL migrations that apply automatically at boot under an advisory lock. The running stack has no Convex process, image, or client runtime anywhere.

The port is domain-by-domain rather than a rewrite: 0.4 handler logic that was correct is reused against the new SQL-backed runtime, and the surface is proven by an integration suite that exercises every door against a real Postgres — uploads, automations, task agents, SSO/SCIM, governance holds and retention, and the WebDAV lane included.

List pages are aligned across the app, and automations gained a switcher in the area header (#3101).

Breaking changes

• No 0.4 → 0.5 in-place upgrade — 0.5 requires a fresh deployment. The application store itself changed: 0.5 keeps application data in Postgres where 0.4 kept it in the bundled Convex service, and no importer bridges the two. Nothing from a 0.4 instance's database is carried over: chats, automations and their run history, knowledge entries, task history, users and sign-ins. The org config tree (agents, skills, providers, governance policies) lives as files on the shared config volume and does carry forward when a host is reused; files in a BYO-S3 bucket physically remain in the bucket, but a new instance has no references to them.
• Guard rail, if you skip this: tale deploy with a 0.5 CLI refuses to touch an instance whose running version is below 0.5.0, before pulling an image or writing anything. The expert override — tale deploy --accept-data-loss — exists for deliberately reusing a host whose old volumes you have already dealt with: pre-0.5 data on that instance becomes permanently unreadable.
• Downgrading below 0.5.0 is equally unsupported. A 0.4.x release cannot read data created by 0.5+ — restore a pre-0.5 snapshot or deploy 0.4.x fresh instead.

Staying on 0.4.x

Staying on 0.4.x for a while is a supported choice: the release/0.4 branch receives security and critical fixes. Every 0.4.x CLI pins updates to its own line — a bare tale update stays within 0.4.x and only reports that a newer line exists, so nothing crosses to 0.5 on its own.

Moving to 0.5

Moving is a re-onboarding, not an upgrade — the full walk-through is in Upgrades → 0.4 → 0.5: breaking cutover.

# 1. Leave the 0.4 instance untouched (it keeps serving).

# 2. Get the 0.5 CLI (a 0.4.x CLI never crosses to 0.5 on its own):
curl -fsSL https://raw.githubusercontent.com/tale-project/tale/main/scripts/install-cli.sh | bash

# 3. Deploy fresh in a NEW project directory:
mkdir tale-05 && cd tale-05
tale init
tale deploy

# 4. Re-onboard: organizations, users (invite / SSO), configuration,
#    documents and knowledge re-upload.
# 5. Decommission the 0.4 instance once the new one is accepted.

What's Changed

• feat(platform): align list pages and add the automation switcher by @yannickmonney in #3101
• feat(platform): move the platform off Convex onto Postgres by @larryro in #3107

Full Changelog: v0.4.18...v0.5.0