Architecture

Nginx terminates HTTPS and proxies to loopback FastAPI running as the existing restricted application OS user. PHP consumers send registered service bearer credentials over certificate-verified HTTPS. FastAPI authorizes an operation, derives its tenant from the service registry, validates the payload and executes parameterized MySQL statements within a pooled transaction. Database exceptions become safe JSON errors. PHP needs neither database credentials nor a DB socket.

The repository defaults remain PostgreSQL diagnostics and the existing Azure version 13 deployment flow. Application operations require explicit opt-in APPLICATION_API_ENABLED=1 and DB_ENGINE=mysql. MySQL and MariaDB share the PyMySQL driver. PostgreSQL application operations are not implemented; its experimental tenant/ledger foundation and console remain separate.

backend/api/application.py implements tenant predicates and fixed operations. core/application_database.py owns bounded pooling, acquisition, transaction commit/rollback, server execution limits and socket deadlines. Remote MySQL connections require an explicit CA bundle and certificate/hostname verification; loopback remains supported. No schema is created by API startup or deployment. Database/migrate.py provides explicit migration streams and protected administrator credentials.

Database/mysql-auth is a new isolated contract with asi_services, asi_users, asi_sessions, asi_verification and asi_audit. It preserves user/token/account concepts from legacy 01_users.sql without treating inconsistent historical tables as safe to install. Existing user data is not imported automatically. Legacy company_id mapping, roles and consent/KYC fields require consumer and schema-owner review before any data migration. Existing PostgreSQL RLS is preserved in its own stream; MySQL isolation is enforced through service-derived tenant predicates and composite foreign keys. Runtime credentials are a cross-tenant trusted API boundary and must never be shared with PHP clients.

The separate loopback VM operator service handles the static administration UI, SQL console, backup and lifecycle jobs. Its private operator token is unrelated to application credentials; it grants privileged administration and must be restricted to trusted operators. The UI's contractVerified flag remains false for the PHP consumer; it was not converted into an application client.

Deployment scripts preserve staging/production target selection, pinned SSH identity, TLS checks and run.sh interfaces. Readiness is distinct from operation, PHP integration, backup restoration and production acceptance.

Dual MySQL TLS and HTTPS interface

The dual-interface extension replaces the earlier loopback-only MySQL limitation with an explicit verified-TLS transport: remote MySQL settings require DB_SSL_CA; certificate and hostname verification cannot be disabled. Existing PostgreSQL configuration remains a compatibility path, not the target database for the new dual interface. The new production target must be an explicitly configured MySQL 8.0/MariaDB 10.11 schema, not an automatic PostgreSQL conversion.

HTTP routes delegate business transactions to core/application_service.py. Shared lookup/update database routines are also called by tenant-bound direct wrappers. Direct consumer grants are execute-only; they do not inherit HTTP scopes or API runtime table access. A transactional trigger audits username changes through both paths. Service quotas are stored in the authoritative DB and apply across workers.

See the two-path architecture diagram and contract and reviewable public network proposal. Generated /setup-api/ gateway routes are now loopback-only. No production listener, NSG, account, certificate or schema was changed by this work.