What "persistent" actually means here
There is no save button because there is nothing to save. Your container is never deleted, only started or stopped. The filesystem you sit in today is the exact same one you will sit in next month.
That is what makes this a place to actually host
something rather than just visit it: a bot watching a webhook, a scheduled
job, a background worker, an SSH tunnel you would otherwise have to
re-establish every session. Start it in a tmux window and it
keeps running, whether or not your browser is open, whether or not your
laptop is even on.
Real limits, honestly stated
| Limit | Why it is there |
|---|---|
| 2 GiB RAM (2.5 GiB with swap headroom) | Sized to what the heaviest tool on this box actually needs to run without being killed mid-task, measured, not guessed. |
| 2 CPU | The real anti-abuse control; CPU-bound misuse is throttled here, not by the memory limit. |
| 2 GB disk | Enforced at the kernel level where the host storage driver supports it. |
| 4096 process slots | Enough for real parallel work, not enough for a fork bomb to matter. |
sudo gets you real root inside your own container. It does
not get you off it: no mounting tricks, no kernel module loading, no
reaching outside your own container, no Docker socket, no port ever
published to the outside world. Outbound internet is unrestricted; nothing
inbound reaches you unless you are the one who started this session
; see Exposing a port if you want to
deliberately put one of your own services on the public internet.
Platform updates reach your shell, not your uptime
Shared, non-secret configuration the platform pushes out lands in your
shell the moment a new interactive shell opens, no restart, no
reprovisioning, no interruption to whatever is already running in your
tmux session. The same discipline applies to the platform
itself: routine deploys to the browser-facing app are built to leave an
already-open terminal connected exactly as it was, not to force a
reconnect the way a naive redeploy would.