Primary commands

div deploy

Ship your website to a real, public URL. The fun command.

div deploy

This is the command that takes your folder and turns it into a real, public website at <slug>.div.so. The first deploy reserves your slug and emails you a one-click claim link. Every deploy after that quietly pushes your updates without prompting you for anything.

#Synopsis

div deploy

div deploy takes no arguments. The behavior depends on whether your folder has been deployed before — keep reading.

#Your first deploy

When you run div deploy in a folder that hasn't been published yet (i.e. div.json has "slug": null):

What email should we send your link to: you@example.com
✓ Sent! Check your inbox to deploy hello-a4f9d2.div.so

Here's what just happened behind the curtain:

  1. The CLI walked your folder, respected .divignore, and confirmed everything fits within the size limits.
  2. It asked for your email.
  3. It pinged the server, which allocated a unique slug, created a locked project, and returned a claim token.
  4. It uploaded every file to that locked project.
  5. It asked the server to email you a verification link.

Until you click that link, the website is reserved but not yet public. Visiting hello-a4f9d2.div.so in a browser returns 404 to anyone who isn't you.

When you click the link:

  • Your email is verified.
  • The project flips to public.
  • You're whisked away to your live website.

Cue the confetti. 🎉

#Re-deploying

When you run div deploy in a folder that's already been published (i.e. div.json has a slug and your machine has saved credentials for it):

✓ Updated hello-a4f9d2.div.so

No email prompt, no new project, no friction. The CLI sends each file straight to the same slug using the credentials it saved on your first deploy.

#What gets uploaded

div deploy walks the current directory and uploads every file that isn't ignored. The defaults skip:

node_modules
.git
.DS_Store
.env*
div.json
*.log

You can add to that list with a .divignore file in your project root.

Files are sent base64-encoded so binary files (images, fonts, PDFs) round-trip cleanly. Uploads run with a concurrency of 8 — fast enough that you won't be staring at a progress bar.

#Limits

  • 10 MB per file
  • 50 MB total per deploy
  • Allowed filetypes: an allowlist of web-safe formats — HTML, CSS, JS, images, fonts, media, PDFs, text, markdown. Anything else (archives, executables, source files for non-web languages) is dropped with a warning. See Limits for the exact list.

A deploy that exceeds any of these errors out before a single byte is uploaded, so you'll never end up with a half-pushed website.

#Error states

Message What it means What to do
No div.json here You're not in a Div project. cd into one, or run div new to scaffold one.
No files to deploy The folder is empty (or everything's ignored). Add an index.html.
This deploy is X MB; cap is 50 MB Your folder is over the cap. Compress images, drop unused assets, or split into multiple websites.
This project has been claimed You verified the email at some point, which clears the CLI's claim token. Run div login.
No saved credentials for <slug> on this machine div.json references a slug, but your machine has no token for it. Run div login.
Saved credentials are no longer valid The server has rotated or cleared the token tied to this slug. Run div login.
Too many requests Rate-limited. Wait a minute, try again.

#How verification works

After your first deploy, the link in your inbox is a one-time signed URL that's valid for 24 hours. Clicking it:

  1. Verifies your email.
  2. Clears the project's locked state on the server.
  3. Flips the project to public.
  4. Redirects you to your live URL.

Until then, your project is in a holding pattern — only your CLI session can write to it (via the saved claim token), and only you (with the verification link in your inbox) can finish claiming it. After 7 days of being unverified, unclaimed projects are swept away and the slug returns to the available pool.

#See also