> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hiveku.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Deployments

> Deploy your site and roll back releases

Deploying publishes your project files to your live URL. You can deploy with a button click or by asking the AI assistant.

## How to deploy

* Click the **Deploy** button in the top toolbar
* Or type "deploy my site" in the AI chat

## What happens during deployment

<Steps>
  <Step title="Build">
    Hiveku runs your build process (if configured) and prepares the output files.
  </Step>

  <Step title="Publish">
    The built files are pushed to the hosting infrastructure.
  </Step>

  <Step title="CDN update">
    The global CDN cache is invalidated and updated with your new files.
  </Step>

  <Step title="Live">
    Your site is live at its URL with the latest changes.
  </Step>
</Steps>

## Deployment status

| Status        | Meaning                                                      |
| ------------- | ------------------------------------------------------------ |
| **Building**  | The build process is running                                 |
| **Deploying** | Files are being published to hosting                         |
| **Live**      | Deployment succeeded and the site is serving the new version |
| **Failed**    | Something went wrong -- check the build logs for errors      |

## Pre-deploy GitHub sync

When your project is connected to GitHub, every deploy starts with a quick reconciliation against the GitHub branch you're deploying from. This guarantees the build matches what's on GitHub right now.

Three outcomes are possible:

| Outcome                              | What happens                                                                   |
| ------------------------------------ | ------------------------------------------------------------------------------ |
| **Already in sync**                  | Near-instant -- the deploy proceeds with no changes pulled                     |
| **GitHub has newer content**         | Hiveku pulls the new commits into the database, then proceeds with the deploy  |
| **Both sides changed the same file** | Deploy is paused with a conflict notice. Resolve in the GitHub panel and retry |

The third case is rare in practice because AI session edits auto-commit to GitHub at the end of each chat session. The only way to reach a real conflict is to edit a file in Hiveku and edit the *same* file outside Hiveku (e.g. via VSCode) before either side commits.

<Tip>
  If you need to ship anyway and let GitHub win the conflict, use **Overwrite with GitHub** in the Deploy dropdown. This discards the Hiveku-side edits for the listed files. Use carefully -- it's destructive.
</Tip>

For projects without GitHub connected, this step is skipped entirely -- the database is already the source of truth.

## Deployment history

Every deployment is recorded with a timestamp, status, and the user who triggered it. Open the **Deployments** tab in the hosting dashboard to browse the full history.

## Changes since last deployment

The deployment panel shows a summary of files that have been added, modified, or deleted since the last deployment. Review these changes before deploying to make sure everything looks right.

## Rolling back

If a deployment introduces a problem, you have two ways to roll back depending on the scope:

### Project-wide rollback (recommended for broken deploys)

Every deployment is anchored to a [checkpoint](/editor/checkpoints) Hiveku creates right before the deploy started. To restore the entire project to the state it was in before that deploy:

<Steps>
  <Step title="Open the Hosting page">
    Navigate to **Hosting**. The Checkpoints section lists every checkpoint, with the one tagged `pre-deploy` matching each deployment.
  </Step>

  <Step title="Restore the pre-deploy checkpoint">
    Click **Restore** on the checkpoint that was created just before the problematic deployment. Hiveku snapshots your current state as a safety backup first, then restores all files and assets to that point.
  </Step>

  <Step title="Redeploy">
    Click **Deploy** again to publish the restored files as a new deployment.
  </Step>
</Steps>

### Single-file rollback

If only one or two files are causing problems, use per-file version history instead -- it's faster:

<Steps>
  <Step title="Open version history">
    Go to the file tree, right-click the affected file, and select **Version History**.
  </Step>

  <Step title="Restore the file">
    Browse to a previous version and restore just that file.
  </Step>

  <Step title="Redeploy">
    Click **Deploy** again to publish the restored file as a new deployment.
  </Step>
</Steps>

<Info>
  Rollbacks create a new deployment rather than reverting to an old one. This means your deployment history always moves forward, making it easy to audit what happened and when.
</Info>