Yes, a customer can run a separate MCP DigLab installation on their own compatible server. This is a deployment project, not a change to a managed connection key. Arrange the approved software package, activation and maintenance scope with DigLab before starting.
Check the server requirements#
For the current standalone build, prepare PHP 8.3 or newer with sodium, PDO, cURL, mbstring, JSON and OpenSSL. Install the appropriate database driver for SQLite, MySQL, MariaDB or PostgreSQL. Also verify PHP ZIP and the ZipArchive class for the native package updater. The internationalisation extension is recommended. Package requirements can change, so use the release-specific preflight as the final check.
The deployment also needs a working HTTPS domain, writable application storage and a scheduler running every minute. Configure the web server to serve the application's public directory while keeping configuration, database files and private storage outside web access. Choose CPU, memory and disk capacity for the actual workload rather than assuming one fixed server size suits every customer.
Install the approved release#
- Confirm the hosting model, authorised administrator and software activation arrangement.
- Take a recoverable backup of any existing site or application on the target host.
- Obtain the approved standalone release through the agreed delivery route and verify its integrity.
- Deploy the application into its own directory or container and configure the public web root.
- Open the initial setup screen on the chosen domain and complete the requirements, database and administrator steps.
- Save the generated installation secrets in the approved encrypted backup route. Do not copy them into tickets or shared project files.
- Configure the scheduler and confirm the first-run setup is closed after installation.
- Connect the required software activation and apply the agreed branding.
Do not clone a live owner installation, its database or its credentials to create a customer's environment. Start with a clean installation and authorise that customer's services separately.
Activate and brand the installation#
Software activation and the branding add-on have separate entitlements. An activated core installation does not prove that branding is active, and a managed connection key cannot activate either package. The authorised operator completes activation using the licensing account and arrangement agreed for this customer.
Open the installation's License screen in Settings and choose the license connection or authentication action. Sign in through the supported account flow, select the intended entitlement for the exact installation domain and complete consent. Return to the application and check the activation status, site allowance, expiry or lifetime status and a fresh verification time. Do not apply another installation's stored license value as a shortcut.
Where branding is included, open Settings → Add-ons, install the branding add-on if it is absent, and use its license connection action. Verify that its activation is accepted separately. A missing entitlement or payment request must be resolved through the agreed delivery arrangement; this guide does not authorise a purchase.
Open Branding and set the product name, company name, website, support URL and documentation URL. For MCP DigLab customer help, use https://mcp.diglab.ai/docs/. Upload the approved light/dark logos and icon where required, choose a readable accent colour and review the previews. Apply a customer's own brand only when that branding scope is authorised. Save the settings and reload the interface.
Verify the administrator header, login page, help links and any relevant consent screen using the intended domain. Check email branding through an authorised test rather than sending an unsolicited message. If an operator chooses to hide the branding controls, first store its recovery link securely; that link is not customer documentation. Branding changes the interface, not ownership of software rights or visibility of code to a server administrator.
Verify before handing it over#
Check HTTPS, administrator access, protected endpoint behaviour, the scheduler and a recoverable backup. Create a narrow test server, verify discovery and an agreed read-only tool, and confirm that missing or wrong credentials are rejected. Test any requested write capability separately and check the final state.
The customer must receive the domain, administrator responsibility, enabled workflows, support route and update/backup plan. Document whether DigLab will continue operating the installation or hand over maintenance. Use backups and updates for the ongoing checklist.