Platform Operations and Support
Investigate orders and deployments, monitor mail and cloud services, and protect the platform's data and secrets.
Use the office to follow each customer issue from its commercial record to its fulfillment result. Start with the client, order or invoice, and affected service so changes apply to the correct account.
Daily checks
Review unpaid and overdue invoices, services awaiting provisioning, failed deployments, open tickets, domain expiry and renewal problems, and transactional email failures.
For BRAD Cloud, also review wallet balances and adjustments, configured prices, usage, sender-domain verification, and jobs relevant to provider dispatch or reconciliation. A healthy CMS deployment does not prove its cloud service is funded and ready.
Investigate a failed deployment
Open Infrastructure → Deployments and select the existing record. Review its current state, step breakdown, error, logs, attempt history, and associated service.
Common preparation failures include:
- A hosting product with no server group.
- No active compatible Berth node in that group.
- Missing panel credentials or plan slug.
- No linked license service.
- No complete release archive for the license product.
- An inaccessible or oversized archive.
- Invalid database, domain, or application configuration.
Fix the underlying condition before using Retry where offered. The retry workflow reuses the deployment record and preserves attempt history. Its confirmation assesses existing resources and the evidence available about prior work.
Do not delete the record as a substitute for a retry. Deletion and resource teardown have different consequences, and a record can be the only history connecting a failed deployment to provisioned resources.
Handle payment and support issues
Review orders, invoices, and transactions together. If payment was received, inspect settlement and service activation rather than telling the customer to pay again. A provisioning failure does not automatically reverse payment.
Use Customers → Tickets for replies and Emails for transactional delivery history. SendGrid event processing can distinguish accepted requests from subsequent delivery outcomes. A dry-run email log means no message was actually sent.
Do not request passwords, private keys, or full database URLs in tickets. Use service references, exact errors, and redacted logs.
Maintain integrations
Periodically test server and registrar connections, review node capacity, and verify that product groups still route to the intended infrastructure. Review administrator permissions and remove obsolete access.
Rotate credentials with a tested replacement path. Encryption-key changes can make stored secrets unreadable, while a license signing-key change can invalidate every installed client. Coordinate those changes rather than treating them as ordinary password updates.
Back up the platform
Retain:
- The complete MySQL/MariaDB database.
- Uploaded release files under
storage/downloads. - Environment secrets, especially signing, session, TOTP, and cloud encryption keys.
- The current source/deployment version and service-manager configuration.
- Integration configuration and any other durable application data.
Database records pointing at missing archive files cannot fulfill downloads or managed installations. Back up both and test recovery.
Update and verify
Schedule platform updates with attention to checkout, live deployments, and scheduled jobs. Back up the database and release storage, review migrations, deploy the compatible application, and inspect startup and job logs.
Afterward, verify customer and office sign-in, transactional mail, checkout in the appropriate test environment, invoice settlement, license verification and version checks, release downloads, and infrastructure connection tests.
Do not change the license API contract as part of routine documentation or platform maintenance. Older CMS installations depend on its production URL and response signatures.