Editing in the site editor on GitHub
With the hosted Deco CMS, the site editor edits your GitHub repository directly, with nothing to clone or install: saves are commits on a draft branch, and publishing brings them to production.
A merchandiser needs to change the homepage hero before tomorrow's sale. They don't have Git, a copy of the code or a dev server, and they shouldn't need one.
On your machine, the site editor edits your working tree through deco serve, and you commit the changes yourself (see Edit on your machine). With the hosted Deco CMS, the site editor's GitHub backend edits your repository itself.
This page shows how the site editor edits your repository on GitHub, where uploads go, and how publishing and CI work.
What changes
The site editor's forms, variants, pages and redirects are the same on both backends: they need only the schema and the files. What differs is where a save goes and what happens next.
deco serve | The site editor's GitHub backend | |
|---|---|---|
| Edits | The files in your working tree | Your repository on GitHub |
Where .deco/ is | The folder you pass with --root, or the nearest one with a .deco/; deco serve tells the site editor | The site editor's "app root" setting, such as apps/storefront in a monorepo |
| A save | Writes the file; your app hot-reloads | One commit on the draft's branch, with all the files of that save |
| Committing | You review the diff and commit | Each save is already a commit |
| Drafts and publishing | Not shown: your branch is the draft, and you merge it | A draft branch per draft; publishing brings it to production |
| Uploads | Files in public/assets/ (or the folder you pass with --assets) in your working tree, which you commit | Deco's asset storage, served from a CDN |
| Preview canvas | Your dev app | Your site, with a ?__draft= link |
| The site editor checks for changes | About every 2 seconds | When you return to the tab, and about every 30 seconds |
| Needs | A copy of the repository on your machine and a running CLI | A connected site |
Uploads
With the hosted Deco CMS, images and other files editors upload in the site editor go to Deco's asset storage, not your repository. The site editor saves each file's CDN address in the field, such as https://assets.decocms.com/…/summer-banner.jpg, so images are served from a CDN close to your visitors, your app serves nothing for them, and your repository doesn't grow with every image. Without the hosted Deco CMS, uploads are files in your repository (see Images and other uploads).
Uploads already in your repository keep working: a field holds either kind of address, and your app keeps serving the files it has.
Drafts are branches
The editor works with a draft; they never need to create a branch, merge or rebase. The backend manages the branch automatically. An editor's changes live on a draft branch in your repository, created on the first save. Each save is one commit on it, so the draft's history is ordinary Git history: you can review it in a pull request, diff it, or check it out. Saving is last-writer-wins: if two people edit the same entry at once, the later save replaces the earlier one (see Where edits go).
When new content lands on production, open drafts incorporate it automatically; inactive drafts catch up when reopened. Untouched files follow production. For any file edited or deleted in the draft, the draft wins the whole file, even if production changed different fields in it. There is no property-level merging. The backend also synchronizes before saves and publishing. See Keeping drafts current.
While the draft is unpublished, the site editor previews it on your real site; see Previewing drafts.
Publishing
Publishing reconciles the draft with current production and writes its content-only changes to your production branch (usually main), respecting required checks. The delivery pipeline prepares an immutable release and promotes it only when ready. Servers adopt it on their next background check (see Publishing without a deploy); saving, preparing and promoting are separate statuses.
The site editor reads the schema committed on the branch it edits, so editors only see the block types and fields that branch's code has. Deploy code that adds a type before publishing content that uses it (see Keep running code compatible).
CI on site editor commits
The site editor's saves are commits that only change content, and the check workflow validates them like any other change. Saves always land on a draft branch. When publishing opens a pull request, the check runs on it before merge. When publishing brings the draft straight to your production branch, it's live as soon as it lands, so also run the check on pushes to main:
on:
pull_request:
push:
branches: [main]How the site editor reads and writes your files over the protocol is in Content protocol, and its compatibility details in Site editor compatibility.