Security: how ox hardens your VPS and isolates apps

When you add a server, ox locks it down before it joins your account. Each app then runs as its own user in a sandbox, and the server takes only updates signed with ox's release key. This page lists what ox sets, how to check it yourself, and what stays your job.

What ox sets on your server

• SSH takes keys only. Root login and passwords are off, even when the cloud image turns passwords on, and weak MACs are off. Before it changes anything, ox checks that an SSH key from outside the server can still log in. If none can, it stops and says how to add yours. It also logs in again through the new settings before it keeps them, so a broken SSH setting cannot lock you out.
• The users ox makes for your projects, its toolchains and its model downloads can never log in over SSH, even with a key in their home folder, so an app cannot open an SSH tunnel out of its sandbox. Your own login is not touched.
• The ufw firewall refuses incoming connections and opens SSH, 80 and 443. Rules you had in ufw before ox, such as a port you opened yourself, stay open.
• fail2ban bans addresses that keep guessing at SSH. The first ban lasts an hour, the next 4 hours, and each one after that a day. Trying a wrong key before the right one does not count. The firewall writes nothing to the log for the packets it blocks.
• Ubuntu's security updates install themselves every day, and the audit checks that they ran. A kernel or library fix loads only after a restart. The server's page then says "Restart needed since" with what was updated, and you restart it with the Restart now button or ox servers restart. ox never restarts your server on its own and does not offer Livepatch.
• io_uring is off for every process. This part of the kernel has a long record of privilege bugs, and no app ox runs needs it.
• Your server writes a line to its own journal each time ox reads a variable's value, saves variables, deploys, backs up, runs a command, opens a backup, restores, or uses Explore. A deploy line names the repository and ref it was asked to build, and a backup line names the bucket. A line names the project and the keys, never a value, a query or a command. Read them with journalctl -u ox-agent -g 'security:'. The server also refuses more than 30 value reads a minute, and writes a line for each refusal.
• Every site sends nosniff and a referrer policy, and HSTS once it has a domain, unless your app sets its own. Only the same site may frame its static files. There is no default Content-Security-Policy, because a wrong one breaks the app.

How your apps are kept apart

Each project runs as its own system user, in a systemd unit with no extra privileges. An app cannot see other users' processes, load kernel modules or trace other processes. It can write only its own directories. Only its own project and Caddy can reach its ports. It cannot read the cloud's metadata service, where a droplet keeps its setup data. Your variables and secrets sit in files only root and that project can read.

A process set to sandbox = "relaxed" in ox.toml can write wherever its user may. It keeps everything else: its own user, no extra privileges, hidden processes, the kernel limits, and a filter that refuses rarely used calls (swap, reboot, kernel modules, raw I/O, CPU emulation, old calls, bpf and perf).

Builds run as the same user, with the same limits on processes, the kernel and those calls. Each build step gets its own temporary folder that no other project can see. No unit or build step can write a core file, which would hold your secrets. One project cannot use up the server's processes and threads either: a project's units together stop at 40% of the host's limit, and all previews together at 20%. A project gets this limit at its next deploy.

Signed updates

ox updates the agent on your server between jobs. A new build first runs on ox's own servers for a day without trouble. If an updated agent does not answer ox within two minutes, the server goes back to the old build.

The agent installs only a build that carries two signatures: one from ox Cloud and one from ox's release key. The ox team keeps that key on its own machine, with one backup in a password manager, and never on ox Cloud or a server. So someone who took over ox Cloud could not put a program of their own on a server you already added. They could still run jobs on your server as your projects' users and read your projects' variables, as ox does to deploy. A server added while they held ox Cloud would run whatever install script they served.

The agent talks to ox only over HTTPS, and only outward: ox never connects in. It refuses any request ox did not sign, and any old or repeated one. It answers only ox's fixed list of requests. The one that runs a command you type, ox exec, runs as your app's own user in its sandbox, never as root. Only your account, with full access, can start one, and each one is in your audit log.

Check your server yourself

Before a server enrolls, ox reads back what it set and refuses to go on if any row fails. Run the same check on an enrolled server at any time; it changes nothing:

sudo ox install --audit

It prints a pass or fail row for each setting: SSH root, password and key login, the firewall, fail2ban, automatic updates, the kernel's network and crash settings (redirects, source routes, multipath TCP off, setuid core dumps, Ubuntu's crash reporter off), the modes of ox's own folders and secret files, and that SSH turns ox's own users away. Two rows look for signs that something broke out of an app: an SSH key or a startup unit in a project's home folder, and a library forced into every program (/etc/ld.so.preload). ox reports these and deletes nothing: look at the file the row names, remove it if you did not put it there, then press Recheck. An up-to-date server also runs the audit every day, and its page shows any row that drifted, with the fix. The agent applies its kernel settings each time it starts, so a restart cannot undo them. If a kernel or hardening row stays failed on an older server, press Update on its page, then Recheck. When no update is offered, restarting the server does the same, but its projects are down for about a minute. The same goes for the row that keeps ox's own users out of SSH. Update does not change your SSH login settings. A failed row about root, passwords or keys means the SSH settings on the server changed since ox set them: set them back, then press Recheck.

sudo ox install --harden applies the settings by hand. It turns io_uring off, lets Redis fork for its snapshots (memory overcommit), writes the rules that keep apps apart and away from the cloud's metadata services, sets the kernel's network settings, keeps ox's own users out of SSH, writes the fail2ban settings, turns the firewall's logging off, and runs the audit. It leaves your SSH login settings, the firewall's rules and updates as they are.

Where your data lives

ox keeps only what it needs to run your account. Your app and its data stay on your server. These stay there:

• Your code, builds and releases.
• Your variables and secrets. ox shows them to you but keeps no copy.
• Your databases, files and uploads.
• Backups of your services. A copy goes to your own S3 bucket only if you add one.
• Your app's logs. ox reads them only when you ask to see them.

Logs you open, rows you browse in Explore, and backups you download pass through ox to your screen. ox does not save them. With tested deploys on, ox also sends a pull request's text and changes, and the text of its preview's pages, to DigitalOcean's AI inference, and keeps the checks it writes and each run's results. The questions below list what ox keeps and for how long, and the privacy policy has every detail.

What stays your job

• Your app's own code and dependencies. The sandbox limits what a bad dependency can reach, but it can still read that project's own data.
• Who holds an SSH key. Anyone with a key for the operator account is root on the server.
• The Add server command. Treat it like a password until the server shows up. It expires on its own.
• Backups somewhere else. Keep copies in your own S3 bucket, as Backups and restore explains. Also copy what no backup holds, which What ox backs up lists.

If something here looks wrong, or you found a hole, write to the address on the privacy page. If a deploy fails after a hardening change, start with Troubleshooting, and see the CLI reference for the rest of ox.

Questions people ask