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

feat: suspend and resume an instance without losing its data

Browse Source 
An instance you are not using had to be deleted, and deleting it destroys its
database. Now it can be put to sleep instead.

  sudo supaspin suspend N    # stops all twelve pods, keeps everything else
  sudo supaspin resume N     # starts them again with the same data

Suspending gives the server back, per instance: the 1.875 GiB it had reserved and
the 1.5-2.5 GiB it was actually using, its twelve pod slots out of the 110 a node
allows, and its two server ports (Postgres 544N, Studio 300N).

It keeps: the database and the uploads (the disk images stay mounted), the .env
file with its passwords and keys, the HTTPS certificate, which goes on renewing
itself while the instance sleeps, and the hostname, which answers "service
unavailable" until the instance is resumed. Disk space is not given back - that is
the data being kept.

How: every service takes its pod count from a `replicaCount` setting, so suspend
writes zero into all twelve and re-applies the chart, resume writes one. This goes
through the instance's stored settings rather than scaling the running pods by
hand, so it survives anything that re-applies the chart later.

`supaspin upgrade` now understands a sleeping instance: it stores the new memory
limits for it and leaves it asleep instead of waiting for pods that by design do
not exist. `supaspin list` reports each instance as running, suspended or partly
suspended, and prints no tunnel commands for a sleeping one, because nothing is
listening on its ports.

`suspend` and `resume` take one instance number and have no "all" form: stopping
every instance is not something to type by accident, and resuming them all at once
would start 36 pods in one go.

Reading the stored settings and handing them back to Helm is now shared by
upgrade, suspend and resume.

Verified on instance 2 (supa2.didgibot.com): suspended to zero pods, memory
reserved on the node fell from 25766 MiB to 23846 MiB (exactly the 1920 MiB it
had), ports 3002 and 5442 freed, then resumed to 12/12 pods with 0 restarts, its
55 tables and 11 MB of data intact and the gateway answering again.

Tests: 130 pass (17 new). Version 1.2.1 -> 1.3.0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit was merged in pull request #7.
This commit is contained in:
Igor
2026-09-22 22:13:03 +03:00
co-authored by Claude Opus 5
parent 99fdf7a0ab
commit 2e4e46c878
4 changed files with 349 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+39 -2
View File
@@ -1,6 +1,6 @@
# supaspin
Version 1.2.1
Version 1.3.0
Create, list, show and delete throwaway [Supabase](https://supabase.com) instances on a
single-node [microk8s](https://microk8s.io) server, from a terminal menu.
@@ -94,6 +94,8 @@ Supabase Helm chart (0.8.0, Postgres 17.6.1.136) once into `/var/lib/supaspin/ch
| Delete instance | asks you to type the number; removes everything (see below) |
| Copy instance values into another .env file | puts an instance's `.env` values into your app's `.env`, on this server or on another computer (see below) |
| Apply current memory caps to running instances | puts this version's memory limits on instances that already exist, replacing their pods one service at a time; databases, uploads and `.env` files are not touched |
| Suspend instance | stops every pod of one instance and keeps everything else: its memory, processor time, pod slots and two server ports go back to the server, its disks and `.env` file stay |
| Resume instance | starts a suspended instance again, with the data it had |
| Mail settings | view and change the saved default mail settings |
| Settings | change any first-run setting |
@@ -108,9 +110,11 @@ sudo supaspin tunnel N # the tunnel commands, step by step
sudo supaspin push-env N TARGET [--port P] [--key FILE] [--dry-run] # see "Copying an instance's values"
sudo supaspin delete N [--yes]
sudo supaspin upgrade [N] # apply this version's memory caps to running instances
sudo supaspin suspend N # stop an instance, keep its data (see "Suspending an instance")
sudo supaspin resume N # start it again
sudo supaspin mail # change the saved default mail settings
sudo supaspin setup # change settings
supaspin --version # prints "supaspin 1.2.1"
supaspin --version # prints "supaspin 1.3.0"
```
### Connecting your app
@@ -209,6 +213,39 @@ Creating that instance again restores the saved certificate, so repeated create/
not hit Let's Encrypt's limit of 5 certificates per hostname per week. If a create fails midway,
run `supaspin delete N` to clean up.
## Suspending an instance
An instance you are not using right now does not have to be deleted. `sudo supaspin suspend N`
stops all twelve of its pods and leaves everything else alone; `sudo supaspin resume N` starts
them again with the data they had.
```bash
sudo supaspin suspend 2 # about half a minute
sudo supaspin resume 2 # a minute or two: the database answers first, the rest wait for it
```
What the server gets back while an instance sleeps:
- the memory it had reserved (1.875 GiB) and everything it was actually using (1.5 to 2.5 GiB),
- its twelve pod slots, out of the 110 a node allows,
- its two ports on the server: Postgres on 544N and Studio on 300N are free for something else.
What is kept, untouched:
- the database and the uploaded files - the disk images stay mounted and keep their contents,
- the `.env` file with its passwords and keys, so your app needs no change when the instance is back,
- the HTTPS certificate, which goes on renewing itself while the instance sleeps,
- the hostname and every Kubernetes object. Until you resume it, the hostname answers "service
unavailable" instead of not answering at all.
Disk space is **not** given back: that is the data you are keeping. `sudo supaspin list` shows the
state of every instance, and a suspended one is listed as `suspended` with no tunnel commands,
because nothing is listening on its ports.
Suspending is written into the instance's stored settings, not done by hand to the running pods,
so it survives anything that re-applies the chart. `sudo supaspin upgrade` on a suspended instance
stores the new memory limits and leaves it asleep; they take effect when you resume it.
## Memory per instance
| Service | Request | Limit | Highest use measured |