Verification and Access
On-Prem Deployment Guide (Azure)
Your deployment is complete when every item below is true:
All VM containers show Up/healthy in docker ps.
Every endpoint in Test Service Endpoints below returns a healthy response.
The application is reachable at the address you configured in Access Hivel Application below.
At least one integration (Jira/GitHub/GitLab) has been connected and shows data in the UI.
Validation Checklist
Check
How to verify
Database connectivity
psql "host=$DB_HOST port=5432 dbname=insightly user= sslmode=require" connects from VM
Cache/queue (Redis)
docker exec -it insightly-redis redis-cli ping returns PONG on VM
API readiness
curl http://localhost:80/health returns healthy on VM
UI access
UI loads at http://<vm-public-ip>:3000 with no console errors
Integration connectivity
Connected Jira/GitHub/GitLab shows "connected" status in the UI
First-data confirmation
Open the relevant dashboard in the Hivel UI for the integration you just connected (e.g. Jira/GitHub/GitLab) - records/metrics appearing there confirm data is flowing. This is the primary supported signal for on-prem/VPC deployments
Step 1: Verify Services Are Running
On VM:
# Check all containers
docker ps
# Check service health
./deploy.sh --health
# Check specific service
./deploy.sh --health auth-svcStep 2: Test Service Endpoints
On VM:
Step 3: Access Hivel Application
Once all services are healthy, access Hivel using one of these methods:
Option A: Quick test / pilot - Direct VM Public IP
Choose this only for quick testing or pilots - not recommended for production (no load balancing, and no HTTPS unless you add the Caddy option in DNS Setup).
Web UI:
http://\<vm-public-ip>:3000API Gateway:
http://\<vm-public-ip>
Option B: Azure Load Balancer
Choose this when you need a stable, health-checked entry point but don't require a custom domain yet.
Create a Standard Load Balancer in the Azure Portal
Configure a backend pool pointing to VM (ports 80, 3000)
Configure health probes and load balancing rules
Access via the Load Balancer's public IP or DNS name
Option C: Recommended for production - Azure DNS + Load Balancer
Choose this for customer-facing production deployments. If you'd rather not stand up a full Load Balancer or Application Gateway, the lighter-weight Caddy option in DNS Setup achieves the same HTTPS outcome for smaller deployments.
1. Create a Load Balancer (as above) or Application Gateway
2. Create an Azure DNS zone for your domain
3. Create an A record pointing to the Load Balancer's public IP
4. Configure an SSL/TLS certificate (Application Gateway or Key Vault-managed certificate) for HTTPS
5. Access via custom domain: https://your-domain.com
Next step: Troubleshooting - if anything above fails.
Otherwise create your first admin account and connect your integrations - see Application Setup Guide: User Sign-up and Integration
then review
Security and Secrets to prepare for ongoing operations.
Last updated