public/supaspin
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

fix: give each instance's Postgres a 12 GB disk image and a 4 GB memory limit

Browse Source 
- db disk image 6144 -> 12288 MiB (VOLUMES["db"]): instance 4 had reached
  4.7 GB of its 6 GB and instances kept being recreated when the image filled.
- db memory request/limit 512/2048 -> 1024/4096 MiB (MEMORY["db"]); the
  per-instance totals become 2.375 GiB requested and 11 GiB limit.
- README (disk and memory rows, totals) and the unit tests follow the new
  numbers; release 1.6.5.

Only instances created afterwards get the bigger disk image: existing ones
have to be deleted and created again.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Igor K.
2026-11-03 13:45:30 -05:00
co-authored by Claude Opus 5.5
parent e2afacb5fc
commit 711ae36c72
4 changed files with 21 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+5 -5
View File
@@ -1,6 +1,6 @@
# supaspin
Version 1.6.4
Version 1.6.5
Create, list, show and delete throwaway [Supabase](https://supabase.com) instances on a
single-node [microk8s](https://microk8s.io) server, from a terminal menu.
@@ -16,8 +16,8 @@ endangering them. Nothing in it is specific to any one app.
| Web API | `https://<slot hostname>` (auth, rest, graphql, realtime, storage, functions); the certificate is from Let's Encrypt when that is enabled, otherwise self-signed |
| Postgres | `<LAN IP>:544N` (instance 1 → 5441, 2 → 5442, …); which addresses listen is set by **Port bind** |
| Studio (admin UI) | `http://<LAN IP>:300N` (3001, 3002, …), not on the public hostname |
| Disk | fixed-size ext4 image files, mounted at boot: **db 6 GB, storage 1 GB, every other volume 256 MB** |
| Memory | limits add up to **9 GiB** per instance, requests to 1.875 GiB (table below) |
| Disk | fixed-size ext4 image files, mounted at boot: **db 12 GB, storage 1 GB, every other volume 256 MB** |
| Memory | limits add up to **11 GiB** per instance, requests to 2.375 GiB (table below) |
| Priority | pods run at priority -100 (`supaspin-low`); when the server runs short of memory they are evicted first and never evict anyone else |
| Secrets | generated fresh per instance: JWT secret, anon and service keys, Postgres password, Studio password, and the internal keys |
| Uploads | stored in the instance's own storage image (no MinIO); deleted with the instance |
@@ -270,13 +270,13 @@ stores the new memory limits and leaves it asleep; they take effect when you res
| Service | Request | Limit | Highest use measured |
|---|---|---|---|
| db | 512 MiB | 2048 MiB | 273 MiB |
| db | 1024 MiB | 4096 MiB | 273 MiB |
| analytics | 128 MiB | 1536 MiB | 694 MiB |
| vector | 128 MiB | 512 MiB | 290 MiB |
| kong | 128 MiB | 768 MiB | 269 MiB |
| realtime | 128 MiB | 768 MiB | 300 MiB |
| auth, functions, imgproxy, meta, rest, storage, studio | 128 MiB each | 512 MiB each | 203 MiB (studio) |
| **Total** | **1.875 GiB** | **9 GiB** | |
| **Total** | **2.375 GiB** | **11 GiB** | |
The request is what the scheduler sets aside for a service and can never be given to anything else.
The limit is the ceiling the kernel kills the container at. They do different jobs here.