Deployments

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

​

Deployment status

​

When a new version fails Hiveku’s check

On sites that run server code (Next.js sites, for example), Hiveku sends each new version one test request, to its /api/health page, before the publish finishes. If the new version crashes or answers with a server error, the publish shows Failed. On Production and Staging, Hiveku then switches your site back to the version visitors had right before this publish, usually within 1 to 3 minutes. Visitors can get the new version’s errors during those minutes. The message names that version by when it was published, for example:

Publish failed. The new version gave server errors when Hiveku checked it, so your site is showing the version from Oct 19, 3:02 PM again. Your changes are saved; fix them and publish again.

• Your changes stay saved. Fix the error and publish again.
• This only happens while you publish. Hiveku never switches your site on its own.
• If the version from before fails the check too, or Hiveku cannot switch back, the publish goes live and its message says so (“Published, but …”).
• A first publish has nothing to go back to. It goes online, and the message says the new version gave server errors.
• On Development the publish goes live, and the message says the new version gave server errors, so you can open the site, see them and fix them.
• Publishing a site that was offline or unpublished brings it back with the new version, even when that version fails the check: there was no earlier version on the live site to go back to. The message says the new version gave server errors.
• Going back brings back the code only. Files in public folders and your site’s settings stay as the new publish left them.
• If Hiveku cannot run its check, the publish goes live and says it was not checked.
• The check is one request, so open the pages you changed after you publish.
• Sites served as plain files have no server code, so there is nothing to check.

​

Which branch a tier deploys

Development and Staging can show a branch instead of Your site. What a tier shows decides what each deploy ships: Publishing Your site saves its latest changes as a version first (“Saved automatically before publishing”), so you can always come back to what was published. When a tier shows a branch:

• The deploy ships the branch’s latest version. Its latest changes are saved as a version first, named after the deploy, so what you see in the editor is what ships.
• The Deploy button labels the tier with its branch, and says how many new versions the branch has had since the tier’s last deploy.
• The size check runs against the branch, not Your site.
• A tier cannot show a branch and publish from GitHub at the same time. Move it back to Your site if you want GitHub to be the source.

If a tier shows a branch that no longer exists, the deploy refuses until you move the tier back to Your site. See Branches and environments.

​

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: 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. When Hiveku needs the whole branch from GitHub before it can publish (the site was never brought in, the branch was rewritten on GitHub, or too much changed), the deploy stops and says so, for example: “This site publishes from GitHub, and Hiveku needs to bring the whole branch in from GitHub first. Nothing was published. Bring it in from the GitHub panel, then publish again.” A pull from GitHub saves Your site as a version first, so you can go back to it. 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.

​

If a deploy goes wrong

If a deployment introduces a problem, choose the way back that fits. Anything that changes what visitors see rebuilds your site, which takes a few minutes.

​

Go back to an earlier version

For pages and code, go back to the version that worked. On the Branches tab, open that version, click Roll back to this version, and leave Also put this version on the live site now ticked: Your site goes back to that version and is published in one step (Roll back and put it live). Newer versions stay, so you can undo it. See Versions.

​

Bring files back from an earlier deploy

Hosting › Deployment History lists each deploy. Restore files brings your project files back to that deploy (“Restore your project files to this deployment?”, Restore files), with images and uploads when that deploy kept a copy of them. A safety backup is saved first. This changes your project files only: visitors keep seeing your live site as it is until you deploy again.

​

Bring back images and data

Versions hold pages and code only. To bring back images, uploads or database data, restore a restore point in Project history, then deploy.

​

Bring back one file

Open the file in the code editor and click History. It lists the file’s earlier copies; Bring it back brings one back as a new version. Then deploy.