For the complete documentation index, see llms.txt. This page is also available as Markdown.

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-svc

Step 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>:3000

  • API 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.

  1. Create a Standard Load Balancer in the Azure Portal

  2. Configure a backend pool pointing to VM (ports 80, 3000)

  3. Configure health probes and load balancing rules

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

Backup and Restore,

Upgrade and Rollback,

Uninstall and Cleanup and

Security and Secrets to prepare for ongoing operations.

Last updated