$ the-wire · showcase
Self-hosted stack bumps realtime and storage, Studio remembers your chart range
By RepoJournal · Filed · About Supabase · Composed from the cited sources · methodology
The day's substance is packaging: slim-services published smoke-tested artifacts for storage v1.83.4-r0 and realtime v2.144.4-r0, while the self-hosted compose file moved its pinned components forward.
chore(self-hosted): update 2026-10-16 - 0.8.3 supabase/supabase
The self-hosted compose file now pins supabase/studio:2026.10.12-sha-3699278, supabase/gotrue:v2.197.0, postgrest/postgrest:v14.18, supabase/realtime:v2.143.3 and supabase/storage-api:v1.81.0, each replacing an older tag. Note the gap: realtime jumps from v2.134.10 to v2.143.3 here, though slim-services has already packaged v2.144.4.
storage v1.83.4-r0 supabase/slim-services
by github-actions[bot]
storage v1.83.4-r0 is published as portable, smoke-tested artifacts for linux/amd64, linux/arm64 and darwin/arm64, plus a multi-platform image at ghcr.io/supabase/cli/storage:v1.83.4-r0 with a digest-pinned reference. Archives carry an attached SHA256 checksum for verification.
realtime v2.144.4-r0 supabase/slim-services
by github-actions[bot]
realtime v2.144.4-r0 shipped on the same packaging commit with the same three targets, published as ghcr.io/supabase/cli/realtime:v2.144.4-r0. It lands ahead of the v2.143.3 pin now in the self-hosted compose file.
fix(studio): preserve restore times across date edits FE-4129 supabase/supabase
The restore-point picker now stores the timestamp as a Unix value and carries the entered hours, minutes and seconds across calendar edits, so changing the date no longer wipes the time or misresolves the repeated hour at the end of daylight saving.
feat(studio): remember project home chart interval per project supabase/supabase
The request-chart time range on the project home page persists in localStorage keyed as home-chart-interval-${ref}, so a chosen interval survives the next visit. Small, but it kills a repeated re-selection on every page load.
docs: correct Node adapter dependency note in README (#458) supabase/mcp
Elsewhere: the MCP README dropped its claim that @modelcontextprotocol/node is not a dependency, since the adapter has been in @supabase/mcp-server-supabase since the --http entry landed and the 0.13.0 manifest lists it.