What ox backs up, what it does not, and how to leave

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.

ox's plane decides when to deploy, back up and check your sites, and signs each job; the agent on your server runs only jobs that carry the plane's signature. Your apps, data and backups stay on your server, and a copy of each daily and manual backup goes to your S3 bucket only if you add one, which keeps 30 per service.

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] keep folder 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. They live only on your server; save them 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, The beta).

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. To leave for good, pick one of two ways.

Keep the apps running

Delete your account in Settings, Delete account, or with ox account delete --confirm <your GitHub login>. Nothing on your servers is stopped or deleted. Every Pro subscription of the account is cancelled first. The ox agent on each server then removes itself: its binary, its unit and its link to ox go, and everything your apps use stays (their code, units, databases, Caddy and its certificates, cron jobs). It leaves a note at /etc/ox/LEFT.txt that lists the apps and where their code, variables, backups and passwords are. A server that is offline does this when it next connects. The page lists each server, and for one that is offline or whose agent is too old to leave on its own it also gives the command to run there:

On a server whose agent did not leave, as root

sudo systemctl stop ox-agent && curl -fsSL https://deploywithox.com/install.sh | sudo sh && sudo ox leave

After that nothing manages the server: no deploys, backups, alerts or updates, Caddy included. Copy your backups somewhere safe as below, because the ones on the server are now yours to keep. To leave ox on one server while you keep the account, delete its projects and forget it, as below. Leaving one server while its apps keep running is not supported yet: sudo ox leave removes the agent there, but the console keeps listing the server.

Remove everything

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] keep folder 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. A server with projects cannot be forgotten. The ox agent then removes itself from the server, at once or when the server is next online, and leaves /etc/ox/LEFT.txt. For a server that is offline or whose agent is too old to leave on its own, the answer also gives the command to run there. Caddy and the databases ox installed keep running.
Remove the rest of ox from the server with curl -fsSL https://deploywithox.com/install.sh | sudo sh && sudo ox uninstall (the agent took the ox binary with it), 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.