# 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.

Your apps, their data and their backups live on your own server. ox runs a control plane on its own servers at deploywithox.com, called the plane on this page, and the plane tells the agent on your server what to do. If ox goes down, your apps keep serving. To leave ox and keep your apps running, delete your account: nothing on your servers is stopped or deleted.

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 and you are root on it. Anyone with an SSH key for its operator account is root too.

The plane holds your account, servers, projects and run records. It decides when to deploy, back up and check your sites. The [privacy policy](https://console.t12.sorv.dev/privacy) lists what it keeps.

The agent on your server does the work. It runs only jobs that ox signed, and it installs only updates signed with ox's release key ([signed updates](https://console.t12.sorv.dev/docs/security#updates)).

## What ox backs up

ox backs up once a day, soon after 03:00 UTC, and whenever you press **Back up now**. A backup holds:

- PostgreSQL, with `pg_dump`.
- A project's own Redis, Neo4j, Qdrant, MySQL, ClickHouse, Meilisearch and custom services, as files.
- RabbitMQ's queues, without the messages in them.
- The SQLite databases in the project's data folder: the first 20 found, in the folder and up to 3 folders below it.
- Each `[storage] keep` folder.

Before a deploy runs its migrate step, ox also backs up each PostgreSQL database that has tables. [Backups and restore](https://console.t12.sorv.dev/docs/operate/backups#turn-on) has the details.

## What ox does not back up

- Files in the project's data folder outside a `[storage] keep` folder, other than the SQLite databases above.
- 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](https://console.t12.sorv.dev/docs/operate/backups#not-backed-up).

## 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 migration 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 the plane does not store it.

| 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, and it keeps the newest backup of each service.

## How much data you can lose

| What went wrong | What 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 on the same UTC day, and a day the plane is down until its end gets none;
- uptime checks and alert emails;
- agent updates.

ox is in beta and promises no uptime ([terms, The beta](https://console.t12.sorv.dev/terms#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, or remove everything.

### Keep the apps running

First, give every app on a free test address your own domain ([Domains](https://console.t12.sorv.dev/docs/operate/domains)). The test address's name lives in ox's DNS, so the app loses it when you leave.

Then delete your account in Settings, Your data, Delete account (`ox account delete` prints the link). If you signed in more than 15 minutes ago, ox asks you to sign in with GitHub again first. Nothing on your servers is stopped or deleted. Every ox 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. Everything your apps use stays: their code, units, databases, Caddy and its certificates, and cron jobs. The agent only takes the free test addresses out of Caddy's config ([Keep Caddy updated](https://console.t12.sorv.dev/docs/operate/leaving#caddy)). 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. For a server 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:

```sh
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. [Keep Caddy updated](https://console.t12.sorv.dev/docs/operate/leaving#caddy) moves it to a Caddy you can update. 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 the server, 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.

### Keep Caddy updated

Caddy answers every visitor from the internet. It runs ox's own build, `/usr/local/bin/ox-caddy`, which nothing updates once ox has left. ox's build adds two things to Caddy: a fix so that a config reload does not drop requests, and the module that renews the certificate of the free test addresses.

When ox leaves, the agent takes the test addresses and their certificate out of `/etc/caddy/ox.json`, since they stop working anyway. It checks the result with Caddy and reloads it, so your domains keep answering. If Caddy refuses the result, or you edited the file by hand, the agent keeps the old file and `sudo ox leave` ends with an error. `/etc/ox/LEFT.txt` then says so and lists what to take out of the file before you run the line below.

Then switch to the packaged Caddy, `/usr/bin/caddy`, which is already installed and which you can update. This line checks the config with it first. Only then does it point Caddy's service at it and restart Caddy once, which drops open connections for about a second. Your domains and their certificates stay as they are. `/etc/ox/LEFT.txt` on the server has the same line.

On the server, after ox has left:

```sh
sudo /usr/bin/caddy validate --config /etc/caddy/ox.json && sudo sed -i 's#/usr/local/bin/ox-caddy#/usr/bin/caddy#' /etc/systemd/system/caddy.service.d/ox.conf && sudo systemctl daemon-reload && sudo systemctl restart caddy
```

The packaged Caddy came from a `.deb` file, and ox adds no apt source for it, so `apt upgrade` does not update it yet. These commands add Caddy's own apt source and its signing key, then install `caddy` from it. It is the same package at Caddy's newest release, and it restarts Caddy once if it is newer. Your config and the switch above stay as they are. These are the stable steps from [Caddy's install page](https://caddyserver.com/docs/install#debian-ubuntu-raspbian), so check them there before you paste them.

On the server, after the switch:

```sh
sudo apt install --yes debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy
```

From then on `sudo apt update && sudo apt upgrade` updates Caddy like any other package. Ubuntu's automatic updates install only Ubuntu's own security fixes, so Caddy's updates arrive when you run `sudo apt upgrade`. `/etc/ox/LEFT.txt` points here for these steps.

### 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, then remove ox step by step:

1. Download the newest backup of each service from the project's **Backups** tab, or with `ox backups shop download postgres backup:daily-20261007T030512Z.dump`.
2. Save the variables: `ox vars pull shop -o shop.env`.
3. Copy each `[storage] keep` folder off the server. As root, they are under `/srv/ox/<project>/data`.
4. 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. The service copies go sooner if the disk is nearly full.
5. 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.
6. 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

It deletes everything ox created on the server, and asks first:

- every project left on it, with its app, databases, services and files under `/srv/ox`;
- the backups, run logs and trash under `/var/lib/ox`;
- the packages ox installed;
- the agent and its settings.

The firewall, fail2ban and automatic updates stay, and root SSH login is turned back on. There is no undo, so run it only after you have copied what you need. The [CLI reference](https://console.t12.sorv.dev/docs/cli#on-your-server) lists it with the other server commands.

Last updated 2026-10-30. The page as HTML: https://console.t12.sorv.dev/docs/operate/leaving