What ox backs up, what it does not, and how to leave
Where your backups live, what is not backed up, how much data you can lose, what pauses when ox is down, and how to leave ox with your data.
Last updated 2026-10-11
On this page
Your apps, their data and their backups live on your own server, and ox's plane only sends it jobs. This page says what ox backs up and what it does not, where each copy lives, how much data a bad day can cost, what pauses while ox is down, and how to leave with your data.
Who runs what
- You own the server. You rent it, you are root on it, and anyone with an SSH key for its operator account is root too.
- ox's plane (deploywithox.com) holds your account, servers, projects and run records, and decides when to deploy, back up and check your sites. The privacy policy lists what it keeps.
- The agent on your server runs the jobs. The plane signs each job with its own key, and the agent runs only jobs signed with the one plane key it was installed with. Agent updates also need ox's release key (signed updates).
What ox backs up
Once a day, soon after 03:00 UTC, and whenever you press Back up now: PostgreSQL with pg_dump, a project's own Redis, Neo4j, Qdrant, MySQL and custom services as files, and the SQLite databases in the project's data folder (the first 20 found, in the folder and up to 3 folders below it). Before a deploy runs its migrate step, ox also backs up each PostgreSQL database that has tables. Backups and restore has the details.
What ox does not back up
- Files in a
[storage] keepfolder other than the SQLite databases above: uploads, a DuckDB file, logs. - A shared Redis or Neo4j, and a custom service with
backup = false. - Your variables, outside the plane. They live on your server, and the plane keeps a sealed copy only to put them back when you move a lost server's projects; it never gives the copy out. Save your own with
ox vars pull shop -o shop.env. - Releases and build caches, which ox builds again from your repository.
Copy what you need of these yourself. The list with its reasons is in Backups and restore.
Where the copies live
By default every backup stays on the same server as the app, under /var/lib/ox/projects/<project>/backups. If that server or its disk is lost, its backups are lost with it. Add an S3 bucket in Settings and each daily and manual backup also goes there; before migrate backups stay on the server. ox keeps no copy of your backups on its own servers: a backup you download passes through the plane to you and is not stored.
| What | How many are kept |
|---|---|
| Daily backups on the server | 7 per service, or 2 once S3 has a copy |
| Manual backups on the server | 3 per service |
| Before migrate backups on the server | 3 per service, never sent to S3 |
| Backups in your S3 bucket | 30 per service, daily and manual together |
| A deleted project's variables, and a fresh copy of each service ox backs up | In the trash on the server for 7 days; the service copies go sooner if the disk is nearly full |
One project's backups may take up to 20% of the server's disk; past that ox deletes the oldest first, but keeps the newest backup of each service.
How much data you can lose
- A bad write or a bad migration: up to a day. A restore brings back the last backup, so anything written after it is gone. Press Back up now before a risky change.
- A lost server without S3: everything, backups included.
- A lost server with S3: up to a day, from the newest copy in your bucket, plus the files and variables that no backup holds.
ox does not test your backups for you. Now and then, download one and check it opens, for example with pg_restore --list on a PostgreSQL backup.
When ox is down
Your apps keep serving: Caddy, your processes, workers and cron jobs run on your server and do not need the plane. What the plane starts pauses until it is back:
- deploys, including the ones a push to GitHub starts, and every action in the dashboard and the CLI;
- the daily backups: a backup that missed 03:00 UTC runs when the plane is back that same UTC day, and a day the plane is down to its end gets none;
- uptime checks and alert emails;
- agent updates.
ox is in beta and promises no uptime (terms, section 2).
Leave ox
If you only stop using ox, your apps keep serving as they do while ox is down, with nothing deploying or backing them up. ox cannot yet step away and leave the apps it deployed running: a server with projects cannot be forgotten, and deleting a project removes its app at once, with its backups, its SQLite files and its keep folders. Only its variables and a fresh copy of each service ox backs up stay in the trash on the server, for up to 7 days. So copy everything first:
- Download the newest backup of each service from the project's Backups tab, or with
ox backups shop download postgres backup:daily-20261007T030512Z.dump. - Save the variables:
ox vars pull shop -o shop.env. - Copy each
[storage] keepfolder off the server. As root, they are under/srv/ox/<project>/data. - Delete each project:
ox delete shop --confirm shop --wait. Its app stops and its files and backups are deleted. Its variables and a fresh copy of each service ox backs up stay in the trash on the server for 7 days, and the service copies go sooner if the disk is nearly full. - Forget the server on the Servers page, or with
ox servers forget web-1 --confirm web-1. This changes nothing on the server: its agent keeps running until you remove it, and still empties the trash once an entry is 7 days old. - Remove ox from the server with
sudo ox uninstall, then delete your account in Settings if you want.
What sudo ox uninstall deletes
Everything ox created on the server: every project left on it with its app, databases, services and files under /srv/ox, the backups and trash under /var/lib/ox, the packages ox installed, the agent and its settings. It asks first. The firewall, fail2ban and automatic updates stay, and root SSH login is turned back on. Run it only after you have copied what you need; there is no undo. The CLI reference lists it with the other server commands.