After your Connected Docs site is live, you need a way to keep it current when your repository changes. Doxbrix supports three deployment modes: **webhook** (reb...
After your Connected Docs site is live, you need a way to keep it current when your repository changes. Doxbrix supports three deployment modes: **webhook** (reb...
After your Connected Docs site is live, you need a way to keep it current when your repository changes. Doxbrix supports three deployment modes: webhook (rebuild on push), poll (rebuild on a schedule), and manual (rebuild on demand).
Configure the mode from Project settings → Deployments.
Deployment modes
Webhook (push-to-deploy)
The fastest option. Doxbrix registers a webhook with your Git host so that every push to the tracked branch triggers a rebuild immediately.
To enable webhook auto-deploy:
Go to Project settings → Deployments and select Webhook as the auto-deploy mode.
Doxbrix generates a unique webhook endpoint URL and a signing secret for your project.
In your repository settings (GitHub, GitLab, etc.), add a new webhook:
- Payload URL — paste the Doxbrix webhook URL
- Content type —
application/json - Secret — paste the signing secret
- Events — select Push events only
Doxbrix verifies the signature on every incoming request.
Make a small change and push. The build should start within a few seconds and appear in the deployment history.
Poll
Doxbrix checks your repository on a regular schedule and triggers a rebuild when it detects new commits on the tracked branch. No webhook configuration is required — useful when you cannot install webhooks in your Git host.
Select Poll in Project settings → Deployments and choose a polling interval. Doxbrix will check for changes and rebuild when new commits are found.
Manual
Doxbrix does not rebuild automatically. To update the site, click Rebuild in Project settings → Deployments, or upload a new bundle if your project uses the bundle source.
Use manual mode when you want full control over when updates go live — for example, to review changes before publishing them to readers.
Deployment history and rollback
Every build is stored as a deployment. Open Project settings → Deployments to see the full history, including:
- build trigger (push, poll, or manual)
- commit SHA and branch
- build start time and duration
- number of pages indexed
- build status (success or failed)
To roll back to a previous deployment, click Rollback next to any successful build. Doxbrix atomically swaps the live site to that build's output — no rebuild required.
View build logs
If a build fails, click View log on the deployment entry to download the full build output. The log shows every command Doxbrix ran, including install and build output, so you can identify the exact failure point.
Common causes of build failures:
- Missing environment variables required by your build (set them in Project settings → Environment)
- A dependency that cannot be installed in the build sandbox
- A build command that assumes a local file that is not committed to the repo
If the issue is unclear, use the Report build failure option to send the log to the Doxbrix team.