> For the complete documentation index, see [llms.txt](https://docs.hivel.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hivel.ai/archive/generic/hivel-on-premises-deployment-guide-generic/10.-verification-and-access.md).

# 10. Verification and Access

On-Prem Deployment Guide (Generic)

### Definition of Installation Complete

Your deployment is complete when every item below is true:

* All VM1 and VM2 containers show Up/healthy in docker ps
* Every endpoint in Test Service Endpoints below returns a healthy response
* The UI loads at the address in Access the Hivel Application below
* At least one integration (Jira/GitHub/GitLab) has been connected and shows data in the UI

### Validation Checklist

<table data-header-hidden data-search="false"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Check</strong></td><td><strong>How to verify</strong></td></tr><tr><td>Database connectivity</td><td>psql -h $DB_HOST -U &#x3C;user> -d insightly connects successfully from VM1</td></tr><tr><td>Cache/queue (Redis) connectivity</td><td>docker exec -it insightly-redis redis-cli ping returns PONG</td></tr><tr><td>API readiness</td><td>curl http://localhost:80/health returns a healthy response on VM1</td></tr><tr><td>Git Util Service readiness</td><td>curl http://localhost:8085/health returns a healthy response on VM2</td></tr><tr><td>UI access</td><td>UI loads at http://&#x3C;vm1-ip>:3000 with no console errors</td></tr><tr><td>Integration connectivity</td><td>A connected Jira/GitHub/GitLab integration shows "connected" status in the UI</td></tr><tr><td>First-data confirmation</td><td>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.</td></tr></tbody></table>

### Step 1: Verify Services Are Running

On VM1:

```
docker ps
./deploy.sh --health
./deploy.sh --health auth-svc
```

On VM2:

```
docker ps
./deploy.sh --health git-util
```

**Expected result:** every service listed as Up (docker ps) and healthy (./deploy.sh --health).

**If it fails:** see Health checks failing in [Troubleshooting](/archive/generic/hivel-on-premises-deployment-guide-generic/11.-troubleshooting.md).

### Step 2: Test Service Endpoints

On VM1:

```
# Test API Gateway
curl http://localhost:80/health

# Test Auth Service
curl http://localhost:8095/health

# Test Insightly Service
curl http://localhost:8082/hivelapi/health

# Test UI
curl http://localhost:3000
```

On VM2:

```
curl http://localhost:8085/health
```

**Expected result:** each endpoint returns a healthy/200 response.

### Step 3: Access the Hivel Application

Once all services are healthy, access Hivel using one of these methods:

#### Option 1: Quick Check - Direct Server IP

**Choose this option when** you just want to confirm the deployment works, e.g. during initial testing. Not recommended for client-facing production access.

* Web UI: http\://\<vm1-ip>:3000
* API Gateway: http\://\<vm1-ip>

#### Option 2: Load Balancer

**Choose this option when** you need a stable, provider-managed endpoint but don't yet need a custom domain, or your organization requires traffic to pass through a load balancer for other reasons.

Use your provider's load balancer service - AWS Application Load Balancer, Azure Load Balancer / Application Gateway, GCP Cloud Load Balancing, or an on-prem load balancer (e.g. HAProxy, NGINX).

1. Create a load balancer in your provider's console
2. Configure a target/backend pointing at VM1 (ports 80, 3000)
3. Configure listener/routing rules
4. Access via the load balancer's assigned DNS name or IP

#### Option 3: Recommended for Production - DNS + Load Balancer

**Choose this option when** setting up a client-facing production environment.

1. Create a load balancer (as in Option 2)
2. Create a hosted zone / DNS record set with your DNS provider (Route53, Azure DNS, Cloud DNS, or your existing internal DNS)
3. Create an A record (or alias) pointing to the load balancer
4. Configure an SSL/TLS certificate on the load balancer for HTTPS
5. Access via your custom domain: <https://your-domain.com>

If you'd rather not stand up a full load balancer, the lighter-weight Caddy-based option in DNS and HTTPS Setup achieves the same HTTPS outcome directly on VM1.

**Next step:** [Troubleshooting](/self-managed-hivel-deployment/virtual-private-cloud/azure/hivel-on-premises-deployment-guide-azure/troubleshooting.md) - if anything above fails; otherwise proceed to connect your integrations, then review Backup and Restore, Upgrade and Rollback, Uninstall and Cleanup, and Security and Secrets to prepare for ongoing operations.

<br>

{% columns %}
{% column %} <a href="/archive/generic/hivel-on-premises-deployment-guide-generic/9.-log-rotation-setup.md" class="button primary" data-icon="backward">Log Rotation Setup</a>
{% endcolumn %}

{% column %}

{% endcolumn %}

{% column %} <a href="/integrations.md" class="button primary" data-icon="forward">Integrations</a>
{% endcolumn %}
{% endcolumns %}
