Moving between the Cloud and your own installation

Moving takes two steps: download the archive at the old place and upload it at the new one. This works from the Cloud to your own installation, back to the Cloud, or from one of your servers to another.

There is a fuller path for self-hosting: if you move from one of your installations to another and want to take everything — including the sign-in password, passkeys, tokens and integration keys — use rivo restore --with-keys from Updates, backup and restore. The “All my data” archive moves the data, not the access.

Step 1. Download the archive at the old place

1. Settings → Account and data → Build archive.
2. If you need the vault, tick “Include the vault” (see “Vault” below).
3. Wait for the notification and click “Download”. The archive is kept for 24 hours and can be downloaded once.

Do not unpack or repack the archive: the new instance only accepts the original ZIP from Rivo.

Step 2. Prepare the new place

• Cloud — sign up at me.rivo.day, sign in at your new address.
• Your own installation — install Rivo as described in Installing on your own server and complete the first sign-in.

It is best to move to a clean instance: sections from the archive replace whatever they already contain. A newer Rivo reads archives of older versions, not the other way round: if the new instance says “update Rivo”, update it.

Step 3. Upload the archive

1. Settings → Account and data → Transfer data from an archive → Choose an archive.
2. Rivo checks the archive and shows what is inside: sections and row counts, how many rows already exist here and will be replaced, files, settings, the vault, warnings. Nothing is written yet — you can click “Cancel”.
3. Tick “I understand: data in these sections will be replaced” and click “Transfer data”. Confirmation is required — Touch ID / Face ID or PIN.

The tables are written in a single operation: if something does not fit, nothing in them changes, and the screen tells you what got in the way. Files, the dashboard and the vault follow; if a failure happens at that step, the screen says so — the archive is kept, just click “Transfer data” again. An uploaded but unconfirmed archive is deleted after an hour; an account has one upload at a time — a new one replaces the previous.

Step 4. After the transfer

Reload the page — the data is there. Then set up what the archive deliberately does not carry:

• sign-in — the new instance has its own password, PIN and passkeys;
• integration keys — banks and exchanges, Google Calendar, the Telegram bot, the assistant (Settings);
• API tokens, the browser extension, iOS — issue them again and sign in again;
• booking — bookings get new cancel and reschedule links: links in old emails to guests stop working.

Once you have checked that everything is in place, delete the downloaded archive; the old instance can be closed — in the Cloud, delete the account.

What is transferred

Vault

• Without end-to-end encryption — tick “Include the vault” when building the archive: records go into the archive as plain text and are encrypted with the new instance’s key on arrival. Keep such an archive only on an encrypted disk and delete it right after the move.
• With end-to-end encryption — the server cannot see your passwords and cannot move them. At the old place use Vault → Export (a password-protected file), at the new one — Vault → Import.

Limits

• A self-hosted installation accepts archives up to 4 GB (change it with the ACCOUNT_IMPORT_MAX_MB variable); the Cloud — within your plan’s file storage. If your installation also sits behind your own proxy (nginx etc.), its request size limit (client_max_body_size) must let the archive through.
• A section the new instance does not have (module disabled or an older version) is not transferred — the preview warns about it.
• Only the owner can transfer data.

If something goes wrong, write to [email protected] and include the text from the screen (do not send the archive itself).