Skip to main content
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

1

Build

Hiveku runs your build process (if configured) and prepares the output files.
2

Publish

The built files are pushed to the hosting infrastructure.
3

CDN update

The global CDN cache is invalidated and updated with your new files.
4

Live

Your site is live at its URL with the latest changes.

​
Deployment status

StatusMeaning
BuildingThe build process is running
DeployingFiles are being published to hosting
LiveDeployment succeeded and the site is serving the new version
FailedSomething 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:
OutcomeWhat happens
Already in syncNear-instant — the deploy proceeds with no changes pulled
GitHub has newer contentHiveku pulls the new commits into the database, then proceeds with the deploy
Both sides changed the same fileDeploy 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.
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.
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: Every deployment is anchored to a checkpoint Hiveku creates right before the deploy started. To restore the entire project to the state it was in before that deploy:
1

Open the Hosting page

Navigate to Hosting. The Checkpoints section lists every checkpoint, with the one tagged pre-deploy matching each deployment.
2

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.
3

Redeploy

Click Deploy again to publish the restored files as a new deployment.

​
Single-file rollback

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

Open version history

Go to the file tree, right-click the affected file, and select Version History.
2

Restore the file

Browse to a previous version and restore just that file.
3

Redeploy

Click Deploy again to publish the restored file as a new deployment.
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.