Storage
Keep a server's files across restarts and redeploys with a persistent data volume
Introduction
Servers that Gatana deploys for you (Executable Apps and Runnable Code) start from a fresh filesystem every time they deploy. Whatever the server writes to disk is gone after a restart, a redeploy, or the automatic stop of an idle server.
With persistent storage the server keeps one data volume, mounted at /data. Files under that path survive restarts, redeploys, and idle stops. Use it for state worth keeping between restarts: a SQLite database, a cache that is expensive to rebuild, or files an agent accumulates over time.
Remote HTTP and OpenAPI servers run outside Gatana, so this setting does not exist for them.
Turning It On
Check Attach Persistent Storage when creating the server, or enable it later under Storage in the server's Settings tab. The server restarts to mount the volume.
The mount path is also in the environment variable GATANA_DATA_DIR, so your code can read the variable instead of hardcoding /data.
Every volume has the same fixed size, set by the platform. The server's Deployment tab shows the size and how much of it is used, and the deployment metrics chart includes the usage over time.
If the option is not offered, persistent storage is not available in your environment. In the Gatana cloud service it is part of the paid plans. A self-hosted installation offers it only when it is configured with a Kubernetes storage class for the volumes.
The Organization Quota
An organization can claim a fixed total of storage across all its servers: 20 Gi, unless a different quota was agreed for the organization. The quota counts the size the volumes claim, not the bytes written to them. Turning storage on for a server is refused when it would push the total past the quota. Contact [email protected] to raise the quota.
Lifecycle
A volume is always in one of four states, and each action moves it to the next one. Turning storage off is not the same as deleting the data: only steps 5 and 6 destroy it.
| State | Where the data is | Quota | The state ends when |
|---|---|---|---|
| Attached | On the volume, mounted at /data | Counted | You turn storage off, or you delete the server |
| Detached | Kept on the volume | Counted | You turn storage on again, or you delete the server |
| Orphaned | Kept on the volume of the deleted server | Counted | 50 days pass, or an owner deletes the volume |
| Deleted | Gone. Volumes are not backed up, so the data cannot be recovered | Freed | Never. This state is the end |
Points to know about each step:
- Turn storage off (in the server settings, or Detach on the Storage page). The server restarts without the volume. The volume and its data are kept.
- Turn it on again and the same volume is mounted, with the files as they were. If the volume was deleted in the meantime, the server gets a new, empty one.
- Delete the server and its volume becomes orphaned. The Storage page lists it until it is deleted. An orphaned volume stays with the deleted server and cannot be attached to a different one, so a new server with the same name starts with empty storage.
- Delete the volume on the Storage page and the data is destroyed immediately. When the owning server still has storage turned on, this also turns storage off for that server.
The Storage Page
Organization owners can manage all volumes under Storage in the left sidebar. The page lists every volume in the organization, including the orphaned volumes of deleted servers, shows the total claimed against the quota, and charts the usage of each volume over time. Volumes can be detached, attached again, and deleted here.
Servers connected to Tailscale also appear here with a small volume holding their machine identity. Identity volumes do not count against the quota, cannot be detached or attached, and can only be deleted once the server no longer uses them.
Redeploy Behavior
A volume can be attached to only one running instance at a time. A server with storage therefore stops its old instance before the new one starts when it redeploys, instead of overlapping the two, so a redeploy pauses the server for a moment.