Publish a project

Publishing is the one act that puts a project on brilliant.design. Until you publish, a project is just files on your disk and nothing about it reaches Brilliant's servers. This page covers how to publish, what public and private mean, and how checkpoints, forks, and history work once a project is online.

Publishing from the desktop app

Publishing lives in Settings, in the Sharing tab. You can reach it from the Sharing command, the account avatar menu, or a project tile's menu on the home screen.

There is exactly one gesture: tick the Published row. Before it goes live, Brilliant shows you a confirmation and a What gets published review, so you can see every file that will be uploaded. It also flags anything that looks like a secret (a stray .env file, an SSH key) as a heads-up, never a block.

Confirm, and your project goes live. The link is copied to your clipboard so you can paste it straight into a message.

Publishing from the web

Signed in on the web, the New menu gives you two ways to start a cloud project:

New project: a fresh, empty project.
Create from Figma: bring a Figma file in as a new project.

Both start a new project in the cloud, public by default.

Public by default

New projects are public by default. That is the model, not an accident:

Free is for working in public. Personal is for working in private.

A public project is visible to anyone with the link, and going public is always free. Keeping work private is the paid part.

Visibility: public and private

Every published project is either public or private, and only the owner can flip it.

Public: anyone with the link can view your latest work.
Private: only you and the people you have invited can see it. On a paid plan you can also hand out a read-only share link so someone can view it without an invite.

Making a project private is a paid feature. Flipping a private project back to public is free and takes effect immediately. See Plans and billing for what private work is bundled with.

Control what visitors see

By default, visitors to a published project see your latest work, live, including autosaves as you make them. If you would rather they see only a polished version, switch the audience to Checkpoints only. Visitors then see your most recent checkpoint instead of your in-progress canvas, while you keep working freely behind it.

"Control what visitors see" is a paid feature. It pairs naturally with checkpoints, described below.

Checkpoints and version history

A checkpoint is a named, saved version of a published project. It is the unit of version history on the web.

You create checkpoints on purpose. In the desktop app, hit the bookmark button in the top island, or run the Create Checkpoint command, give it a name (or take the suggested one), and it is minted. Autosave keeps your work safe continuously, but autosave never creates a checkpoint. Checkpoints are the moments you decide are worth marking.

Your checkpoints are listed at brilliant.design/{handle}/{project}/history. There is no cap on how many you keep and no retention limit; the only ceiling is your storage quota.

Restoring an older checkpoint rolls forward. Instead of erasing what came after, a restore writes a new checkpoint that matches the one you picked, and your unsaved work is saved first as its own checkpoint. Nothing is ever destroyed, so you can restore, look around, and restore again without losing a thing.

Forks

Anyone signed in can fork any project they can see. A fork is a fresh copy under your own handle: it starts clean, with no history carried over, and it records where it came from so the provenance is visible.

Forking a public project is free for everyone. Forking a private project (one you were invited to) creates a private fork, so it needs a paid plan.

Clone with Git

A published project is a real Git repository with a clone URL of the form https://api.brilliant.design/git/{handle}/{project}.git. Public projects clone anonymously (unless you have limited visitors to checkpoints), so you can pull a design into a local workflow the same way you would clone code.

Unpublishing

To take a project offline, untick the Published row and confirm by typing the project's name. The moment you do, its links stop working for everyone, including you.

Your local files are untouched: unpublishing only removes the cloud copy, and everything on your disk stays exactly as it was. The cloud copy is not purged right away either. It is held for 30 days before it is permanently removed, so an accidental unpublish has a recovery window.

Stars

Star any project you want to keep track of. On the projects list, the two ways into a project are its name and its canvas thumbnails, and both open it. The Star button sits at the top right of each row, on its own, so starring a project never opens it. Starring works the way it does on GitHub: click to star, click again to unstar, and each project shows how many people have starred it. It is a free, public signal, so it doubles as a bookmark and a way to say a project is worth a look.

Your starred projects live on the Stars tab of your profile, and because stars are public, anyone visiting your profile can see them. Starring while signed out is fine: Brilliant asks you to sign in and then stars the project in the same step.

Know exactly what uploads and when: How sync works.
Work on a project with other people: Collaborate live.
See which visibility features are paid: Plans and billing.