How the CLI Keeps You in Sync Across Web and Terminal

The two-editor problem

Htmlhost gives you two ways to edit a site. You can work locally in your code editor and deploy with the CLI. Or you can open the site in the web editor, make changes visually, and publish from the browser.

Both are useful for different tasks. The web editor is great for quick copy tweaks, AI-powered edits, and visual fine-tuning. The local editor is better for structural changes, writing new pages, or working with your own tools and extensions.

But if you use both, you can end up with conflicting versions. You deploy from your laptop, then edit in the browser, then try to deploy from your laptop again. If the CLI blindly overwrites the remote site, your browser edits are lost.

The htmlhost CLI prevents this with an automatic sync check.

How the sync check works

Every time you deploy or pull, the CLI records a version number in the .htmlhost link file. This version corresponds to the state of the site at the moment of the last sync.

When you run htmlhost deploy on a linked project, the CLI contacts the server and checks the remote version before uploading anything. If the remote version is higher than the version your local project last synced with, it means something changed on the server since your last deploy or pull.

What you see when changes are detected

If the CLI detects that the remote site has been modified, it pauses the deploy and presents three options:

  ! Remote changes detected — my-site.htmlhost.co was modified since your last deploy.
    Remote version: 5 · Local version: 3

  ? What would you like to do?

    1. Pull changes first, then deploy
    2. Deploy anyway (overwrites remote changes)
    3. Cancel

Option 1: Pull first

This downloads the remote changes to your local project using the same mechanism as htmlhost pull. After pulling, the CLI asks you to run htmlhost deploy again. This gives you a chance to review the pulled files, merge them with your own changes if needed, and then deploy the combined result.

Option 2: Deploy anyway

This proceeds with the deploy and overwrites whatever is on the server. Use this when you're certain your local version is the correct one and the remote changes should be discarded.

Option 3: Cancel

This aborts the deploy entirely. Useful when you want to investigate the situation before making a decision.

A typical workflow

Here's what the full loop looks like when you're editing across both environments:

1. Deploy your project from the terminal with htmlhost deploy
2. Open the site in the web editor and make some visual tweaks
3. Go back to your terminal and make additional changes locally
4. Run htmlhost deploy again
5. The CLI warns you that the remote site was modified
6. Choose "Pull changes first" to download the web editor edits
7. Run htmlhost deploy one more time to push everything together

This way, nothing gets lost. Your web editor changes and your local changes both end up in the deployed site.

CI/CD pipelines

If you're deploying from a CI/CD system (like GitHub Actions), there's no human to answer the prompt. In this case, use the --no-pull-check flag to skip the sync check entirely:

htmlhost deploy --no-pull-check

This is also useful when you have a single authoritative source (like a Git repo) and want the CI deploy to always win, regardless of any manual edits made through the browser.

When does the check run?

The sync check only runs when all of these are true:

• You're re-deploying to an existing linked site (not creating a new one)
• Your .htmlhost file contains sync metadata (meaning you've deployed or pulled at least once)
• You haven't passed --no-pull-check

For first-time deploys or when using --new, there's nothing to compare against, so the check is skipped.

Keeping everything in sync

The sync check is one piece of a larger workflow that the CLI supports. Together with htmlhost pull and htmlhost clone, it means you can freely switch between the terminal and the browser without worrying about losing work. Edit where it's convenient, and the CLI keeps track of what's changed.