Preparing and verifying a VerifyWise deployment
Scope of this guide
VerifyWise is an AI governance management tool. This guide covers preparation, verification and handover. Take the actual installation steps from documentation for the selected version. This article does not demonstrate a tested production deployment and is not a runbook for your environment.
The review on 6 September 2026 inspected public source code at revision cdef65eb5c0ff315ce73382f544b6ce480a9abea, dated 4 September 2026. This is a development-branch revision, not a recommendation to deploy it without further verification. The official repository provides documentation and licensing terms; the reviewed README states the source-available BSL 1.1 licence. Assess permission for internal use and any service offered to customers against the exact licence of the selected version.
1. Define the goal and operational responsibilities
Before selecting infrastructure, define the number of users and systems, information to be stored, required roles, integrations and exports. Establish:
- the application owner, infrastructure administrator and responsibility for updates;
- permitted data location and processing, access management and secret management;
- availability requirements and recovery point and recovery time objectives, based on outage impact;
- a budget covering operations, backups, monitoring, support and any licences;
- acceptance scenarios and the person authorised to accept the result.
Verify SSO, localisation, imports, role granularity and particular connectors in the selected edition and version. An example configuration is not evidence that a feature is available.
2. Select and record the version
Record the application’s tag or commit, container image versions and, where relevant, Helm chart version. Do not rely on the mutable label latest. Retain the version list and configuration procedure for each installation, excluding secrets.
The following commands only download and identify the revision reviewed for this article; they do not deploy the application:
git clone https://github.com/verifywise-ai/verifywise.git verifywise-reviewcd verifywise-reviewgit checkout --detach cdef65eb5c0ff315ce73382f544b6ce480a9abeagit rev-parse HEAD3. Use the selected version’s actual interfaces
| Area | What the source review confirmed | How to proceed |
|---|---|---|
| Docker Compose | The database service is named postgresdb | Derive services and dependencies from the actual Compose file and chosen environment files |
| Backend npm scripts | Servers/package.json does not contain seed:admin, import:ai-systems, backup, restore or db:check | Use the documented procedure for that version; do not assume command names |
| Helm | The official repository URL is https://verifywise-ai.github.io/verifywise | Select a specific chart version and read its README and values |
| Helm values | Examples include replicas.backend and persistence.postgres.size | Check configuration against the selected chart’s values and generated manifests |
Reviewed sources: Compose, npm scripts, Helm README, Helm values.
Before execution, inspect installation scripts, exposed ports, volumes and default accounts. Keep secrets out of Git and published logs. Separate a test installation from production data and infrastructure.
4. Verify the deployment against your scenarios
| Scenario | Acceptance outcome |
|---|---|
| Login and roles | An authorised user can sign in and cannot exceed their role’s permissions |
| Creating and updating a record | Required fields are retained and changes are traceable to the required level |
| Import, if required | A known sample transfers without silent data loss; rejected rows have an explanation |
| Export and exit | Data can be opened and used outside the application in an agreed format |
| Backup and recovery | The database and required files are restored in a separate environment, with completeness and access checked |
| Update and rollback | Migrations, compatibility and a verified recovery path are documented |
| Dependency outage | Detection, escalation and recovery work against agreed objectives |
Write backup and recovery commands for the actual storage, database version and permissions. Successfully creating a backup file does not establish that recovery works.
5. Hand over operational information
The handover should include versions and architecture, configuration references, account and secret management, the update plan, monitoring, backups and verified recovery, known limitations and contacts. Agree support scope and response times separately.
A deployed platform can improve record keeping and workflows. It does not establish that the conclusions entered into it are correct or that the organisation complies with the AI Act.