rConfig Vector Prism – Best Practices

rConfig Vector Prism Best Practices: Production Operations and Hardening

This page collects practical recommendations for running Prism reliably in production. None of these are technical requirements — Prism will run with the defaults — but operators serving real customers should treat the list as a baseline.

Security and Access

Mandate strong passwords and 2FA enrolment

Prism’s middleware already forces 2FA enrolment before any user can use the system. Combine that with a password policy that fits your environment (length, dictionary check, breach check) at the IdP layer if you front-end Prism with one. Don’t disable 2FA, even temporarily, even for “just” the admin account.

Run two admins minimum

Don’t operate Prism with a single admin. If that account loses access — lost authenticator, departed staff member, accidental disable — you’ll need a database-level intervention to recover. Promote a second trusted engineer in your team to is_prism_admin as soon as the primary admin signs in for the first time.

Rotate the seeded credential

The seeded admin email and password printed at install time are well-known to anyone who has read the install script. Change both before the first internet-routable DNS record points to the host.

Front Prism with TLS and a WAF

Run Prism behind a reverse proxy or load balancer terminating TLS with a publicly trusted certificate (Let’s Encrypt, your enterprise CA, or your CDN). Add a WAF — Cloudflare, AWS WAF, or similar — to filter common HTTP attacks before they reach the application.

Pin DNS with CAA records

A CAA record on your Prism hostname tells public CAs which authority is allowed to issue a certificate for that name. This blocks issuance from unauthorised CAs even if the rest of your DNS is briefly compromised.

Patch the OS, PHP, and database regularly

Subscribe to the relevant security feeds for your distribution, your PHP minor version, and your database (MariaDB or MySQL). A monthly patch window is reasonable; coordinate with your queue worker so a restart doesn’t lose in-flight jobs.

Monitor the access audit

Repeated permission denials from a single user or IP usually mean one of three things: the user is confused, the user’s tag mapping is wrong, or someone is probing. The first two are tickets you can resolve quickly. The third is a security signal worth alerting on. Schedule a weekly review of /admin/access-audit filtered to denials.

Enable exception alerts

Set up exception alerts during initial onboarding (Step 14 in Getting Started) and treat them as paging signals. Throttle to at least 15 minutes so a hot-loop bug doesn’t flood your inbox, but don’t suppress them. A silent exception is a silent customer impact.

Branding and White-Label Delivery

Decide your brand model up front

Two patterns work; pick one and stick to it:

Single-brand instance — Prism wears your brand across all customers. Simple, fast to set up, appropriate for a single enterprise IT shop.
Per-team override — each customer’s portal wears that customer’s brand. Required for MSPs delivering as a managed service. Set up the global brand as your fallback (so blank fields make sense).

Use SVG logos where possible

SVG scales cleanly across the sidebar, login screen, email headers, and favicons without pixel artefacts. Prism’s SVG sanitiser will reject anything with embedded scripts or external references, so export from your design tool with “no scripting” / “presentation attributes only”.

Test contrast

The brand-primary colour picker shows a WCAG contrast ratio against the background. Aim for 4.5:1 minimum (AA for body text); 7:1 if your customers include users with low vision. The picker recommends adjustments inline.

Keep support links accurate

Customer users see your support email and URL on every dashboard load. Stale contact info is one of the easiest avoidable causes of bad customer experience.

Customer Onboarding

Plan tag taxonomy in rConfig before mapping

Before you create your first Prism customer, decide on a tag scheme in rConfig. The cleanest pattern:

One customer-specific tag per customer (cust:acme, cust:globex, …).
Apply it to every device that customer owns.
Map only that tag to the customer’s team in Prism.

Layered tags (device-type, location, criticality) can coexist; just don’t use them as the customer scope. Keep the customer tag boring and stable.

Verify the mapping immediately after creating a team

After creating a team and mapping tags, sign in as the team’s primary contact (or impersonate a team member) and confirm the device list looks right. Catching an over-permissive mapping in five minutes is much cheaper than catching it in a security review six months later.

Use the per-team override sparingly when scaling

Per-team brand overrides are powerful but generate operational drag at scale — every customer’s brand pack needs to be kept in sync if their parent company rebrands. For a fleet of fifty customers, consider whether a single white-label instance under your brand serves the same value with less maintenance.

Lifecycle status reflects engagement state

Active — customer is paying and using.
Suspended — temporary lock; data preserved; user sign-in blocked.
Archived — engagement ended; team kept for audit history.

Use Suspended for billing or contractual issues you expect to resolve. Use Archived when an engagement is genuinely over. Don’t delete — you’ll lose the audit trail.

Tag Mappings

Fail closed by default

A new team has zero mapped tags and therefore zero visible devices. This is intentional. Don’t workaround it with a “default” mapping; create the mapping deliberately for each customer.

Avoid broad tags

Tags like production or core aggregate across customers. Mapping them to a customer team exposes far more than you intend. The customer-specific tag is the only mapping that should appear in Prism’s UI.

Audit mappings on a schedule

Quarterly or semi-annually, walk down /admin/tag-mappings and verify each customer’s mappings still match their contractual scope. Confirm the device count tracks reality (one customer with 30 listed devices and a contract for 20 is a billing question; one with 50 listed and a contract for 30 is a security question).

Retention

Pick retention windows that match your obligations

The defaults — 730 days for action audit, 90 days for access audit — are a reasonable starting point but not a recommendation for your jurisdiction or contracts. For GDPR-relevant deployments, document the retention rationale in your privacy policy and tune accordingly.

Don’t disable auto-purge unless you have an external archive

Setting retention to 0 keeps everything forever. That sounds like a feature, but it accumulates database bloat indefinitely and makes “give me everything about user X” data-subject requests slower over time. If you need permanent retention, export to an external SIEM or audit warehouse on a schedule and let Prism purge.

Test a manual purge before relying on the automatic one

The first time you trigger a manual purge, do it on a small date range (one day) and verify the row count drops as expected. Knowing the mechanism works under your eye is better than discovering surprises during a real retention crisis.

Mail and Notifications

Run a real queue worker

In production, QUEUE_CONNECTION=sync means every queued job runs inline — including mail. Move to redis or database and run Horizon (or php artisan queue:work under systemd / supervisor). This is the seventh task on the onboarding checklist for good reason.

Test mail end-to-end after every relay change

The “send test email” button in System Settings → Mail is the canonical smoke test. After any change to the SMTP relay, credentials, or DNS, fire a test and confirm the message lands. Don’t assume — verify.

A single recipient is a single point of failure. A distribution list ensures coverage when someone’s on holiday or has resigned.

Caching and Health

Watch the cache hit rate

The rConfig API request log shows a cache hit/miss flag for every call. A healthy steady-state Prism with a populated cache should run 70–95% hit rate depending on traffic. A sudden drop usually means a cache invalidation bug, a config change that flushed the store, or an unusual traffic pattern.

Tune circuit breaker settings to your upstream

The defaults (5 consecutive failures, 30-second cool-down) are tuned for a stable internal rConfig server. If your upstream is across a slower link or is a managed service with periodic 500ms blips, the defaults may flap the breaker too eagerly. Tune in config/prism.php and observe.

Don’t disable caching to “see fresh data”

Disabling the hot cache makes every page load hit rConfig directly, which doesn’t survive a brownout and quickly degrades performance under load. If you really need a fresh fetch, use the “Refresh” button on the affected screen — it bypasses the hot cache for that call only.

Monitoring and Observability

Schedule a daily eyes-on-glass

The admin dashboard surfaces enough signal that a five-minute check at the start of each day catches most emerging issues:

Open the dashboard.
Read the notifications panel.
Check the API failure count for the past 24 hours.
Glance at the activity feed for unexpected admin actions.

Wire critical signals to your existing monitoring

If you run Prometheus / Grafana / Datadog / NewRelic, scrape Prism’s queue depth, exception count, and API failure rate into the same dashboards as the rest of your platform. Treat exception-count > 0 as a paging signal during business hours.

Use system optimization as a checklist after upgrades

After any PHP upgrade or php.ini change, revisit /admin/optimization and confirm the row counts (green / amber / red) match what you expect. A new PHP version may ship a default that pushes a previously-passing setting into amber.

Disaster Recovery

Back up the Prism database

Prism stores its own state — users, teams, tag mappings, settings, brand assets, audit logs — in a database. Back it up on the same schedule as the rConfig database. A nightly logical backup retained for a fortnight is a sensible floor; daily snapshot to an off-site bucket is better.

Test restoration

A backup you’ve never restored is not a backup. At least once a year, restore Prism into a sandbox and confirm:

Sign-in works (you may need to reset your 2FA secret on the sandbox to avoid token mismatch).
The rConfig API connection works (assuming the sandbox can reach the upstream).
The audit log is intact.

Document the operator runbook

Keep a short, version-locked runbook for operators that covers: where Prism runs, how to start/stop it, where logs are, who to call for the upstream rConfig server, how to restore from backup. Stash it next to the runbook for the rConfig server itself.

Upgrades

Read the release notes, not just the version number

Prism tracks Laravel and Jetstream upstream versions. Major framework bumps occasionally need follow-up (e.g. PHP minimum version, queue worker compatibility). The release notes for each Prism version call this out — don’t skip them.

Stage in a non-production environment

A staging Prism pointed at a non-production rConfig (or a read-only mirror) is the right place to validate an upgrade. Walk through the onboarding checklist as a smoke test; if every task still passes after the upgrade, you’ve covered most of the surface.

Run database migrations on a maintenance window

Migrations are usually fast, but a long-running migration during a customer-visible window is a bad surprise. Schedule for off-peak.

Getting Started — Setup checklist that covers many of these as initial steps.
Admin Guide — Day-to-day operator workflows.
Troubleshooting — When best practices haven’t been enough.
In-app deep dives — /admin/docs inside your running Prism instance.