The problem, stated precisely
You capture a client's Framer site, spend a week in Live Edit -- new copy on the pricing page, a hero image swapped, a section hidden, a route renamed from /team-2 to /team -- and deploy. Two months later they add a case study in Framer. To get it, you capture again. A capture is a fresh download; your week is gone.
Most tools stop there and call the result “a snapshot”. LayerPort stores everything you do in Live Edit as content layers keyed to the page and the element, separate from the captured files. That separation is what makes a recapture survivable: the tree can be thrown away and the layers reapplied. Source Sync is the procedure that does the reapplying without losing the things that are not layers.
What Source Sync does, in order
Keep the old tree
The pre-sync tree is preserved as a same-volume backup before a byte is downloaded. Every later pass reads from it; nothing depends on memory or on the sync finishing.
Capture the source again
The origin is downloaded fresh -- routes, assets, the module graph, all three breakpoints -- as if for the first time. New pages arrive; removed pages do not.
Carry assets and curated decisions
Your uploads (
assets/uploads), page capsules, and the collections you confirmed as CMS are copied across. Which collections you confirmed is a decision, not a detection result, so it is carried verbatim.Re-delete, then re-duplicate
Pages you had deleted are deleted again so the routes they cleared stay free; then the pages you duplicated are carried -- before renames, so their internal links are rewritten with everything else.
Reapply layers and routes
The content layers land on the new tree. Then, because the pages came down at their original URLs, your renames are performed again and the redirect stubs a rename leaves behind are placed once the routes they sit on are free.
Collections, then verify
CMS collections are detected again and reconciled with your decisions. A verification pass walks the result and writes the review list.
What survives, what waits for you
| Your work | After a sync | Why |
|---|---|---|
| Text, link and image edits | Reapplied | Layers keyed to page and element |
| Uploaded images and files | Carried | Copied from the backup tree |
| Hidden or reordered sections | Reapplied | Layers, same as text |
| Renamed routes | Re-performed | Pages come down at original URLs; renames run again |
| Duplicated pages | Carried | Placed before the rename pass |
| Deleted pages | Deleted again | So the routes stay free |
| Confirmed CMS collections | Carried verbatim | A decision, not a detection |
| An edit on a section the source removed | On the review list | There is nothing to place it on |
| A page you created at a route the source now uses | Reported as a collision | The sync never overwrites a source page |
The rule that makes it trustworthy
Where history fits
Every save in LayerPort is atomic and version zero -- the original capture -- is always reachable. The pre-sync state is itself a version, so a sync you regret is a restore. And because a restore is a save, it can be undone too; there is no one-way door anywhere in the sequence. Solo keeps ten saved versions per project, Studio forty, Pro a hundred; version zero and named checkpoints are always kept.
In practice the loop for a maintained site is: the client changes something in Framer → you run Source Sync → you glance at the review list (usually empty) → you redeploy the same folder. It is a chore of minutes, which is the difference between a site you can keep and a snapshot you eventually abandon.
After a sync, before you redeploy
- Open the review list. Empty is normal; anything on it names the page and the element.
- Diff the route list against the previous capture: new pages from the source, renames re-performed.
- Spot-check the pages you edited most -- they are the ones with layers to reapply.
- Redeploy the same way as last time; the host does not need to know a sync happened.