登录

verifywise

verifywise-ai活跃维护

一站式 AI 治理与 LLM 评测平台，内置 EU AI Act、ISO 42001、NIST AI RMF 等 20 多个合规框架，帮团队做模型审计、风险评估和合规落地。

Complete AI governance and LLM Evals platform with support for EU AI Act, ISO 42001, NIST AI RMF and 20+ more AI frameworks and regulations. Join our Discord channel: https://discord.com/invite/d3k3E4uEpR

v2.6.7发布于 2026-11-09 20:47 UTC374star128fork同步于 2026-11-10 12:01 UTC
AI治理LLM评测合规审计风险评估AI法案
对比 GitHub 官网aiai-auditingai-complianceai-governanceai-governance-model

怎么上手

由 README 提炼，执行前请确认
原文 
git clone https://github.com/bluewave-labs/verifywise.git
cd verifywise
cd Clients && npm install
cd ../Servers && npm install
cp .env.dev Servers/.env
硬件要求按 README 说明

README 未说明 GPU 或显存要求；开发环境需本机跑 PostgreSQL、Redis 与 Python 3.12+ 的 EvalServer，生产用 Docker/Kubernetes 部署。

有 Docker 镜像
下载：源码 zip·GitHub Releases（安装包）本站不镜像安装包

项目说明

由 README 自动翻译提炼
没人工点评？写下你的经验

开源自托管 AI 治理平台，帮企业按 EU AI Act、ISO 42001 等框架做合规与 LLM 评测

一站式 AI 治理与 LLM 评测平台，内置 EU AI Act、ISO 42001、NIST AI RMF 等 20 多个合规框架，帮团队做模型审计、风险评估和合规落地。

核心能力

  • 内置 EU AI Act、ISO 42001、NIST AI RMF 等 20+ 框架的合规管理
  • 提供 LLM Evals 评测服务，由独立 Python EvalServer 承担
  • 管理 AI 模型清单、用例风险、供应商风险与事件记录
  • 内置策略管理器与策略模板，支持自动化与报表输出
  • 可本地自托管部署，数据与治理流程完全自控

容易踩的坑

需自行准备 PostgreSQL 并手动创建 verifywise 数据库，还要另起 Redis 容器；LLM 评测功能依赖单独启动的 Python EvalServer，不装则评测不可用；首次启动前必须改 JWT_SECRET 和 SUPERADMIN_PASSWORD，否则用默认弱口令；公司商用超过 60 天评估期需购买商业许可。

内容由模型根据 README 生成，可能不完整或不准确，以官方文档为准。看原文 README

最近发版

5 个版本v2.6.7
全部 release
  1. v2.6.7最新正式版2026-11-09 · 2026-11-09 20:47 UTC

    RACI matrices, external use case owners, AI app bulk import and customizable dashboards

    Each use case has a RACI matrix and can be owned by a person without a VerifyWise account. Use cases and AI apps can be linked, and an AI app can be created from a use case. AI apps can be imported from Excel and risk-assessed in bulk. Each user can choose which widgets appear on their dashboard. Organization Admins can connect MCP clients to their own organization. Use case routes now check access to the use case, and policy PDF export works in the Docker images.

    Upgrade notes

    No action needed. Upgrade as usual. Database changes run on startup by themselves (#5268, #5269, #5293, #5294, #5295, #5297). Changes your users will notice:

    • Use case access (#5270, #5291, #5296): the useCase.edit permission alone no longer allows a change to a use case. Updating, deleting, changing status, classifying or running lifecycle steps takes an Admin, the owner or a member. Other users get a 403, custom roles included. Reading a use case also takes access. Assignees of linked tasks and approvers of its active workflow can read it.
    • MCP (#5136): super admins no longer get governance tools such as use cases, risks and compliance. They get the organization and user tools. Governance tools are for organization Admins.
    • Policy PDFs (#5292): remote images no longer appear in the PDF. Images uploaded through the editor and older base64 images are unaffected.
    • CSV exports (#5294): values a spreadsheet would run as a formula get a leading quote. Text such as +1 555 0100 gains the quote too. Numbers are unchanged.

    Highlights

    • RACI (#5294): a matrix per use case shows who is responsible, accountable, consulted and informed. Most roles come from the owner, team members, approvers and task assignees. People with edit access can change roles or add a person. The matrix warns when no person or more than one person is accountable. It can be exported.
    • External owners (#5269): a use case can be owned by a person with a name and email only. They get email notices and gain no access to the app.
    • AI apps (#5293, #5297): link use cases and AI apps, or create an AI app from a use case. Import apps from an Excel template, with a preview before anything is written. Open assessments on many apps at once against a reusable questionnaire of weighted questions rated 1 to 5. App owners answer for their own apps. Editors can answer for any app, one at a time or through an Excel worksheet.
    • Dashboard (#5268): each user can show, hide or reorder widgets with Edit layout. Operations and Executive views keep separate layouts.
    • MCP (#5136): organization Admins can connect through a new MCP tab in Settings, limited to their own organization. New tools cover user management, read-only lists of vendors, policies, models, incidents, tasks, trainings and datasets, plus update_incident. Super admins gain remove_user and list_invitations.
    • Shadow AI (#5267): sorting the AI tools list works. Start governance records the risk on the new model inventory entry. Many blocked requests to one tool in a batch fire one alert for that tool.
    • Policies (#5292): PDF export works in the published Docker images, where it failed before. The render sanitizes the HTML with JavaScript turned off. It blocks network requests other than data: URLs and web fonts.
    • Fixes (#5295): a user linked to a FRIA assessment can be deleted.
    • What's new (#5298): an entry for AI app bulk import and assessment.
    • Internals (#5151, #5235, #5238, #5265, #5156): 9 intake and deadline emails use the shared color palette. Extensions and buttons use design tokens. Shared translation strings have their own file. Tests audit the routes that need no login.
    • Security (#5270, #5291, #5296, #5294, #5290): use case routes check access to the use case. Linking a task to a framework requirement takes access to its use case. CSV exports neutralize s
  2. v2.6.62026-11-03 · 2026-11-03 01:19 UTC
    查看更新说明

    Use case and AI app lifecycle, multiple organizations per account and Shadow AI syslog ingestion

    Use cases and AI apps now move through In review, Planned, Live and Retired. Each has a go-live date, a retirement step and a regular "Still live?" check. One account can belong to several organizations, with a different role in each. Shadow AI can take proxy logs over syslog, and matched AI tool usage is recorded again. Intake forms suggest a risk level to the applicant and can be previewed as each role. The confirmation email names the reviewer and the review date.

    Upgrade notes

    No action needed. Upgrade as usual. Database changes run on startup by themselves (#5179, #5186, #5195, #5196, #5197, #5198, #5200, #5227, #5228, #5232). Changes your users will notice:

    • Organization memberships (#5179): users and their roles move to a new memberships table, and the existing data is copied across. A user who belongs to two or more organizations picks one at login.
    • Lifecycle stages (#5196, #5200): an existing use case starts as In review when an approval request is pending, as Retired when it is Closed, otherwise as Planned. AI apps under review start as In review, banned apps as Retired, the rest as Planned.
    • Shadow AI figures can drop (#5228): insights count only traffic that matched an AI tool, and so do the new user and sensitive department alerts. Ordinary web traffic inflated them before.
    • Syslog listener (#5232): off by default. To turn it on, set SHADOW_AI_SYSLOG_ENABLED=true, give it a TLS certificate and key, then publish port 6514. Docker Compose, the install script and the Helm chart (shadowAiSyslog) carry commented examples.
    • API versions (#5173): new and changed endpoints live under /api/v1. The existing /api routes are unchanged.

    Highlights

    • Use cases (#5196, #5199, #5195, #5185): tabs for In review, Planned, Live and Retired, with counts. An owner can mark a use case live, confirm it is in use or retire it, and each move is written to its history. Pending intake requests appear in the In review tab. A new dashboard card shows time in review. Admins set the region and frameworks a new use case starts with.
    • AI apps (#5200): the same lifecycle as use cases. An intake form can request a new AI app, which is created when the request is approved.
    • Organizations (#5179): one account can join several organizations. Inviting an email that already has an account sends a join link. Removing a user takes them out of that organization only.
    • Intake forms (#5198, #5197, #5175, #5177, #5176, #5174, #5194, #5181): the applicant sees the suggested EU AI Act risk level with the articles behind it. They can accept it or add context for the reviewer. The confirmation email names the reviewer and the due date, from a review time set per form. Builders can preview the form as the submitter or the review flow as each role. A test submit in the preview sends nothing. A Logic view lists every calculation, show/hide rule and risk tag. Formulas and rules can read any field, and they show field names. Routing thresholds have info tooltips. The submissions list refreshes while it is open.
    • Intake fixes (#5165, #5178, #5180, #5182, #5184): the builder keeps edits made during a save, and guidance goes on the right field. Routing labels use plain terms. URL checks, empty answers and placeholders work as expected.
    • Shadow AI (#5232, #5233, #5227, #5228): a syslog listener for Zscaler, Netskope, Squid and generic key=value or CEF logs, with a key per source. The AI tool registry (55 tools) is back, so matched events are stored instead of failing. Insights count AI tool usage only. The parsers handle time zones, IPv6 and more Netskope formats, and the user guide is updated.
    • AI Gateway (#5202): MCP servers can authenticate with OAuth client credentials or AWS IAM.
    • Post-market monitoring (#5229): a View reports button on the Monitoring tab opens the saved reports for
  3. v2.6.52026-10-29 · 2026-10-29 01:13 UTC
    查看更新说明

    Intake live checks, vendor document prefill and working intake emails

    The public intake form now flags problem answers while the submitter fills it in, and can suggest answers from an uploaded vendor document. Intake emails, which failed to send before this release, now go out. AI agents can be linked to use cases and models. Emails and reports use the shared color palette, and a file upload check is fixed.

    Upgrade notes

    No action needed. Upgrade as usual. Two changes your users will notice:

    • Intake emails start arriving (#5158): the submission received, new submission, approved, rejected and second review emails failed before and were never sent. They now go out.
    • AI governance scores can drop (#5147): high and critical risks with no mitigation status now count as unmitigated.

    Database changes run on startup by themselves (#5107, #5108, #5109, #5137, #5157, #5159). Intake forms saved as left-aligned move to centered, and each one is recorded so it can be put back.

    Highlights

    • Intake live checks (#5157): hints under a question for possible EU AI Act Article 5 practices, Annex III high-risk uses, GDPR Article 22 automated decisions and answers that are too short or placeholders. An "Intake assistant" panel lists open hints. The server re-runs the checks at submit and shows them to the reviewer. A form builder toggle turns them off.
    • Vendor document prefill (#5157): a submitter uploads a PDF or Word file and gets suggested answers for empty questions, each marked as suggested with a Confirm button. The file is not stored.
    • Intake review (#5088): approving or rejecting a submission shows a confirmation. Rejections are no longer reported as approvals, and a submission cannot be decided twice.
    • Intake form (#5107): the public form is centered and the contact field focus outline is fixed.
    • AI agents (#5108, #5113): agents have a description, use case links, model links and the standard owner picker. Synced agents can be linked to a use case from the review panel.
    • AI risk suggestions (#5106): suggestions now use the use case description.
    • Model lifecycle (#5112): detaching a file keeps it. Report delete only applies to reports.
    • AI Gateway (#5137): guardrail counts on the dashboard and the Logs page now agree.
    • LLM Evals (#5147): an LLM judge scorer with no threshold no longer passes every sample. Google API keys that start with AQ. are accepted.
    • Emails and reports (#5087, #5139, #5142, #5144, #5146, #5149, #5154): emails, PDFs, charts and the post-market monitoring report use the shared color palette. Emails also share one head.
    • Lists (#5075): the lists in Model inventory, Vendors, Policies, Tasks and Training registry use shared loading, empty-state and error views.
    • Fixes (#5147): auditing an ISO 42001 annex category counts toward readiness, and a screening question no longer uses a double negative.
    • Security (#5147): file uploads to /api/files record the signed-in user as the uploader and check project membership. They no longer trust user or project ids sent in the request.
    • Dependencies: Dependabot updates across the backend, frontend, EvalServer and GRS UI (#5093, #5094, #5096 to #5103, #5084, #5085, #5134).

    What's Changed

  4. v2.6.42026-10-23 · 2026-10-23 16:47 UTC
    查看更新说明

    Intake risk scoring, review routing and oversight

    Intake submissions now arrive with a risk score and a list of suggested risks. Each form can route submissions to senior or standard reviewers by score, send a share of approvals for a second review and track reviews on a new Oversight tab. This release also adds test, performance and monitoring tooling, and merges the risk catalog pickers into one.

    Upgrade notes

    • Migrations (#5077, #5089): three migrations run on startup. They add columns for intake scoring, suggested risks and routing, plus one index. Routing stays off for existing forms until an Admin turns it on.
    • One-time scoring of existing submissions (#5077): when the worker first starts, it scores each existing intake submission that has no assessment yet, once, with that form's AI provider. That is about 6 model calls per submission. Forms with no AI provider keep their rule score. Existing submissions are marked as already notified, so they get no new emails.
    • New forms (#5077): the EU AI Act risk step is on by default for new intake forms. Existing forms keep their setting.

    Highlights

    • Intake scoring: each submission gets a 0-100 score from 5 model runs. The score never falls below the floor set by its EU AI Act classification and maps to a Low, Medium, High or Critical band. Reviewers see the score, its rationale and suggested risks with drafted mitigations. They can accept, edit or dismiss each suggestion, and accepted risks go into the risk register on approval.
    • Review routing: an Admin can split a form's reviewers into senior and standard lanes. A score threshold and a close-call margin decide the lane. Prohibited, unscored, close-call and high-scoring submissions go to senior reviewers. Only that lane's reviewers and Admins can decide. The lane's reviewers get the new submission email along with the form's recipients.
    • Second reviews: a set share of approvals goes to a different senior reviewer, who agrees or records a miss. The email links to the submission, and the list has a "Second review" filter.
    • Oversight: a new tab shows lane mix, close calls, decision times, second review outcomes and how often reviewers kept the suggested band over 4, 8 or 12 weeks. It also lists items that need attention.
    • Risks: the IBM and MIT risk catalog pickers are now one picker. An unused vendor risk form with a hardcoded risk level is gone.
    • Fixes: dropdown and multi-select options no longer overflow the form builder's settings panel. The remove option button now works with a keyboard or a screen reader.
    • Testing and operations: new end-to-end, contract, flake, load (k6) and restore tests, plus Prometheus alert rules (#5045). Setup guides cover Alertmanager, Uptime Kuma and GlitchTip. None of this changes how the app behaves.
    • Design tokens: colors now come from one shared token set. ESLint warns when a screen adds a new hardcoded color (#5054).

    What's Changed

    Full Changelog: https://github.com/verifywise-ai/verif

  5. v2.6.32026-10-21 · 2026-10-21 18:26 UTC
    查看更新说明

    AI Gateway /v1 routing, approver checks and the MCP server in the backend

    This release makes the AI Gateway /v1 base URL work on deployments whose proxy sends everything to the frontend container. Before, those /v1 calls returned 503. Approve and reject on approval requests now check that the caller is an approver on the current step. The super admin MCP server now runs inside the backend, so it needs no separate package.

    Upgrade notes

    • AI Gateway /v1 (#5070): the frontend container now forwards /api and /v1 to the backend at VW_BACKEND_URL (default http://backend:3000). Docker Compose, Helm and the Kubernetes manifests set it, so they need no change. If your host proxy is hand-edited, either give it a /v1/ block like the one in docs/deployment/PRODUCTION_DEPLOYMENT_GUIDE.md, or let it send /v1 to the frontend. The guide also has a checklist for hand-edited proxies. Check with curl https://<your-host>/v1/models -H "Authorization: Bearer sk-vw-invalid", which should return 401 {"detail":"Virtual key not found"}.
    • Client address behind a proxy (#5070): the frontend takes the client address from X-Forwarded-For only when the request comes from an address in VW_TRUSTED_PROXIES. Docker Compose sets this to private networks. If you publish the frontend port yourself, set it to your proxy's address. Otherwise all clients share one rate limit.
    • MCP server (#5060): the super admin MCP server is now served by the backend at /api/mcp, and the separate MCPServer/ package has been removed. If you set it up before, set it up again from the MCP tab in Super admin settings: download the config and run the command shown there.
    • Approval overrides (#5059): only approvers on the current step can approve or reject. If a step needs every approver and one of them has left, a role with the approvalRequest.admin permission can decide that step through the API (override: true, step_number and a comment). There is no UI for this yet.

    Highlights

    • AI Gateway: /v1 works through the frontend container. Proxy errors come back as JSON. A stopped backend now fails in 5 seconds with a 503 instead of after 60. The virtual key base URL shown in the UI keeps the page's own port. Agent guides, the hook script and the Python SDK use your VerifyWise URL instead of localhost:8100.
    • MCP: the super admin MCP server runs in the backend. The connect page downloads a single server config and gives a command you can run again after a token rotation.
    • Approvals: approving now shows what happened (approved, moved to the next step, or still waiting on N approvers). The timeline shows each approver's vote and comment.
    • Fixes: the Linked risks tab explains what it shows and has clearer forms. "Enable automatic sync" in extensions uses the standard toggle. The MCP tools page has a back link when opened from MCP servers.
    • Security: any logged-in user, Auditors included, could reject a pending approval request. Only approvers on the current step can now approve or reject (#5059). follow-redirects is updated for two advisories (#5061, #5064).
    • Dependencies: Dependabot updates for the frontend packages and EvalServer (#5063, #5065). GRSModule's CI audit passes again (#5066).

    What's Changed

用户点评

登录用户的真实使用记录，可按版本和硬件筛选
共 0 条

    还没有人点评。第一个说出真实体验的人最有价值。

    README 原文

    未翻译
    在 GitHub 打开

    [!NOTE] VerifyWise has a new license. New releases are licensed under the VerifyWise Community & Evaluation License (VCEL) 1.0, which replaces the Business Source License 1.1.

    • Free for personal use, schools and universities, public sector institutions and noncommercial research. Schools and public bodies can also run it in production for their own work.
    • Companies can evaluate VerifyWise free for 60 days. Running it inside a company after that needs a commercial license.
    • Releases you already use keep the license they were released under.

    Questions? See the licensing FAQ or write to [email protected]. Thank you for using and supporting VerifyWise.

    VerifyWise is a source available AI governance platform designed to help businesses use the power of AI safely and responsibly. Our platform ensures compliance and robust AI management without compromising on security.

    We are democratizing AI best practices with a solution that can be hosted on-premises, giving you complete control over your AI governance.

    Quick links

    Screenshots

    The main dashboardLLM Evals
    EU AI Act project viewAI Use case risks
    AI Risk managementAI Model inventory
    AI Model risksAI Policy manager and policy templates
    AI vendors and vendor risksAI Incident management (with filter example)
    AI Trust CenterAutomations
    Reporting

    Features

    VerifyWise platform

    • Option to host the application on-premises or in a private cloud
    • Source-available license (VCEL 1.0): free for personal, educational, public sector, noncommercial research and evaluation use. Commercial use needs a commercial license (licensing FAQ)
    • Faster audits using AI-generated answers for compliance and assessment questions
    • Full access to the source code for transparency, security audits, and customization
    • Docker and Kubernetes deployment (also deployable on render.com and similar platforms)
    • User registration, authentication, and role-based access control (RBAC) support
    • Major features:
      • Support for EU AI Act, ISO 42001, NIST AI RMF and ISO 27001
      • Dashboard: executive view & operating view
      • Vendors & vendor risks
      • AI use cases and risks
      • Global tasks with timeline view
      • Complete LLM Evals and LLM Arena
      • Evidence center with folder structure
      • AI trust center for public view
      • AI literacy training registery
      • AI Advisor, AI-powered chat interface providing governance recommendations
      • AI Detection Module, which scans code repositories to identify AI-generated content.
      • Shadow AI detection and risk management
      • AI agent discovery
      • Activity history for each entity
      • Integration with MIT and IBM AI risk repository
      • Model inventory and model risks that keeps a list of models used and risks
      • Policy manager to create and manage internal company AI policies
      • Risk and control mappings for EU AI Act, ISO 42001, NIST AI RMF and ISO 27001
      • CE Marking registry
      • Dataset registry
      • Desktop notifications
      • Approval workflows & approval requests
      • Detailed reports with PDF and DOCX export
      • Event logs (audits) for enterprise organizations
      • AI incident management
      • 25 built-in compliance frameworks: the four above plus 21 more, including SOC 2, GDPR, HIPAA, DORA, CCPA, NIST CSF and NYC Local Law 144
      • Built-in extensions an admin can enable per organization: Slack, MLflow, Azure AI Foundry, Jira Assets, Model Lifecycle, Risk Import (Excel) and Dataset Bulk Upload
      • Automations (when an entity changes, do this, or send period reports, or send webhooks)
      • Google OAuth2 and Entra ID (enterprise edition) support for authentication

    Installation

    The VerifyWise application has two components: a frontend built with React.js and a backend built with Node.js. At present, you can use npm (for development) or Docker/Kubernetes (production) to run VerifyWise. A PostgreSQL database is required.

    Installation using npm (for development)

    Prerequisites:

    • npm and Docker
    • Python 3.12+ (for EvalServer)
    • A running PostgreSQL, preferably as a Docker image (eg. using docker pull postgres:latest)
    • Available ports: 5173 (frontend), 3000 (backend), 5432 (database), 6379 (Redis), 8000 (EvalServer)
    Step 1: Clone, install dependencies, and set up databases

    First, clone the repository to your local machine and go to verifywise directory. Then, navigate to the Clients directory and install the dependencies:

    git clone https://github.com/bluewave-labs/verifywise.git
cd verifywise
cd Clients
npm install
cd ../Servers
npm install

    Go to the root directory and copy the contents of .env.dev to the .env file. For security, you must set a strong and unpredictable JWT_SECRET in your .env file. This secret is used to sign and verify your JWT tokens, so it must be kept private and cryptographically secure. You can generate a 256-bit base64-encoded secret using openssl rand -base64 32.

    cd ..
cp .env.dev Servers/.env

    In .env file, change FRONTEND_URL and set your super admin credentials:

    FRONTEND_URL=http://localhost:5173
[email protected]
SUPERADMIN_PASSWORD=ChangeMe!Str0ng

    Important: Change SUPERADMIN_PASSWORD to a strong password (minimum 8 characters). These credentials are used to create the initial super admin account on first setup.

    Note: CORS is automatically configured to allow requests from the same host (localhost, 127.0.0.1) where the backend is running.

    Run the PostgreSQL container with the following command:

    docker run -d --name mypostgres -p 5432:5432 -e POSTGRES_PASSWORD={env variable password} postgres

    Run redis with following command:

    docker run -d --name myredis -p 6379:6379 redis

    Access the PostgreSQL container and create the verifywise database:

    docker exec -it mypostgres psql -U postgres
CREATE DATABASE verifywise;
    Step 2: Set up EvalServer (for LLM evaluations)

    EvalServer is a Python-based service that handles LLM evaluations. If you want to use the evaluation features, follow these steps:

    cd EvalServer
python3.12 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

    Set up the environment file. You can copy the minimal .env.example file in the EvalServer directory:

    cp .env.example .env
    Step 3: Start the application

    Navigate to the EvalServer/src directory, activate the virtual environment (if not already activated), and start the server:

    cd EvalServer/src
source ../venv/bin/activate
python app.py

    Navigate to the Servers directory and start the server in watch mode:

    cd Servers
npm run watch

    Navigate to the Clients directory and start the client in development mode:

    cd Clients
npm run dev

    Note: Make sure to replace {env variable password} with the actual password from your environment variables.

    Note: On a fresh setup, a super admin account is created automatically using the SUPERADMIN_EMAIL and SUPERADMIN_PASSWORD environment variables. Log in with these credentials, then create an organization and invite users to get started. The login page will display a banner guiding you through this process.

    Installation using Docker (production)

    First, ensure you have the following installed:

    • npm
    • Docker
    • Docker Compose

    Create a directory in your desired folder:

    mkdir verifywise
cd verifywise

    Download the required files using wget:

    curl -O https://raw.githubusercontent.com/bluewave-labs/verifywise/develop/install.sh
curl -O https://raw.githubusercontent.com/bluewave-labs/verifywise/develop/.env.prod

    Make sure to change the JWT_SECRET variable to your liking, set your super admin credentials (SUPERADMIN_EMAIL and SUPERADMIN_PASSWORD), and change localhost to the IP of the server. An example is shown below:

    BACKEND_URL=http://64.23.242.4:3000
FRONTEND_URL=http://64.23.242.4:8080
[email protected]
SUPERADMIN_PASSWORD=YourStr0ngPassword!

    Note: CORS is automatically configured to allow requests from the same host where the backend is running.

    Change the permissions of the install.sh script to make it executable, and then execute it.

    chmod +x ./install.sh
./install.sh

    Now the server is running on the IP and the port you defined in .env.prod file (8080 by default).

    If the install.sh script doesn't work for some reason, try the following commands:

    docker-compose --env-file .env.prod up -d backend
docker ps  # to confirm
docker-compose --env-file .env.prod up -d frontend
docker ps  # to confirm

    If you want to re-run install.sh for some reason (e.g want to change a configuration in .env.prod file), first stop all Docker containers before starting a new one:

    docker-compose --env-file .env.prod down
./install.sh

    Note: On a fresh setup, a super admin account is created automatically using the SUPERADMIN_EMAIL and SUPERADMIN_PASSWORD environment variables. Log in with these credentials, then create an organization and invite users to get started.

    Installing SSL

    Here are the steps to enable SSL on your system.

    1. Make sure to point domain to VM IP

    2. Install Nginx:

    sudo apt update
sudo apt install nginx -y
    1. Create a config file (/etc/nginx/sites-available/verifywise) with the following content. Change the domain name accordingly.
    server {
    server_name domainname.com;

    client_max_body_size 200M;

    # Custom error page for maintenance/upgrades
    error_page 502 503 504 /upgrade.html;

    location = /upgrade.html {
        root /var/www/verifywise;
        internal;
    }

    location / {
        proxy_pass http://localhost:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

    location /api/ {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
 }
    1. Create the directory for custom error pages and copy the upgrade page:
    sudo mkdir -p /var/www/verifywise
sudo curl -o /var/www/verifywise/upgrade.html https://raw.githubusercontent.com/bluewave-labs/verifywise/develop/Clients/upgrade.html
    1. Enable the config:
    sudo ln -s /etc/nginx/sites-available/verifywise /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx
    1. Install Certbot for SSL:
    sudo apt install certbot python3-certbot-nginx -y
    1. Obtain SSL certificate. Change the domain name accordingly.
    sudo certbot --nginx -d domainname.com
    1. Update the .env.prod to point to correct domain. Change the domain name accordingly.
    BACKEND_URL=https://domainname.com/api
FRONTEND_URL=https://domainname.com

    Note: CORS is automatically configured to allow requests from the same host where the backend is running.

    1. Restart the application
    ./install.sh

    Note: The Nginx configuration includes custom error pages that display a professional "upgrading" message instead of the default "502 Bad Gateway" error when the servers are not running or during maintenance.

    Email configuration

    VerifyWise supports multiple email service providers through a provider abstraction layer, enabling administrators to choose the most suitable email service for their organization. The system includes security enhancements such as TLS enforcement, input validation and credential rotation for supported providers.

    Below is a list of supported email providers. You can use this documentation to setup the email service of your choice.

    • Exchange Online (Office 365) - Microsoft's cloud email service
    • On-Premises Exchange - Self-hosted Exchange servers
    • Amazon SES - AWS Simple Email Service
    • Resend - Developer-focused email API
    • Generic SMTP - SMTP support for any provider

    Ports

    You’ll need to open ports 80 and 443 so VerifyWise can be accessed from the internet.

    Security

    If you find a vulnerability, please report it here.

    相关项目

    同分类里 star 最高的项目
    对比全部 →
    promptfoo
    promptfoo·TypeScript

    用声明式配置对提示词、Agent 和 RAG 做自动化评测与红队渗透测试，支持多模型横向对比，可接入命令行和 CI/CD。

    提示词评测+4模型评测
    27019+782.7k0.125.12026-11-09 21:45 UTC
    opik
    comet-ml·Python

    面向 LLM 应用、RAG 和 Agent 工作流的可观测与评测平台，提供全链路追踪、自动评估和生产级监控看板，帮团队定位问题并持续优化效果。

    LLM 可观测+4模型评测
    23298+461.9k2.2.1432026-11-10 09:38 UTC
    deepeval
    confident-ai·Python

    一个 Python 的 LLM 评测框架，提供开箱即用的评估指标，帮你在开发和上线前系统检验大模型输出质量。

    LLM评测+3模型评测
    19405+482.2ksetup-v0.1.02026-11-10 11:12 UTC
    ragas
    vibrantlabsai·Python

    面向 LLM 应用的自动化评测工具，用合成测试集和多种指标量化 RAG 与生成效果，帮你在上线前发现质量问题。

    LLM评测+4模型评测
    16280+231.8kv0.4.32026-02-24 07:47 UTC