Instance 1 had its log collector killed 297 times and its log store 36 times for going over their memory ceilings. The ceilings sat right on top of normal use; instances 2 and 3 were within 5% of the same failure.
Ceilings raised to about twice the highest use measured on all three running instances on 2026-09-22: analytics 1536, vector 1024, kong 768, realtime 768, the small services 512 MiB. The database is unchanged.
Reserved memory is untouched at 1.875 GiB per instance. The server already has 80% of its memory reserved and production must still be able to start.
New: sudo supaspin upgrade [N] puts the current ceilings on instances that already run, without deleting anything.
Fixes a rollout that could never finish: Studio binds a port on the server itself, and the default rollout started the replacement pod before stopping the old one, so the replacement never got the port.
Instance 1 had its log collector killed 297 times and its log store 36 times for going over their memory ceilings. The ceilings sat right on top of normal use; instances 2 and 3 were within 5% of the same failure.
- Ceilings raised to about twice the highest use measured on all three running instances on 2026-09-22: analytics 1536, vector 1024, kong 768, realtime 768, the small services 512 MiB. The database is unchanged.
- Reserved memory is untouched at 1.875 GiB per instance. The server already has 80% of its memory reserved and production must still be able to start.
- New: `sudo supaspin upgrade [N]` puts the current ceilings on instances that already run, without deleting anything.
- Fixes a rollout that could never finish: Studio binds a port on the server itself, and the default rollout started the replacement pod before stopping the old one, so the replacement never got the port.
113 tests pass. Version 1.1.2 -> 1.2.0.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The two logging services were being killed by the kernel in a loop on instance 1
(supa1.didgibot.com): vector 297 times, analytics 36 times, both exit code 137
(out of memory). The old ceilings sat right on top of what the services normally
use, so any backlog crossed them.
Measured across the three running instances on 2026-09-22:
- analytics 612 / 694 / 662 MiB against a 768 MiB ceiling -> 1536 MiB
- vector 287 / 290 MiB against 512 MiB -> 1024 MiB
- realtime 269 / 287 / 300 MiB against 384 MiB -> 768 MiB
- kong 260 / 269 / 265 MiB against 512 MiB -> 768 MiB
- studio 203, storage 187, rest 162 MiB against 256 MiB -> 512 MiB
- db 163 / 175 / 273 MiB against 2048 MiB -> unchanged
Limits only. The requests stay at 128 MiB (512 for db): the server is one machine
shared with the production workloads and already has 80% of its memory reserved,
so raising the requests would leave production nothing to schedule into. Raising a
limit reserves nothing - it only moves the point at which the kernel kills.
Per-instance totals go from 5.875 GiB to 9.5 GiB of limit; reserved memory is
unchanged at 1.875 GiB.
New numbers only reach instances created afterwards, so this also adds
`sudo supaspin upgrade [N]`: it reads back the values Helm stored at install
time, replaces the memory block in them and applies the chart again. Pods are
replaced service by service; databases, uploads, certificates and .env files are
untouched. Without a number it does every instance and reports which ones failed.
Also available from the menu.
Fixes a rollout that could never finish, found by the first upgrade: Studio binds
port 3001 (3002, 3003) on the server itself so it can be reached over an SSH
tunnel, and one port can be held by one pod at a time. The default rollout starts
the replacement pod before stopping the old one, so the replacement never got the
port and stayed Pending for ever. The Studio deployment now stops the old pod
first. Postgres was never affected: a StatefulSet already replaces its pod that
way.
The values file that carries the instance's secrets and the post-renderer
arguments are now built by shared helpers used by both create and upgrade.
Tests: 113 pass (12 new). Version 1.1.2 -> 1.2.0 in VERSION, the VERSION constant
and README.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
igor
merged commit 1d49234400 into main2026-09-22 18:53:47 +00:00
igor
deleted branch fix/supabase-instance-memory-limits2026-09-22 18:53:47 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Instance 1 had its log collector killed 297 times and its log store 36 times for going over their memory ceilings. The ceilings sat right on top of normal use; instances 2 and 3 were within 5% of the same failure.
sudo supaspin upgrade [N]puts the current ceilings on instances that already run, without deleting anything.113 tests pass. Version 1.1.2 -> 1.2.0.
🤖 Generated with Claude Code
supaspin upgrade1d49234400