Skip to main content

Updating

Updating StreamVault Engine is one command on the server. This page explains what that command does, what it guarantees, and what happens when your right to updates expires.

Why there is no button in the panel​

The panel shows you which version you have, which is the latest published, the notes for each one and the exact command to run. What it does not do is run it.

For a button in the panel to be able to recreate the services, that panel would need Docker access. The panel is exposed to the internet: a remote execution flaw there would become total control of your server. The update is done by sve, which lives outside the containers, and that is why it asks for a session on the machine.

It is one more manual step. It is deliberate, and it is the reason a flaw in the panel stays inside the panel.

The command​

sudo sve update

On its own, it installs the latest version your provider has published for you. To go to a specific one:

sudo sve update --to 1.12.1

Before that it is worth seeing where you stand:

sudo sve status

It shows the installed version, the licence state and, if something newer is published, a line reading disponible: X.Y.Z → sve update.

What it guarantees​

The rule governing the whole operation: an update that goes wrong must not leave the installation worse than it was. Hence the order of the steps, and hence the backup being mandatory rather than an option you can skip with a flag.

The steps, in order:

  1. Checks your right to update before downloading anything. If your licence does not allow it, it stops here and you have not spent several gigabytes and half an hour on something that was going to bounce.
  2. Backs up the whole database, compressed, into <your-data>/backups/. If the backup fails, or comes out suspiciously small, it does not continue: an empty backup is not a backup, it is an error that came out on standard output.
  3. Records the version it is leaving, before downloading anything. If the process dies halfway — the session drops, the power goes — sve rollback still knows where to go back to.
  4. Downloads the new version's images. If the download fails, it leaves the previous version in place and nothing has changed.
  5. Replaces the services.
  6. Waits for everything to become healthy, up to five minutes. Five and not fewer, because a cold start of an installation with many channels includes migrations, reconciliation and the staggered start of the broadcast processes; being impatient would turn a slow start into an unnecessary rollback, which is worse than waiting.
  7. If anything is unhealthy, it goes back to the previous version on its own and waits for that one to become healthy. You do not have to be there to fix it: that is what separates an update from a gamble.

When it finishes successfully, it says where the backup was left. Keep it.

What the rollback does not do​

It does not restore the database. This is deliberate and worth understanding before you need it.

This product's migrations only move forward: they never delete or transform destructively, only add. An already-migrated schema works with the new version and almost always with the previous one too. Restoring the database outright would throw away everything your customers and channels have done in the meantime — sign-ups, payments, changes — to fix a problem that is almost never in the data.

So the backup is made, you are told where it is, and if data does need recovering as well, a person decides that, with sve restore.

Going back by hand​

If the new version started up healthy but you do not like what you see:

sudo sve rollback

It returns to the version recorded by the last sve update. It also makes a backup before touching anything, and it also waits for everything to become healthy.

If there is no previous version recorded, it tells you and does nothing.

Recovering data from a backup​

This is the most destructive operation in the tool: it replaces the current database with the contents of a backup, and everything that has changed since then is lost.

sudo sve restore /opt/streamvault/data/backups/20260905-0833-pre-update-1.12.0.sql.gz

It asks you to type the whole word RESTAURAR, not one letter: an extra keystroke on a tired terminal must not cost you the day's work. Before replacing anything it backs up what is there now, so that undoing the undo also exists.

It stops the services that write while it restores. Restoring underneath a live API leaves half-written rows from two different versions.

sve status does not list the backups. They are in <your-data>/backups/:

ls -lh /opt/streamvault/data/backups/

What happens when the right to updates expires​

Your licence carries two different dates, and the difference is the whole promise of the product:

  • How long the licence is valid. That is what keeps the engine broadcasting.
  • How long you may install new versions (updates_until).

A perpetual licence with one year of updates is a normal product, and "perpetual" has to mean it keeps working.

The rule​

An expired right to updates never prevents starting or broadcasting. All it does is degrade.

What keeps working, exactly as it did yesterday:

  • The broadcast, every channel, every viewer.
  • The full panel, with all its features.
  • The version you have installed, indefinitely, for as long as your licence is valid.

What you can no longer do:

  • Install a new version. sve update refuses before touching anything, so it does not leave the installation half done:

    error: el derecho a actualizaciones vencio el 2026-08-31; la instalacion sigue
    funcionando, pero para instalar una version nueva hay que renovarlo

  • Receive security fixes published after that date. This is the thing to genuinely weigh when deciding whether to renew, and it is said in those words because dressing it up would be worse.

The panel shows it too, with the date it was valid until.

Why start-up is not blocked​

It would be easy to treat that date as a second expiry and refuse to start. Some products do, and it is a trap for the honest customer: they update because of a security notice, then discover their right expired last month, and end up with the broadcast stopped and no quick way back.

That does not happen here. If by any route you end up with a version later than your date installed, it starts and runs normally.

Other reasons sve update refuses​

MessageWhat it means
esta instalacion no tiene licencia activadaActivate it first, in the panel or with the installer.
la licencia esta en estado restringida: renuevela antes de actualizarThe licence has gone days without renewing. It still broadcasts, but read-only.
la licencia esta en estado bloqueada: renuevela antes de actualizarThe licence expired some time ago. On renewal everything comes back by itself; nothing has been deleted.
no se sabe cual es la ultima version publicada; indique una con --to X.Y.ZThis server could not ask what is published. Give the version by hand or check your outbound internet.

Licence states go in stages and with room to spare: first a grace period with everything working, then a read-only period, and only at the end does the broadcast stop. How long each stage lasts depends on your plan. Nothing is ever deleted.

Updating the tool itself​

sve updates too:

sudo sve self-update

It asks the licence server for the latest published version using the same credential it already uses to download the images — there is nothing new to store or renew — checks its checksum and replaces itself. If you already have the latest, it says so and touches nothing.

The checksum check is not decoration: a half-finished download looks like a complete one until you try to use it, and by then the broken tool would be the very one that fixes things.

For a specific version: sudo sve self-update --to 1.12.1.

If something fails​

"la copia fallo, asi que no se sigue" / "la copia salio vacia"​

Nothing has been touched. The problem is in the database, not the update:

sudo sve doctor
sudo sve logs postgres

Also check there is free space on the disk where your data lives.

"no se pudieron descargar las imagenes de la X; nada ha cambiado"​

The previous version is still in place and running. It is usually outbound internet or a licence that stopped being valid for the registry. Check sve status and try again.

"no quedo sano; volviendo a la X" followed by "se volvio a la X y esta sana"​

It worked as it should: the new version did not come up properly and your installation is back on the previous one, broadcasting. Save the full output and send it to your provider:

sudo sve logs api -n 300

Do not run the same update again without knowing what happened: it will fail the same way.

"se volvio a la X pero tampoco queda sana"​

This is the bad case, and the only one that needs immediate attention. Neither the new version nor the previous one starts properly, which almost always points at something outside the product: full disk, exhausted memory, Docker in a bad state. Start with:

sudo sve doctor
docker compose ps
df -h

The prior backup has been made and sve doctor tells you how many there are.

"ya esta la X instalada"​

Nothing to do: you already have that version.

Before an important update​

None of this is mandatory — the command already makes its backup — but for a major version jump it is worth it:

sudo sve status                 # where you are starting from and how the licence is
sudo sve doctor                 # that it is not already dragging a problem
sudo sve backup                 # a backup of your own, on top of the automatic one

And read the release notes. They are in the panel, on the update page, in Spanish and English, and they describe what you will notice as different — not what was changed inside.

Jumps across several versions​

Some jumps cannot be made in one go. When a new version can no longer be applied on top of one that is too old, your provider announces which version you can reach it directly from.

Since 1.12.2, sve update checks that floor before downloading anything and refuses, saying which version to go through first:

esta instalacion corre la 1.8.3 y desde la 1.9.0 en adelante es lo unico que puede
saltar de una vez: actualice primero a la 1.9.0 (`sve update --to 1.9.0`) y repita

It is not a formality: jumping from too far back does not produce a clean error, it leaves the database half-migrated on a machine that was broadcasting. Migrations only move forward.

With --to it is not checked: by naming a specific version you are choosing the step yourself, which is exactly what this would be asking you to do.