If you run Restreamer in Docker, the safest update starts by identifying your installed version and preserving the host directories mounted for its configuration and data. Back those up or export the database before changing images, then check the YouTube destination in Restreamer after restart and before your next broadcast.
For a current v2 installation, the documented process is to pull the current image and start the container again with the relevant settings for your installation. That is not a promise that every YouTube credential or destination setting survives every version transition or installation method, so treat verification as part of the update rather than an optional final check.
Identify your installation and version path
First establish which Restreamer release you are running and how Docker starts it. Restreamer’s update guidance distinguishes a current version 2 installation from the older v0.6.x-to-v2 migration. The latter has an intermediate upgrade requirement and different configuration paths; it is not just a routine image refresh.
In Restreamer, check the version shown in the application’s system area. Then inspect how the container is managed: it may have been launched with a Docker command, a Compose file, or a graphical Docker interface. Keep a copy of the actual command or Compose configuration, including image name and variant, published ports, environment variables, and host paths. Do not rely on memory or an old tutorial that may describe a different release.
The official Restreamer update instructions say to pull the current image and restart a version 2 installation using its usual Docker invocation. They also describe enabling update checks in System settings. An update notification can tell you that a newer image exists; it does not tell you that your own mounts and startup options are correct.
| Installation path | What to establish before proceeding | Why the distinction matters |
|---|---|---|
| Existing v2 Docker installation | Image variant, host mounts, ports, environment, and launch method | The update should use the same relevant container settings and persistent paths. |
| Legacy v0.6.x installation | Exact version and legacy database mount | The documented migration path first uses v0.6.8 and changes mount targets for v2. |
| Unknown or manually altered installation | Inspect the running container and its saved launch configuration | A generic example may omit a path or option your deployment needs. |
If you cannot determine the version or locate the startup configuration, pause before removing the container. A container can be replaced; a configuration directory that was never mounted may only exist inside it. Identify where the data lives before taking an action that discards the old container.
Locate the mounted configuration and data
For current v2 Docker installations, Restreamer documents /core/config as the configuration and state mount, and /core/data for persistent internal files. These are paths inside the container. Your installation maps them to directories on the host, such as a directory under /opt or a Docker-managed location. The specific host paths depend on how you installed it.
Review the saved -v or --mount arguments in your Docker command, your Compose volumes entries, or the volume settings in your management interface. Confirm that the host directory on the left maps to the expected container path on the right. Do not create a new empty host directory and attach it in place of the existing configuration directory: the application may start with a blank state rather than the one you meant to preserve.
The official Docker installation guidance documents the persistent mount approach. The point is practical: a container is replaceable, but the host-mounted state is what lets a new container instance find the existing configuration. If your deployment uses Docker Desktop, check its file-sharing and volume settings as well; a path visible inside one Docker environment may not refer to the host location you think it does.
Make a record of both mounts before touching the container. For example, note that one host directory maps to /core/config and another to /core/data, rather than recording only that “Restreamer has a volume”. This simple mapping prevents a common mistake during recreation: preserving the data directory but pointing the configuration mount at an unrelated path, or omitting one of the mounts entirely.
Older installations may instead have used /restreamer/db. Do not rename or redirect that path based on the v2 instructions alone. Follow the migration instructions for the exact legacy route, because the container-side path changes and v2 also introduces the /core/data mount. If you are unsure whether a directory is a bind mount, named volume, or data inside the container, verify it in Docker before proceeding.
Back up or export configuration before changing images
Make a separate copy of the host directory mounted to /core/config before updating. Consider copying /core/data too, particularly if you do not have another copy of its contents. Keep the copy outside the directory being mounted so that a container restart or mistaken cleanup cannot affect both the working data and your backup at once. An external drive is one possible destination, not a requirement; what matters is a distinct, restorable copy.
Restreamer also documents database export in the system settings’ expert mode. If that option is available in your version, export the database as an additional safeguard. The system settings manual describes the relevant settings area. An export is useful, but it is not a substitute for understanding which host directory the running container uses, particularly if you may need to recreate the container.
Before you proceed, check that the backup exists and is not empty. Keep the original directory in place during the update; do not use the backup as the live mount unless you have a reason and know how to restore it. If you have a separate process list or notes for your streams, keep those too. The aim is not to create a complicated backup system for a small installation; it is to avoid having only one copy of configuration at the moment you replace the container.
A backup reduces the consequences of an error, but it does not make every upgrade route interchangeable. The migration documentation defines particular version paths, while the source material does not establish a universal guarantee for YouTube credentials or every destination setting. You should still plan to inspect and, if needed, re-enter destination details after the update.
Pull the image that matches your installation
For a current v2 installation, pull the image you intend to run before recreating or restarting the container. Use the image name and variant from your existing setup unless you have deliberately chosen to change them. Some installations use a CUDA variant; do not silently switch variants by copying a generic command from another machine or guide.
The update page’s “current image” instruction is a starting point, not a reason to discard your current Docker settings. If you use Compose, review the image declaration and the project’s normal pull and recreation process. If you use a command line, retain the exact image identifier and options needed by your deployment. If a graphical interface manages the container, confirm that its update action will use the existing volumes and environment values rather than creating a fresh configuration.
Do not confuse an image pull with a completed update. Pulling downloads an image, but the running container may still be using the previous image until you recreate or restart it as appropriate. Conversely, do not remove a container before recording its configuration if that is the only place you have the launch options. A saved Compose file or Docker command makes the next step more controlled.
Restreamer recommends using its official Docker images in its production recommendations. Stick to documented images and the path appropriate to your version, especially if a channel has been running unattended. A quiet, planned update is preferable to experimenting with image tags during a live broadcast.
Restart with the same relevant Docker settings
Recreate or restart the container using the same relevant settings as before. In particular, keep the host mappings to /core/config and /core/data, the ports required for your access and streaming workflow, environment variables, and image variant. Use your existing Compose configuration or recorded Docker invocation as the reference. The exact command differs by installation, so avoid pasting a sample command unless you have replaced its paths and options with your own verified values.
Check the mounts as the container starts. The configuration host directory should still map to /core/config, and the data directory to /core/data. Check that the ports and any required environment values have not disappeared. If the application opens as if it were newly installed, stop and investigate before entering everything from scratch: the new container may not be seeing the old state. Do not overwrite the backup while troubleshooting.
For a v2 update, the usual invocation means the actual Docker settings used by your installation, not an imagined default. If you have changed paths over time, compare the container configuration with your notes from the previous section. This is also a good point to confirm that you have not accidentally attached the same host folder to a different container destination.
If you are managing a channel for a devotional stream, a local news loop, or another always-on service, schedule the update for a period when you can monitor it. Do not make a routine software change in the middle of a broadcast simply because an update check appeared. Keep the prior image and data available until you have confirmed that the new instance starts and the destination configuration is present.
Check migration and application state
When the new container starts, open Restreamer and check that the application loads normally. Confirm the expected configuration is present, not just that the home page responds. Look for your existing stream or process configuration, media references, and relevant system settings. A successful container start proves that the application launched; it does not by itself prove that the migration imported every part of your previous setup.
For a legacy v0.6.x installation moving to v2, follow Restreamer’s migration guide, not the short v2 update process. The documented path says to upgrade through v0.6.8 first. It changes the configuration mount from /restreamer/db to /core/config and adds a /core/data mount, with host paths adjusted to the actual deployment. The guide warns that skipping the v0.6.8 step may lose settings.
The legacy guide describes starting the intermediate version and streaming from the video source before stopping and removing that container, then starting v2 with the revised mounts so it can import the settings. It also notes that a new db.json and config.json are created in the mounted configuration directory after import, and that legacy RS_ environment values are transferred on first v2 startup and may then be removed. Treat these as migration-specific instructions, not as steps for a current v2 user. Validate the examples against your installed version and actual host paths rather than pasting them unchanged.
If the migration does not produce the expected application state, avoid repeated starts with altered mounts. Preserve the old configuration and backup, note the version and messages shown, and return to the documentation for the route you are using. The documented migration route is useful guidance, but it does not promise that every YouTube credential or setting survives every possible transition or installation method.
Rollback also needs caution. The migration documentation describes a specific downgrade caveat for Restreamer 2.4.0 and later: FFmpeg 5.1.2 is incompatible with earlier versions, and its limited older-version route warns that processes created with 2.4.0 or newer cannot be restored that way. Do not treat this as a general rollback recipe. Check the current migration page before downgrading, and do not delete the pre-update copy while you are still validating the result.
Verify the YouTube destination before going live
Once Restreamer loads, inspect the saved stream and destination settings in the application’s stream configuration area. Confirm that the intended YouTube destination is selected and that the related stream settings appear as expected. Restreamer’s stream settings manual explains the configuration area. The documentation describes settings and migration paths, but it does not guarantee that every YouTube credential or setting will persist across all upgrade routes.
If a credential is absent, masked, or rejected, do not assume that an unchanged screen means it is valid. Re-enter or refresh it through the appropriate YouTube and Restreamer workflow, then verify the destination again. Keep credentials private: do not paste a stream key into support chats, screenshots, public notes, or a Compose file you share without removing sensitive values. A stream key should be treated as a password for the broadcast destination.
Before the next scheduled broadcast, check the channel and scheduled event on YouTube as well as the settings in Restreamer. If your routine uses a particular scheduled broadcast, make sure the selected destination corresponds to the event you intend to send to. The guide to finding which scheduled YouTube broadcast is using an RTMP stream key is useful when you need to connect a key to the right event. This check is separate from confirming that Restreamer saved a destination: the two ends need to agree.
You can also review the wider encoder setup before returning to a continuous stream. The YouTube bitrate troubleshooting guide helps when a stream reports a bitrate warning, and the always-on Ubuntu FFmpeg setup guide covers a different streaming arrangement if you are comparing approaches. Restreamer’s update is not the moment to change unrelated bitrate or encoding settings unless you have isolated a separate problem.
Run a short, controlled test when practical, and watch for a confirmed live state rather than assuming that a saved configuration is a working broadcast. Check that the intended YouTube channel receives the stream and that audio and video are present. If you make changes to the destination, record what changed so you can distinguish a migration issue from a later channel or key update.
If maintaining Docker, mounts, upgrades, and destination checks is more work than you want for a channel built around a finished video, a managed file-to-live workflow can remove the need to keep your own computer switched on for that task. StreamNeo is relevant to that narrower pain: it turns an uploaded video into a YouTube live stream, rather than updating or managing a Restreamer installation.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Will my YouTube stream key definitely survive a Restreamer update?
No. The documented migration instructions describe defined version paths and settings transfer, but they do not guarantee that every YouTube credential or destination setting survives every transition or installation method. Verify the destination in Restreamer and confirm the correct YouTube event before going live.
Can I update a v0.6.x installation like a current v2 container?
Do not assume so. Restreamer’s migration guide says to upgrade through v0.6.8 before moving to v2 and describes changes to the configuration mount plus the addition of /core/data. Follow that guide for your actual host paths rather than using the short v2 update sequence.
Is pulling the image enough to finish the update?
No. Pulling retrieves the image, but the running container must be restarted or recreated using the relevant settings for your installation. Check the persistent mounts, ports, environment values, and image variant as part of that step.
Should I keep a backup after the application starts?
Yes, at least until you have checked the migrated application state and verified the YouTube destination with a test or the next monitored broadcast. Keep the backup separate from the live mounted directories so that troubleshooting does not overwrite your recovery copy.