docs

Guides

Updating a site

What to expect on subsequent deploys, and how the CLI knows it's the same project.

Updating a site

After your first div deploy, every subsequent deploy is shorter and sweeter:

div deploy
# ✓ Updated mysite-a4f9d2.div.so

No email prompt, no new project, no verification email. The CLI recognizes the folder, looks up the saved claim token, and pushes the new files straight to the same slug. Quick and quiet, the way it should be.

This guide covers the moments where re-deploying gets a little more interesting.

#The happy path

You ran div deploy from this folder before, on this machine, before clicking the verification email. The CLI:

  1. Reads div.json, sees a slug.
  2. Reads ~/.config/div/auth.json, finds a claim token for that slug.
  3. Walks your folder, applying ignores and limits.
  4. Uploads each file to the same slug.

Total time: a couple of seconds.

#After clicking the verification email

Once you've verified, the server clears the claim token. The next div deploy will fail with:

✕ This project has been claimed. Run `div login` to deploy updates from a verified account.

This is expected — verification was the moment ownership transferred from "anyone holding the claim token" to "the verified user account." Run div login once and future deploys from this machine will use your account token instead of the old claim token.

If you haven't verified yet, you can still re-deploy from the CLI as many times as you want. The claim token is valid until the moment of verification; after that, switch to div login.

#On a different machine

div.json is committed to git. Saved credentials are not. So if you clone your project on a new laptop and run div deploy:

✕ No saved credentials for mysite-a4f9d2 on this machine. Run `div login` to deploy updates.

Same root cause as above — claim tokens are per-machine, and div login gives this machine an account token for multi-machine access.

#When something else has gone wrong

Error Cause Fix
Saved credentials are no longer valid for this project Server rotated or cleared the token without you verifying. Rare. div login, or contact support.
Couldn't reach https://div.so: fetch failed Network issue, or you've pointed the CLI at a host that's down. Check div config get api-url and your connection.
Too many requests You hit the rate limiter. Wait a minute and retry.
This deploy is X MB; cap is 50 MB Your folder grew past the per-deploy cap. Compress images, drop unused assets, or split the project.

#What gets uploaded on every deploy

Every deploy is a full upload. The CLI doesn't currently diff against the remote — every file in your folder (minus ignores) is sent every time. For most Div projects (a few HTML files, some CSS, a handful of images) this is fast enough that diffing wouldn't be a meaningful win.

If your project has dozens of large images and you're seeing slow deploys, ask yourself:

  • Is everything in .divignore that should be?
  • Are your images optimized? (You can drop pre-optimized files into the folder; Div doesn't process them.)

A diff-aware deploy mode is on the roadmap; until then, full uploads are the default.

#See also