Recent searches

in

What is a Site?

Last modified: October 16th, 2026

On this page

Publishing Workflows and Site branching are available on our Team or Enterprise plan. Build Deploys are available on our Standard, Team, and Enterprise plans.

Want to chat about whether these features are right for you? Our support team is always happy to hear from you.

A Site in CloudCannon is one version of a website, containing all the files, content, configuration, and settings needed to edit, build, and host it. Sites are where you do the majority of work in CloudCannon.

Every Site belongs to an Organization, which is the workspace your team shares. Sites draw on the resources included in your Organization's Subscription Plan. For more information, please read our documentation on what an Organization is.

Each Site has its own:

  • Files and content — The files that make up the website, such as pages, posts, images, code, and data. Related files are grouped into Collections in the Site Navigation, such as all your blog posts or all your staff profiles.
  • Connection to your Git Repository — Sites sync with a branch of the Git Repository you use to safely store your website. Because all the content is synced from this location, your Site and your Git Repository stay in sync no matter where a change was made, so everyone on your team is working from the same files.
  • Editing Interfaces — The Visual Editor, Content Editor, Data Editor, and Source Editor for editing files in your Collections.
  • Settings — Everything specific to this version of the website, including its build configuration, domains, and who can reach it.

The relationship between websites and CloudCannon Sites#

One website can have multiple Sites on CloudCannon, with each Site representing one version of that website. This way you can keep multiple copies for different purposes, such as your live Site, a staging Site for reviewing changes before they go public, or draft Sites for individual members of your team or projects that your team is working on.

Smaller teams may only need one Site. Keeping several copies of the same website becomes useful when your team wants to draft and review changes before your visitors see them. Moving changes from one Site to another like this is called a Publishing Workflow, which is available on our Team or Enterprise plan. Sites on our Standard plan can still publish to a Publish Branch. For more information, please read our documentation on what publishing is.

Sites for the same website are independent of each other. Each one keeps its own files, settings, and connection to your Git Repository, so changing a setting on your staging Site leaves your live Site as it was.

Each Site connects to one branch of a Git Repository, and normally that relationship is one-to-one: one branch is one Site. Several Sites can also connect to the same branch. For more information, please read our documentation on how Sites connect to Git branches.

Where one website has several Sites, you can group them into a Project. For more information, please read our documentation on what a Project is.

Where to find your Sites#

You can find all the Sites in your Organization in the Sites Browser, which you open from the Sites link in the App Sidebar.

A screenshot of the Sites Browser shows a Site as a Card with its Testing Domain and build status, the Create a Site button above the list, and the Sites link in the App Sidebar.

Each Site in the Sites Browser is represented by a Card, showing the Site's name and a screenshot of the website from its most recent build. The Card also names the branch of your Git Repository the Site syncs with, the Publish Branch it publishes to if it has one, and the domain visitors use to reach the website. Finally, it shows when the Site last built and synced, and flags either one that failed.

A Card also shows a badge for anything that sets the Site apart: Branched for a Site branched from another, Main for the main Site in a Project, Edited when someone has unsaved changes open, Edit locked or Build locked when editing or building is turned off, and Pending transfer when the Site is on its way to another Organization.

If you cannot see a Site you expect, you may not have the correct permissions to view it, or it may live in a different Organization. For more information, please read our documentation on what Permission Groups are and switching between your Organizations.

Click a Card in the Sites Browser to open that Site's Site Dashboard, which summarizes recent activity and usage for that Site, with tabs for its builds and syncs. The Site Header at the top of the screen shows which Site you are viewing. For more information, please read our documentation on what the Site Header is and what the Site Navigation is.

A screenshot of the Site Dashboard Summary tab shows the Site's readme, a list of recent activity, sync and build status, and bandwidth and build time usage for the month.

Creating a Site#

There are three ways to create a Site in CloudCannon: branch an existing Site, connect a branch from your Git Repository to a new Site, or let CloudCannon create Sites for you with Deploy Previews. Which ones you can use will depend on your permissions and Project configuration.

Branching an existing Site

If the website is already in CloudCannon and you want your own copy to work on, you can create a branched Site yourself. Members of the Editors and Technical Editors Default Permission Groups can do this without help from a developer, as long as the website already has a Project. Branching is available on our Team or Enterprise plan. For more information, please read our documentation on creating a branched Site.

Connecting a new Site to your Git Repository

Creating a Site from scratch means connecting a Git Repository and configuring how CloudCannon builds the website. Members of the Owners and Developers Default Permission Groups can create a Site this way. For more information, please read our documentation on getting started with CloudCannon, which covers the process from an empty Organization to a working Site.

Creating Sites automatically with Deploy Previews

If Deploy Previews are turned on for your Project, CloudCannon creates a Site for each Pull Request in your Git Repository. CloudCannon names each one after the Pull Request it was created for, such as "PR #12: Add a new blog post". Sites can appear and disappear from your Organization based on your Deploy Previews configuration. For more information, please read our documentation on what Deploy Previews are.

Working on your Sites#

When you want to edit content on your website in CloudCannon, you can open Site files in the Visual Editor, Content Editor, Data Editor, or Source Editor. Which Editing Interfaces are available will depend on the file type and how your Site and its Collections are configured. For more information, please read our documentation on editing in CloudCannon.

If you use CloudCannon to host your website on the internet, your Site will build each time you save changes to your content and display those changes on your Testing Domain. For more information, please read our documentation on what a Site build is and what a Testing Domain is.

CloudCannon can also build your Site without hosting it, using Build Deploys to send the built website to a repository you deploy from your own infrastructure. For more information, please read our documentation on syncing build files from CloudCannon to an external provider.

Building is optional. A Site using Headless Mode has building and hosting turned off, so CloudCannon manages your content without producing a website from it. For more information, please read our documentation on what Headless Mode is.

Related Resources

Open in a new tab