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

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.

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

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

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.

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

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

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). 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). 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:

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

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, so check them there before you paste them.

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 lists it with the other server commands.