You want Vivaldi on Fedora and you’d like it to update with the rest of the system, not sit there as a one-off RPM you downloaded once. The clean way is Vivaldi’s own dnf repo. The surprise I didn’t expect: the Vivaldi package writes a second copy of that repo file the moment it installs, so most Fedora boxes end up with two. It’s harmless, but it confuses anyone who later tries to remove or disable the repo, so this guide shows both files and what each one does.
Ran this on a Fedora 45 Workstation box and a Fedora 44 Cloud VM with Vivaldi 8.2, repo method and direct RPM both; everything below is what those two machines printed.
1. Add the Vivaldi repo
dnf5 on Fedora 45 and 44 pulls a vendor repo file straight from a URL:
sudo dnf config-manager addrepo --from-repofile=https://repo.vivaldi.com/stable/vivaldi-fedora.repo
That drops /etc/yum.repos.d/vivaldi-fedora.repo, and the contents are short:
cat /etc/yum.repos.d/vivaldi-fedora.repo
The file:
[vivaldi]
name=vivaldi
enabled=1
baseurl=https://repo.vivaldi.com/archive/rpm/$basearch
gpgcheck=1
gpgkey=https://repo.vivaldi.com/archive/linux_signing_key.pub
There’s no $releasever in that baseurl, so a new Fedora release can’t break it with a 404 the way it breaks some vendor repos. The repo carries the stable channel and the development snapshot build:
dnf repoquery --repo=vivaldi --latest-limit=1 --qf "%{name} %{version}\n" 2>/dev/null
Stable and snapshot:
vivaldi-snapshot 8.3.4175.3
vivaldi-stable 8.2.4133.83
2. Install Vivaldi
With the repo in place it’s one dnf command, and I wrapped it in time to see how long the whole thing takes:
time sudo dnf install -y vivaldi-stable
On the Workstation box it was two packages and about 38 seconds. dnf fetched the Vivaldi signing key from the repo, imported it and then verified the package against it:
Updating and loading repositories:
vivaldi 100% | 7.7 KiB/s | 4.8 KiB | 00m01s
Repositories loaded.
Package Arch Version Repository Size
Installing:
vivaldi-stable x86_64 0:8.2.4133.83-1 vivaldi 453.7 MiB
Installing dependencies:
liberation-fonts-all noarch 1:2.1.5-16.fc45 fedora 0.0 B
Transaction Summary:
Installing: 2 packages
Total size of inbound packages is 136 MiB. Need to download 136 MiB.
After this operation, 454 MiB extra will be used (install 454 MiB, remove 0 B).
Warning: A pending offline transaction initiated by the following command will be invalidated: dnf5daemon-server
[1/2] liberation-fonts-all-1:2.1.5-16.f 100% | 38.9 KiB/s | 7.3 KiB | 00m00s
[2/2] vivaldi-stable-0:8.2.4133.83-1.x8 100% | 9.7 MiB/s | 136.3 MiB | 00m14s
--------------------------------------------------------------------------------
[2/2] Total 100% | 8.1 MiB/s | 136.3 MiB | 00m17s
Running transaction
[3/3] https://repo.vivaldi.com/archive/ 100% | 19.3 KiB/s | 3.1 KiB | 00m00s
--------------------------------------------------------------------------------
[3/3] Total 100% | 8.1 MiB/s | 136.3 MiB | 00m17s
Importing OpenPGP key 0x16BD9233:
UserID : "Vivaldi Package Composer KEY11 <[email protected]>"
Fingerprint: 8D1FA52AEF58A09D889DD4221256C34716BD9233
From : https://repo.vivaldi.com/archive/linux_signing_key.pub
The key was successfully imported.
[1/4] Verify package files 100% | 1.0 B/s | 2.0 B | 00m01s
[2/4] Prepare transaction 100% | 10.0 B/s | 2.0 B | 00m00s
[3/4] Installing liberation-fonts-all-1 100% | 420.0 B/s | 124.0 B | 00m00s
[4/4] Installing vivaldi-stable-0:8.2.4 100% | 39.3 MiB/s | 454.0 MiB | 00m12s
Warning: Pending offline transaction has been invalidated.
To reschedule, run: dnf5daemon-server
Complete!
real 0m37.620s
user 0m15.388s
sys 0m2.437s
No scriptlet errors either, which isn’t a given on Fedora 45 (the Chrome install prints a keyring lock error from its own script). The package is signed by that same key:
rpm -q --qf "%{name} %{RSAHEADER:pgpsig}\n" vivaldi-stable; rpmkeys --list
Signature and keyring:
vivaldi-stable RSA/SHA512, Sat 03 Oct 2026 12:34:04 AM EAT, Key ID 1256c34716bd9233
8d1fa52aef58a09d889dd4221256c34716bd9233 Vivaldi Package Composer KEY11 <[email protected]> public key
4f50a6114cd5c6976a7f1179655a4b02f577861e Fedora (45) <[email protected]> public key
3. Check what the install script added
Here’s where the second repo file comes from. The install script writes its own repo definition to /etc/yum.repos.d/vivaldi.repo. The package itself also ships a daily cron script, /etc/cron.daily/vivaldi. Check the version and both directories:
vivaldi --version; ls /etc/yum.repos.d/ /etc/cron.daily/ 2>&1
Two repo files and the cron script:
Vivaldi 8.2.4133.83 stable
/etc/cron.daily/:
vivaldi
/etc/yum.repos.d/:
google-chrome.repo
rpmfusion-nonfree-nvidia-driver.repo
rpmfusion-nonfree-steam.repo
vivaldi-fedora.repo
vivaldi.repo
The new file uses the same repo ID, vivaldi, with the architecture hard-coded instead of $basearch:
cat /etc/yum.repos.d/vivaldi.repo
The second file:
[vivaldi]
name=vivaldi
baseurl=https://repo.vivaldi.com/archive/rpm/x86_64
enabled=1
gpgcheck=1
gpgkey=https://repo.vivaldi.com/archive/linux_signing_key.pub
dnf5 didn’t complain about the duplicate ID on my box. It lists one vivaldi repo and builds the cache without a warning:
dnf makecache 2>&1 | tail -4
Build the cache:
Updating and loading repositories:
Repositories loaded.
Metadata cache created.
All three checks in one terminal:

So you can leave both files alone. If you’d rather have one, delete vivaldi-fedora.repo (the one you added) and keep vivaldi.repo, because that’s the one the package script writes.
The same script handles keys. It removes Vivaldi’s old expired key if it finds it and imports the current one only if it’s missing:
rpm -q --scripts vivaldi-stable | sed -n "228,250p"
Lines 228 to 250 of the scriptlets:
# import Vivaldi public key updates from Vivaldi repo
# Vivaldi public key updates
# Remove expired repository/package signing key (74C35BC8), if present.
remove_old_rpm_key() {
rpm -q gpg-pubkey-74c35bC8 >/dev/null 2>&1
if [ "$?" -eq "0" ]; then
rpm -e gpg-pubkey-74c35bC8 >/dev/null 2>&1
fi
}
# Install the repository/package signing key (16BD9233), if it isn't already.
install_rpm_key() {
# Check to see if the key already exists.
rpm -q gpg-pubkey-16bd9233 >/dev/null 2>&1
if [ "$?" -eq "0" ]; then
# Keys already exist
return 0
fi
# RPM on Mandriva 2009 is dumb and does not understand "rpm --import -"
Proprietary media codecs
This used to be the step that tripped people up. Vivaldi can’t ship the H.264 and AAC decoders inside its RPM, so it fetches a libffmpeg.so separately. Its %post starts /opt/vivaldi/update-ffmpeg in the background with nohup, and on both test machines the library was in place right after the install. On the Workstation:
ls -la /var/opt/vivaldi/media-codecs-* 2>&1 | head; ls ~/.local/lib/vivaldi 2>&1
The codec directory:
lrwxrwxrwx. 1 root root 48 Oct 5 12:30 /var/opt/vivaldi/media-codecs-8.2 -> /var/opt/vivaldi/media-codecs-8.3-153-S-20260918
/var/opt/vivaldi/media-codecs-8.3-153-S-20260918:
total 3524
drwxr-xr-x. 1 root root 24 Oct 5 12:30 .
drwxr-xr-x. 1 root root 94 Oct 5 12:30 ..
-rw-r--r--. 1 root root 3605712 Oct 5 12:30 libffmpeg.so
ls: cannot access '/home/kibet/.local/lib/vivaldi': No such file or directory
On a fresh Fedora 44 Cloud install the same directory was there as soon as dnf finished:
ls /var/opt/vivaldi/; pgrep -af update-ffmpeg
The listing:
media-codecs-8.2
media-codecs-8.3-153-S-20260918
If the background fetch fails (no network during the install, for example), Vivaldi’s proprietary media help page says to restart Vivaldi once. The debug command on the same page runs /opt/vivaldi/update-ffmpeg --user, which installs the library under ~/.local/lib/vivaldi. The helper sits next to the bundled library in /opt/vivaldi:
ls /opt/vivaldi/ | grep -i -E "ffmpeg|codec|update"
Both files:
libffmpeg.so
update-ffmpeg
And these are the scriptlet lines that call it, the background fetch on install and the undo on removal:
rpm -q --scripts vivaldi-stable | grep -n "update-ffmpeg"
The matches:
617: nohup /opt/vivaldi/update-ffmpeg >/dev/null 2>&1 &
1231: /opt/vivaldi/update-ffmpeg --undo ||:
4. First launch and the setup wizard
Start Vivaldi from Activities. The wizard is ten screens long, and I like that the first one leaves crash reports switched off by default:

The third screen sets Vivaldi as the default browser, pins it to the taskbar and imports from other browsers, all three ticked:

Later screens pick the tab position, theme and Web Panels. This is the panel picker:

Once the wizard was done, vivaldi://about showed the build, the Chromium base and the platform it detected:

The wizard’s default-browser box did its job, and with the about page open the browser was using about 620 MiB of proportional memory across its processes:
xdg-settings get default-web-browser; for p in $(pgrep -x vivaldi-bin); do grep ^Pss: /proc/$p/smaps_rollup; done | awk "{s+=\$2; n++} END {printf \"%d processes, PSS total: %.0f MiB\n\", n, s/1024}"
The result:
vivaldi-stable.desktop
12 processes, PSS total: 620 MiB
5. Install the downloaded RPM instead
Vivaldi’s download page hands you a single RPM, and plenty of people install it that way. I tried it on the Fedora 44 Cloud VM. Grab the latest stable file name from the repo listing so you’re not pinning a version:
RPM=$(curl -s https://repo.vivaldi.com/archive/rpm/x86_64/ | grep -o "vivaldi-stable-[0-9.]*-1\.x86_64\.rpm" | sort -uV | tail -1); echo "$RPM"
It found the same build the repo had:
vivaldi-stable-8.2.4133.83-1.x86_64.rpm
Install it with dnf. On a Cloud image that’s a big transaction because the whole desktop stack comes along. The same lookup feeds the URL:
RPM=$(curl -s https://repo.vivaldi.com/archive/rpm/x86_64/ | grep -o "vivaldi-stable-[0-9.]*-1\.x86_64\.rpm" | sort -uV | tail -1); sudo dnf install -y "https://repo.vivaldi.com/archive/rpm/x86_64/${RPM}"
The summary and the last two lines tell the story:
Transaction Summary:
Installing: 252 packages
Total size of inbound packages is 323 MiB. Need to download 187 MiB.
After this operation, 1 GiB extra will be used (install 1 GiB, remove 0 B).
dnf doesn’t check signatures on a file or URL install, and it says so:
Warning: skipped OpenPGP checks for 1 package from repository: @commandline
Complete!
The script still created vivaldi.repo, but no Vivaldi key ended up in the rpm keyring (grep found nothing and exited 1):
ls /etc/yum.repos.d/; rpmkeys --list | grep -i vivaldi; echo "exit=$?"
The repo files and the key check:
fedora-cisco-openh264.repo
fedora.repo
fedora-updates.repo
fedora-updates-testing.repo
vivaldi.repo
exit=1
One way to get the key is a dnf install from the repo. A reinstall forced it:
sudo dnf -y reinstall vivaldi-stable 2>&1 | grep -E "Importing|successfully|Complete"
The import:
Importing OpenPGP key 0x16BD9233:
The key was successfully imported.
Complete!
The other way is the package’s own daily job. Cloud and minimal images have no cron daemon, and I first assumed that meant the job never runs. It does run: when crontab is missing, the %post script writes a systemd timer instead. On a second fresh Fedora 44 Cloud install, check cron and the keyring:
rpm -q cronie; rpmkeys --list | grep -c -i vivaldi
No cronie, no Vivaldi key:
package cronie is not installed
0
The timer the script created:
systemctl list-timers vivaldi.timer
It fires once a day:
NEXT LEFT LAST PASSED UNIT ACTIVATES
Tue 2026-10-06 00:00:00 UTC 14h - - vivaldi.timer vivaldi.service
1 timers listed.
Pass --all to see loaded but inactive timers, too.
Its status:
systemctl status vivaldi.timer --no-pager
Enabled and waiting:
● vivaldi.timer - "Run vivaldi daily cronjob"
Loaded: loaded (/usr/lib/systemd/system/vivaldi.timer; enabled; preset: disabled)
Active: active (waiting) since Mon 2026-10-05 09:50:06 UTC; 6s ago
Invocation: 73d3e7717c7b4023995bfba79b398059
Trigger: Tue 2026-10-06 00:00:00 UTC; 14h left
Triggers: ● vivaldi.service
Oct 05 09:50:06 homelab-f44 systemd[1]: Started vivaldi.timer - "Run vivaldi daily cronjob".
The service runs the same cron script:
systemctl cat vivaldi.service --no-pager
The unit, plus a Fedora drop-in:
# /usr/lib/systemd/system/vivaldi.service
[Unit]
Description="Run vivaldi daily cronjob"
[Service]
Type=oneshot
ExecStart=/etc/cron.daily/vivaldi
# /usr/lib/systemd/system/service.d/10-timeout-abort.conf
# This file is part of the systemd package.
# See https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer.
#
# To facilitate debugging when a service fails to stop cleanly,
# TimeoutStopFailureMode=abort is set to "crash" services that fail to stop in
# the time allotted. This will cause the service to be terminated with SIGABRT
# and a coredump to be generated.
#
# To undo this configuration change, create a mask file:
# sudo mkdir -p /etc/systemd/system/service.d
# sudo ln -sv /dev/null /etc/systemd/system/service.d/10-timeout-abort.conf
[Service]
TimeoutStopFailureMode=abort
Run it once by hand instead of waiting for midnight:
sudo systemctl start vivaldi.service; systemctl is-active vivaldi.service; rpmkeys --list | grep -i vivaldi
The service finished and the keyring now held two Vivaldi keys, KEY11 and the newer KEY12:
inactive
8d1fa52aef58a09d889dd4221256c34716bd9233 Vivaldi Package Composer KEY11 <[email protected]> public key
7c7cb2d56f7d2a950bccab4ebce0de545220e3e9 Vivaldi Package Composer KEY12 <[email protected]> public key
So after a file or URL install the key arrives on the first timer or cron run, or on the first dnf install from the repo, whichever comes first. The timer and the script lines that create it:
rpm -q --scripts vivaldi-stable | grep -n -E "update-ffmpeg|vivaldi.timer|crontab" | head
The matches:
617: nohup /opt/vivaldi/update-ffmpeg >/dev/null 2>&1 &
621:if ! available crontab && available systemctl && [ -d /usr/lib/systemd/system -a -w /usr/lib/systemd/system ]; then
624: <<EOF-timer tee /usr/lib/systemd/system/vivaldi.timer >/dev/null 2>&1 || WRITE_TIMER_TEST=FAIL
647: rm -f /usr/lib/systemd/system/vivaldi.timer \
650: # Not using "systemctl --now enable vivaldi.timer" as it requires version 220+
651: systemctl enable vivaldi.timer >/dev/null 2>&1 && systemctl start vivaldi.timer >/dev/null 2>&1 ||\
652: rm -f /usr/lib/systemd/system/vivaldi.timer \
1231: /opt/vivaldi/update-ffmpeg --undo ||:
1234: if [ -e "/usr/lib/systemd/system/vivaldi.timer" ]; then
1235: systemctl disable vivaldi.timer >/dev/null 2>&1 ||:
dnf updates work either way, because the repo file is already in place. If you want plain rpm -i instead of dnf, import the key first; the Fedora 45 NOKEY guide explains why rpm refuses unknown keys now.
6. The Flatpak, if you prefer it
Flathub has com.vivaldi.Vivaldi at the same version:
flatpak remote-info flathub com.vivaldi.Vivaldi 2>&1 | grep -E "ID|Version|Download|Installed|error"
The listing:
ID: com.vivaldi.Vivaldi
Version: 8.2.4133.83
Download Size: 208.1 MB
Installed Size: 489.0 MB
It’s a bigger download than the RPM and runs in the Flatpak sandbox. You’ll need Flathub turned on first, which the Flatpak and Flathub guide for Fedora walks through. For my own desktop I’d stick with the RPM.
7. Updates
Updates come with sudo dnf upgrade, same as everything else from a dnf repo. The development snapshot build lives in the same repo, and sudo dnf install vivaldi-snapshot installs it.
8. Uninstall
Removing the package is one line, but it doesn’t clean up everything it set up. It removed Vivaldi and the font package it pulled in:
sudo dnf remove -y vivaldi-stable 2>&1 | grep -E "Removing: |freed|Complete"
The summary lines:
Removing: 2 packages
After this operation, 454 MiB will be freed (install 0 B, remove 454 MiB).
Complete!
The codec directory went with it. Check the rest:
ls /etc/yum.repos.d/ /var/opt/vivaldi 2>&1; rpmkeys --list | grep -i vivaldi; du -sh ~/.config/vivaldi
Both repo files, the key and a 189 MiB profile stayed:
ls: cannot access '/var/opt/vivaldi': No such file or directory
/etc/yum.repos.d/:
google-chrome.repo
rpmfusion-nonfree-nvidia-driver.repo
rpmfusion-nonfree-steam.repo
vivaldi-fedora.repo
vivaldi.repo
8d1fa52aef58a09d889dd4221256c34716bd9233 Vivaldi Package Composer KEY11 <[email protected]> public key
189M /home/kibet/.config/vivaldi
There’s one more file. The script also writes /etc/default/vivaldi, which no package owns, so dnf leaves it behind. On the Fedora 44 machine:
cat /etc/default/vivaldi; rpm -qf /etc/default/vivaldi /etc/cron.daily/vivaldi /etc/yum.repos.d/vivaldi.repo
The file and its owner check:
repo_add_once="false"
file /etc/default/vivaldi is not owned by any package
vivaldi-stable-8.2.4133.83-1.x86_64
file /etc/yum.repos.d/vivaldi.repo is not owned by any package
Clean those up by hand if you’re done with Vivaldi:
sudo rm /etc/yum.repos.d/vivaldi.repo /etc/yum.repos.d/vivaldi-fedora.repo /etc/default/vivaldi
sudo rpmkeys --delete 8d1fa52aef58a09d889dd4221256c34716bd9233
rm -rf ~/.config/vivaldi
If the daily timer or cron job ran at least once, it also imported Vivaldi’s second key (KEY12). Remove it too if rpmkeys --list shows it:
sudo rpmkeys --delete 7c7cb2d56f7d2a950bccab4ebce0de545220e3e9
Skip the last line if you might come back; it holds your bookmarks, sessions and settings.
Troubleshooting
Two Vivaldi repo files in /etc/yum.repos.d
That’s normal after any Vivaldi install. vivaldi.repo comes from the package script and vivaldi-fedora.repo from config-manager addrepo. They share the ID vivaldi and dnf treats them as one repo.
Disabling the repo by editing the file
Vendor scripts rewrite their repo files (Chrome’s did it to enabled=1 on the same test box), so an edit to vivaldi.repo may not stick. Disable it through dnf instead, with sudo dnf config-manager setopt vivaldi.enabled=0. That writes a dnf5 override file, and on the test box an override beat the repo file.
No Vivaldi key after installing the RPM
Expected right after a file or URL install. The first run of the daily timer or cron job imports it, so does the first dnf install from the repo, or run sudo rpmkeys --import https://repo.vivaldi.com/archive/linux_signing_key.pub.
Want something else Chromium-based? There’s Brave on Fedora too. For a media player and codecs for the rest of the system, see VLC on Fedora and the RPM Fusion codecs guide, and the Fedora 45 post-install checklist covers the rest of a fresh desktop.
Dropped waivers