Deploying Pyvoid for Your Firm
Installation methods, update behavior, configuration cascade, security posture, and IT administration reference for deploying Pyvoid across teams.
Related tools
Deploying Pyvoid for Your Firm
This guide covers what an IT administrator, BIM Director, or Digital Practice Lead needs to know before rolling Pyvoid out to a team, office, or firm. It is honest about what ships today, what is in flight, and what is not yet built.
Architecture Overview
Pyvoid is a standalone Revit add-in. It does not require Pyvoid, Dynamo, or any third-party host. The runtime stack:
| Layer | Technology |
|---|---|
| Host application | Autodesk Revit 2025, 2026, 2027 |
| Add-in loader | Pyvoid.Engine (C# / .NET 8) |
| Script runtime | IronPython 3.4 hosted by Pyvoid.Engine |
| UI framework | WPF with Fluent 2 theming |
| Dashboards | WebView2 (for D3.js health visualizations) |
Pyvoid registers as a standard Revit add-in via .addin manifest. It loads on Revit startup and adds a single ribbon tab. No background services run between tool invocations.
Installation Methods
Network Path (Available Now)
The simplest deployment for teams of any size. Place the Pyvoid.extension folder on a shared network drive and configure each user's Revit to load from that path.
- Copy
Pyvoid.extensionto a network share (e.g.,\\server\bim-tools\Pyvoid\) - Place the
.addinmanifest in each user's Revit add-in folder (%APPDATA%\Autodesk\Revit\Addins\{version}\) - Users restart Revit. The Pyvoid tab appears.
Pros: Zero per-machine installation. Updates are instant (replace files on the share). Works with any deployment tool that can copy files.
Cons: Requires network access at Revit startup. No automatic version pinning per user.
Signed MSI Installer (In Development)
A signed Windows Installer package compatible with SCCM, Intune, and Group Policy deployment. This is Phase 8 on the engineering roadmap.
Status: In development. Not shipping as of April 2026.
What it will include: Silent install flag, per-machine or per-user install option, uninstall cleanup, and code-signed binaries.
For pilot teams: Use network-path deployment. The MSI is for firm-wide rollout at scale.
Manual Install
For individual evaluation or small teams without a shared drive:
- Clone or download the repository to a local folder
- Place the
.addinmanifest in the Revit add-in folder - Restart Revit
Supported Revit Versions
Pyvoid builds with multi-target framework support for:
- Revit 2025
- Revit 2026
- Revit 2027
A single deployment serves all three versions. The loader detects the running Revit version at startup.
Update Behavior
Pyvoid does not auto-update. Updates are applied by replacing files in the deployment location.
Network-path deployments: Replace files on the share. Users pick up changes on next Revit startup, or immediately via the Hotload tool in the DevTools panel.
Local installs: Pull from the repository or replace files manually.
No auto-update mechanism exists today. This is a known gap. For pilot teams, manual updates on a shared drive are sufficient. Automated update delivery is on the roadmap.
Security Posture
Network Behavior
Pyvoid makes zero network calls at runtime by default. All tool execution is local. The only exceptions:
- DataLink Google Sheets connector - makes authenticated API calls to Google Sheets when the user explicitly configures a Google Sheets data source
- MCP server - communicates over a local Named Pipe (no network traffic) when enabled
No telemetry, analytics, crash reports, or usage data leave the machine unless the user opts in.
Telemetry
Telemetry is disabled by default and requires explicit user consent to enable. When enabled:
- No model content is transmitted
- No personally identifiable information is collected
- Configuration is documented in
config/telemetry.yaml
Code Inspection
The full source code (210,000+ lines) is available for inspection. The test suite contains 20,000+ automated tests across 505 test files.
Data Storage
All Pyvoid data is stored locally:
| Data | Location |
|---|---|
| User preferences | %APPDATA%/Pyvoid/ |
| Selection memory (MWrite/MRead) | %APPDATA%/Pyvoid/ per project |
| Tool configuration | %APPDATA%/Pyvoid/ |
| Audit logs | Per-tool, stored locally |
No server-side component exists. No cloud storage is used.
Configuration Cascade
Pyvoid supports a layered configuration system:
Firm defaults > Office overrides > Project overrides > User overrides
Each level inherits from the level above and can override specific settings. This allows a firm to set baseline naming conventions, an office to adjust for local standards, and individual users to customize UI preferences.
What works today:
- User-level configuration (full support)
- Project-level configuration (full support)
- Firm-level configuration via shared config files (supported, needs hardening)
- Config import/export via JSON (Settings Hub)
What is in development:
- Admin-lockable settings (partially implemented)
- Full firm-tier hardening for enforced settings
What is not yet built:
- Role-based access control (RBAC)
- Configuration version history
- Centralized push of config changes
For a pilot team of 3-15 users, the current config model is sufficient. For firm-wide deployment where you need to enforce settings across 100+ seats and lock them, wait for the RBAC and admin-lock features.
WebView2 Dependency
Several health visualization tools (Health Visualizer, Warning Visualizer) use WebView2 for D3.js dashboards. WebView2 is included with Windows 10 1803+ and all Windows 11 installations.
If WebView2 is not available (locked-down environments):
- The D3 dashboard tools will not render
- All other Pyvoid tools (200+) work normally
- Non-dashboard equivalents exist for core audit functions
Pilot Program Recommendations
For firms evaluating Pyvoid before a broader rollout:
- Start with 3-5 users on a single project, using network-path deployment
- Run for 30 days covering at least one milestone cycle
- Focus on the governance loop: ReViewer audit, Warning Visualizer triage, Conform Names enforcement, Wipe Hub cleanup
- Measure: Warning count before/after, time spent on manual cleanup tasks, user feedback
- Expand: Add users incrementally rather than rolling out firm-wide in one step
Known Gaps for Enterprise Buyers
This section is intentionally honest about what is not yet shipping:
| Capability | Status | Timeline |
|---|---|---|
| Signed MSI installer | In development | Phase 8, 2026 |
| SCCM/Intune deployment | Depends on MSI | Phase 8 |
| Role-based access control | Not started | 6-12 months |
| Auto-update mechanism | Not started | Post-Phase 8 |
| Formal SLA / paid support tier | Not started | 6-12 months |
| Software bill of materials (SBOM) | Not started | On request |
| Published vulnerability disclosure | Not started | Planned |
For Band 2-3 firms (25-500 people): the current deployment model supports pilots and team-level adoption. For Band 4 firms (500+) requiring firm-wide Intune rollout and RBAC: wait for Phase 8 and the RBAC milestone.
Support
During the current phase, support is direct developer access. No queue, no tier-1 gatekeeping. Response times are fast because the person answering wrote the code.
Paid support tiers with published SLAs are on the roadmap for 2026-2027.
Last updated: 2026-04-16