Config Versioning and Version History
RightMessage automatically tracks every change to your project's configuration (that is, all the "stuff" in your project - like questions, campaigns, etc.), creating snapshots you can review and restore when needed. This gives you a safety net when making changes and lets you see exactly how your setup has evolved over time.
How automatic snapshots work
We create a snapshot of your configuration whenever you make changes. Each snapshot captures the complete state of your config at that moment, along with metadata about who made the change and where it came from.
Snapshots are triggered by:
Auto-save events (as you work in the dashboard)
Publishing changes to your website
API updates to your configuration
Restoring a previous version
Changes made via MCP tools or Righty AI
Each snapshot includes a version number, timestamp, source (user, API, MCP, or Righty), and the complete configuration data.
Checksum deduplication and throttling
To avoid cluttering your version history with unnecessary snapshots, we use smart deduplication.
How it works: Before creating a snapshot, we calculate an MD5 checksum of your configuration data. If this checksum matches the most recent snapshot, we skip creating a new one—nothing actually changed.
We also throttle auto-save snapshots to prevent flooding your history. Since the dashboard auto-saves every 2 seconds while you're working, we apply a minimum interval between snapshots. Explicit actions like publishing always create a snapshot, regardless of timing.
This means you won't see a new snapshot for every keystroke. Only meaningful changes that result in different configuration data create new versions.
Viewing version history
Your version history shows all snapshots with key details about each change:
Version number – Sequential numbering for each configuration
Timestamp – When the snapshot was created
Source – Whether the change came from you, the API, MCP, or Righty
Created by – Which user made the change (if applicable)
Description – Context about the change (for restores and undos)
The history is paginated, so you can scroll through your complete change timeline.
Restoring previous versions
When you restore a previous version, we first create a snapshot of your current state (so you don't lose your work), then roll back to the version you selected.
The restoration is logged in your version history with the source detail "restore-version" so you can track when and what you restored.
You can also undo your last change, which works similarly but specifically targets the most recent modification. This is useful for quickly reverting a mistake.
Retention and cleanup
Version history grows over time, so we automatically clean up old snapshots to keep things manageable.
Our default retention policy:
Keep the 50 most recent snapshots, no matter what
Beyond those 50, keep one snapshot per day for the past 30 days
Older snapshots are deleted
This gives you detailed recent history while preserving key checkpoints from the past month. You still have a complete audit trail of major changes without storing thousands of auto-save snapshots.
Cleanup runs automatically via a scheduled command. You don't need to manage retention manually unless you're working with the API or console commands directly.
Version metadata
Each version stores rich metadata to help you understand what changed and why:
Source – user, api, mcp, or righty (tells you which system made the change)
Source detail – Additional context like "restore-version" or "undo"
Description – Optional notes about the change
Checksum – MD5 hash of the configuration data (used for deduplication)
Created by – User ID of the person who triggered the change
This metadata makes it easy to trace configuration changes, understand who made what updates, and identify which version you need when rolling back.