# Phase 6 — simple local setup

You requested a simple setup without Cloudflare or extra cloud configuration. The default remains the existing WampServer/MySQL installation on this computer.

## Start the application

Double-click **Start Zentrik HRMS.cmd** in the project folder. It verifies InnoDB, reuses a running Zentrik server or starts PHP hidden on loopback, then opens **http://127.0.0.1:8000/login**. Start WampServer first if MySQL is stopped. Existing accounts, passwords and MFA are unchanged. The launcher does not reset data, change credentials, start mail/webhook workers or require a custom domain, Docker, Redis or a cloud account.

The database remains `zentrikhrms`, user `root`, blank password. All 83 tables and the application database session use InnoDB. These existing local credentials are not the production-container credentials.

## Company branding

Sign in as the company administrator and open **Deployment & integrations**. Confirm your password when requested. Open **Company branding & theme**; set a name, welcome text and dark hex theme color. Optionally upload PNG/JPEG logos and a square PNG favicon. Images are decoded and re-encoded, size limited and served from controlled branding routes. White button text must meet a 4.5:1 contrast ratio. Platform branding removal requires its package feature.

The company theme appears in its workspace, printable HR outputs and branded notification emails. Branded login pages appear on verified company hosts if that optional feature is deployed later. The shared local login keeps the platform identity so it can serve both platform and company accounts. Nothing requires changing your local hostname.

## Optional integrations

**API tokens:** choose exact abilities and a lifetime up to 90 days. Copy the displayed token to your integration's secret store; it is shown once and only its hash is retained. Every request rechecks its user, MFA, current role, company and module entitlements. Revoke it from the same page. See API_V1.md for the registered resources/actions and idempotency contract.

**Webhooks:** configure an HTTPS public endpoint and event subscriptions. The signing secret is shown once and stored encrypted. Events contain references, not HR document or payroll contents. Delivery validates/pins public DNS, checks TLS, blocks redirects and special/private networks, and retries up to five times. This is an optional outbound integration; no endpoint or worker has been activated in your local database.

**SSO:** optionally configure an HTTPS OpenID Connect issuer and client credentials, then link exact provider subjects to existing MFA-enrolled company users. It uses authorization code/PKCE, state, nonce, issuer/audience/time/signature checks and the existing local MFA challenge. It does not match accounts by email or create users automatically. Discovery/token/JWKS endpoints must share the issuer origin; RS256 is supported. Each deployed callback host must be registered with the provider. Local password login continues to work without SSO.

## Optional domains and offline deployment

These controls are included for future use and need no configuration for the local setup.

Custom domains require configured platform fallback/CNAME target, exact ownership TXT proof and CNAME verification, then HTTPS certificate/routing proof. A Caddy adapter/Compose edge profile handles on-demand TLS; Cloudflare is not used. Unverified hosts cannot serve company pages, and a custom host cannot access another company or platform administration. Host-only secure cookies and host-bound OAuth callbacks are enforced. An hourly queued check disables mappings whose DNS proof no longer matches.

Offline deployments verify RSA/SHA-256 signed licences using an externally mounted public trust-key JSON. The private signing key stays with the issuer. Licences bind installation UUID, company slug, sequence, validity, user cap, modules and add-on features. Signed caps intersect plan/module permissions. Replays/downgrades, changed claims, expired licences, wrong installations and substantial clock rollback are rejected. Recovery/renewal remains available from the deployment screen on the normal platform/local host. The local shared setup uses SaaS mode and needs no licence file.

## Backup, restore and release evidence

An encrypted pre-upgrade backup was verified before installation. The Phase 6 recovery adapter encrypts SQL chunks and an authenticated manifest without saving a plaintext SQL dump; full snapshots include encrypted vault objects. A full snapshot with documents requires maintenance mode and stopped workers. A separate recovery drill restored all 83 InnoDB tables with matching counts; a quarantined encrypted document and MFA fixture were independently recovered using the real keys and DPAPI. No test records were added to your working business tables.

Deployment & integrations also accepts UAT/security/load/restore/upgrade evidence for independent review. An author cannot accept their own evidence. No production sign-off has been inserted into your company data. The automated browser scenarios and local benchmark are test evidence, not an independent penetration test or internet production-capacity certification.

The main scheduler, general notification worker and webhook worker remain off. Existing queued emails were not dispatched. Real document publication still uses the previously implemented antivirus gate; unavailable ClamAV keeps uploads quarantined. This gate has not been bypassed to simplify setup.