Back up an app you built with an AI assistant

You built your app with an AI coding assistant, and it also set up the Linux server: the code, a database, maybe Docker, a web server. You are not always sure what is where. This page says how NeverWiped finds it for you, how your assistant can do the install while you keep the keys, and the few things that are not on your server and so are not in its backups.

What the agent finds

You don’t need a list. The install looks for your sites, your apps in /opt, your databases and your Docker volumes, measures them, and shows the plan before anything is sent (install). Read it, or ask your assistant to explain each line. What it usually finds on such a server:

• The app’s folder, with its .env file. The secrets in it are backed up too, encrypted on your server before they leave (encryption).
• The database, when it runs on the server or in a container: PostgreSQL, MySQL or MariaDB, as a dump (a database).
• Docker volumes, if the app runs in containers (a VPS running Docker).
• The web server and system settings in /etc.

Left out by default: **/node_modules and **/.cache. --preset build also leaves out build caches such as **/.next/cache, which a build recreates (size and exclusions).

Let your assistant install it

The page for AI agents builds the prompt to paste. Your assistant runs the install and the checks; you step in twice:

• The API key: you create it in your dashboard and give it for the install. It can only register servers, and you can revoke it afterwards (what an agent can do).
• The recovery key: it is shown once, at the end of the install. It goes into your password manager, never into a project file or a Git repository (the recovery key). The prompt tells your assistant to hand it to you and keep it out of the chat. That is an instruction, not a lock: for a key your assistant never sees, run the install yourself and let it do the rest.

Ask for a restore the same way: the assistant restores into a separate folder, and copying over live files needs your explicit OK (restore in chat).

Check the plan before you accept it

• A database service outside your server (a hosted database or a backend service your app calls): it is not on the server, so it is not in its backups. Use that service’s own backups.
• A SQLite file. NeverWiped has no SQLite export: the file is copied like any other file, while the app runs, and a copy taken during a write may not open cleanly. Make a copy with SQLite’s own .backup command before the scheduled backup, into a folder of the plan (create /root/sqlite first): for example a cron line 30 0 * * * root sqlite3 /opt/app/data/app.db ".backup /root/sqlite/app.db" in a file of /etc/cron.d. The time of the backup is in check the schedule.
• Uploads stored elsewhere (an object storage service): not on the server, not backed up.

Bringing things back

• A file or a folder the assistant deleted: one file, a folder.
• The database after a bad migration: a database. Before your assistant runs a migration, run neverwiped backup now, or ask it to.
• The whole server: a whole server. You need an account API key and your recovery key.

Test a restore on day one, then once a month: neverwiped restore latest --target /root/test-restore --yes (test a restore).

What it does not do here

• Only what is on the server. Hosted databases, object storage and the platforms your app calls keep their own data.
• It is not version control. A backup is a copy at a time, every night or once a week depending on your plan; keep your code in a Git repository too.
• Whoever is root on the server can read its backups, your assistant included when it runs as root there (known limits).
• Linux servers only. An app on a platform without a server of your own is out of reach.

Start

On the server, as root, or let your assistant use the prompt for AI agents:

curl -fsSL https://neverwiped.com/install.sh | sh

Then follow getting started. Other servers: all use cases.

Last reviewed: 6 November 2026.