Aurora Player Version Pinning

Pinning the Aurora player to a specific version

By default, the embed code Wistia gives you loads the Aurora player without a version. That reference always serves the latest released version of the player:

<script src="https://fast.wistia.com/player.js" async></script>

This is the recommended setup for most users. You automatically pick up bug fixes, performance improvements, security patches, and new features as soon as they ship, without touching your embed code.

In some cases, though, you may want to pin the player to a known version. You can do that by appending @<version> to the script URL.

Version specifiers

Add an @<version> suffix to the player.js reference:

<!-- Always the latest release (default — this is what the in-app embed code gives you) -->
<script src="https://fast.wistia.com/player.js" async></script>

<!-- Explicitly track the latest release -->
<script src="https://fast.wistia.com/player.js@latest" async></script>

<!-- Pin to a specific released version (format only — 1.2.3 is illustrative) -->
<script src="https://fast.wistia.com/[email protected]" async></script>

A few things to know:

• The version must be a real, released player version. Requesting a version that doesn't exist returns an error and the player won't load, so pin only to a version you've confirmed is live.
• @latest and an unversioned player.js behave identically: both follow the newest release.
• The same @<version> suffix works for both the fast.wistia.com (standard) and fast.wistia.net (iframe) hosts.

Pinning with the npm packages

If you embed through @wistia/wistia-player or @wistia/wistia-player-react, you don't use the @<version> URL syntax, you pin through your package manager like any other dependency:

{
  "dependencies": {
    "@wistia/wistia-player": "1.2.3"
  }
}

Use an exact version ("1.2.3") to fully lock the player, or a range ("^1.2.3") to allow compatible updates. Run your install command to apply the change.

Tradeoffs and risks

Pinning is a deliberate tradeoff, not a default:

• You stop receiving updates. A pinned version will not pick up bug fixes, security patches, browser-compatibility updates, or new features. Over time a frozen player drifts further behind the current release.
• Pins are meant to be temporary. A common workflow is to pin while you test an upgrade or a specific issue, then return to the unversioned player.js (or @latest) once you're done.
• Always re-test before un-pinning. When you move from a pinned version back to latest, treat it like any player upgrade and verify your embed behaves as expected.

For most embeds, leave player.js unversioned. Consider pinning only when you have a concrete reason to hold a version steady.