Version Pinning vs Floating Aliases
Trade-offs between pinned version URLs and the @latest floating alias.
Production deployments in Odyn are addressable two ways: by a floating alias that always resolves to the most recent version, or by a pinned version number that resolves to a specific deployment. This page explains how each works and when to use which.
Floating Alias (@latest)
The default production embed code uses a floating alias. The CDN URL contains no version number:
https://cdn.odyn.dev/p/{project}/bundle.jsUnder the hood, the Cloudflare Worker looks up the project's @latest pointer in KV and resolves it to the current production version's R2 path. When you deploy a new version, the KV pointer updates, and subsequent requests serve the new content.
Behavior
- Every new production deploy updates the
@latestpointer. - Existing edge caches may serve the previous version until KV propagates (typically under 60 seconds globally).
- No embed code changes are needed when deploying new versions.
Use case
Use the floating alias when you want visitors to always load the latest code without touching the embed snippet. This is the standard setup for most Webflow projects.
Pinned Version (@{version})
Pinned URLs include the version number:
https://cdn.odyn.dev/p/{project}@42/bundle.jsThe Cloudflare Worker resolves @42 directly to version 42's R2 path. No KV @latest lookup is involved.
Behavior
- The URL always resolves to the same content, regardless of subsequent deployments.
- The underlying R2 object is immutable and never overwritten.
- Edge caches can hold the response indefinitely (
Cache-Control: immutable).
Use case
Use pinned URLs when you need a known-good version that does not change:
- Embedding on a client site where you control the update schedule.
- Referencing a specific version in documentation or QA environments.
- Holding a stable version while testing a new deployment on staging.
Comparison
| Aspect | Floating (@latest) | Pinned (@42) |
|---|---|---|
| Resolves to | Current production version | Specific version |
| Updates on deploy | Yes | No |
| Cache behavior | Short TTL (KV propagation) | Immutable, permanent |
| Embed code maintenance | None | Must update version number |
| Rollback | Deploy previous version or restore from snapshot | Already pointing at desired version |
| Propagation delay | Up to ~60 seconds | None (direct R2 path) |
How Version Numbers Work
Version numbers are monotonically increasing integers scoped to a project and environment. The first production deployment is version 1, the second is version 2, and so on. The version number increments on every production deploy. Restoring a previous version changes your editor files only and does not create a new version. Deploy to production after restoring to publish those files as the next version.
Combining Both
A common pattern is to use the floating alias in production embed code for active development, then switch to a pinned URL once a version is validated and ready for long-term stability. You can run both simultaneously: the floating alias on your primary site, and pinned URLs on client sites or archived pages.
Related
- CDN URL Patterns for full URL anatomy.
- Immutable Bundles for why pinned URLs are safe.
- Edge Resolution and Cache for propagation timing.
- Restore and Production Deploys for restoring previous versions.