rConfig Vector Prism – Getting Started

Getting Started with rConfig Vector Prism: First-Day Setup for Operators

This guide walks Vector Prism operators through the work needed to take a fresh install from a blank dashboard to a production-ready, customer-facing platform. The same checklist is built into the admin dashboard as a gamified card — you can follow that on-screen, or use this page for a single scrollable reference.

Before You Begin

You should have:

A running rConfig server (v8 or compatible) with API access enabled and an API token to hand.
An SMTP relay (host, port, credentials, encryption mode) for outbound mail.
A wildcard or specific TLS certificate for the Prism hostname.
A second person who can be promoted to a backup admin once Prism is up.
(Optional) Brand assets: logo SVG/PNG, primary colour, favicon, support email, support URL.

You will work through twelve setup tasks. Most auto-complete the moment Prism detects you’ve done them; a few are manual ticks for actions Prism can’t observe.

Sign in with the seeded admin email and password from your install. Immediately change both, ideally to a credential set held in your password manager. The seeded values are well-known; an internet-facing instance with default credentials is an open door.

Then, in your password manager, store both the credential and the recovery codes you’ll generate in Step 2.

Step 2 — Enrol Two-Factor Authentication

Every Prism user must enrol TOTP-based 2FA before they can use the system. The middleware redirects you to the 2FA challenge page on first login.

Open your authenticator app (Authy, 1Password, Google Authenticator, Microsoft Authenticator).
Scan the QR code shown on the 2FA enrollment page.
Enter the 6-digit code to confirm.
Download or print the recovery codes. Each is single-use; you’ll need one if you lose your authenticator.

Step 3 — Customize Branding

Open Brand Settings (sidebar → Admin & Settings → Brand settings). The branding you set here applies to every login screen, every portal page, and every email Prism sends — unless a per-team override applies.

Set, at minimum:

Instance name — appears in the browser title and email subject lines.
Logo (light + dark) — shown in the sidebar and on the login screen.
Favicon (light + dark) — browser tab icon.
Primary colour — the brand-primary token used across buttons, badges, and links. Prism shows the WCAG contrast ratio against the background as you pick.
Support email and URL — exposed to customer users on the portal dashboard and footer.
Footer text — your legal name and copyright line.

Save. The change is immediate; no rebuild required. A live preview shows the login screen and a dashboard tile with your changes applied.

If you’re an MSP and you want each customer to see their own branding instead of yours, also tick Enable per-team branding override. You’ll set per-customer branding later when you create their team.

Step 4 — Configure Mail Server

Open System Settings → Mail Server. Prism uses your SMTP relay for invites, password resets, 2FA reset notifications, account lockout warnings, and exception alerts.

Fill in:

Host, port — your SMTP relay endpoint.
Encryption — tls, ssl, or starttls to match your relay.
Username, password — relay credentials. The password field is write-only; leave blank on subsequent saves to keep the stored value.
From address, from name — what customers see in their inbox.

Save, then click Send test email. Prism will queue a branded test message to your admin email address. If it arrives, you’re done. If it doesn’t, check the Exception Logs page — failed mail attempts log there with the underlying error.

Step 5 — Connect to the rConfig API

Open System Settings → rConfig API. This is where Prism learns where your rConfig server lives.

Fill in:

Base URL — the FQDN of your rConfig server, without any path. Example: https://rconfig.example.com. The form will reject anything that includes /api/... — Prism stores the host only and resolves API paths from a versioned registry, so it can target both v1 and v2 endpoints from the same base.
API token — generated in rConfig under your user’s API tokens screen.
Verify TLS — leave on for production; disable only for an internal lab with self-signed certs.

Save, then click Test rConfig. The probe hits rConfig’s /api/v2/dashboard/health-latest endpoint and reports green/red plus response time. If it’s green, the connection works and the sidebar’s clock widget will start showing the rConfig server’s wall clock alongside Prism’s.

Step 6 — Set Locale and Timezone

Open System Settings → Locale & Time.

Locale — pick a BCP-47 locale (en-US, de-DE, fr-FR, ja-JP, etc.). This formats dates, numbers, and times across the UI and audit logs.
Timezone — pick the IANA timezone (Europe/London, America/New_York, Asia/Tokyo, etc.) you want timestamps rendered in.

Defaults are en-US / UTC. The setting is instance-wide — it applies to every user. There’s no per-user override by design: an operator screenshot of the audit log should match what every other operator sees.

Once saved, click the clock widget at the top-left of the sidebar to confirm the time matches your wall clock.

Step 7 — Verify the Queue Manager

Prism queues every mail dispatch and several other long-running jobs. In production you need a queue worker running.

Use whichever of these is appropriate for your install:

Horizon (recommended): visit /horizon in your browser. The dashboard should show jobs being picked up. The sidebar has a “Horizon” link under Admin & Settings.
Plain queue worker: run php artisan queue:work (or set up a systemd unit / supervisor) on the Prism host.

If you skip this, mail will sit in the queue and never go out. The onboarding checklist marks this task as manual — tick it once you’ve confirmed the worker is running.

Step 8 — Run System Optimization

Open System Optimization. Prism reads your PHP runtime configuration and scores each setting against production recommendations: opcache, JIT, memory limit, max execution time, post max size, realpath cache, and so on.

Walk down the list. Each row is green (pass), amber (warn), or red (fail). For each amber or red row, follow the linked doc and adjust your php.ini, then reload PHP-FPM and refresh the page.

Tick the onboarding task once you’ve reviewed the list. You don’t need to be 100% green for development, but for production you should be — particularly opcache and memory limit.

Step 9 — Review Operator Security Hardening

Open /admin/docs → Onboarding → Operator Security. This is a hardening checklist for the host running Prism. Topics include:

Enforcing TLS at your reverse proxy or load balancer.
Putting Prism behind a WAF (Cloudflare, AWS WAF, or similar).
Tightening DNS/CAA records to your certificate authority.
Patching the OS regularly (OS, PHP, MariaDB/MySQL).
Enabling exception alerts (Step 11).
Monitoring access audit for repeated permission denials.

Tick the task when you’ve worked through it. There is no automated check — this is a manual operator review.

Step 10 — Create Your First Customer Team

Open Customers (sidebar → Customers & Teams → Customers) and click Create customer.

Name — the customer’s company name (or a project label if they have multiple teams).
Primary email — the contact address for that team.
Status — leave as Active.
Notes — any internal notes about the engagement.

Save. The team now exists but has no users and no devices. The next two steps fix that.

Step 11 — Map Tags for the Customer

Open Tag mappings (sidebar → Customers & Teams → Tag mappings) and click into the customer team you just created.

You’ll see two panels:

Available rConfig tags — fetched live from your rConfig server (cached for five minutes). Use the search box to filter.
Mapped tags — tags currently bound to this customer.

Click Add on each tag the customer should be allowed to see. The customer’s portal will only surface devices that carry one of these tags. If the mapping is empty, the customer sees zero devices — Prism fails closed.

Step 12 — Invite the Customer’s First User

Back in the customer team’s detail page, click Invite user.

Email — the user’s email.
Role — typically the team’s primary contact, who’ll be able to invite the rest of the team themselves.

Save. Prism queues an invitation email with a 24-hour signup link. The user clicks the link, sets a password, enrols 2FA, and lands on the portal dashboard scoped to their team’s tags.

Step 13 — Promote a Backup Admin

Don’t run a single-admin Prism instance in production. Open Users, find a trusted second engineer, and toggle Is Prism admin. They’ll see the admin sidebar on next sign-in.

Tick the corresponding onboarding task.

Step 14 — Enable Exception Alerts

Open System Settings → Exception Alerts.

Enabled — on.
To address — your operator distribution list.
HTTP statuses to alert on — typically 413,500,502,503,504.
Throttle — at least 15 minutes, so a noisy bug doesn’t flood the inbox.

Save, then click Send test exception alert. A mock alert email should arrive. From this point on, any unhandled error matching the status filter triggers a queued email with the stack trace and request context.

You’re Production-Ready

When all twelve onboarding tasks show green on the dashboard, the checklist celebrates with a “production ready” banner. From here, day-two operations live in Admin Guide, and a curated catalogue of tunables and recommendations lives in Best Practices.

Overview — What Prism is and how it fits into the rConfig stack.
Admin Guide — Day-to-day operator workflows.
Key Features — Feature catalogue.
Best Practices — Hardening, retention, and operations advice.
Troubleshooting — Common issues during setup and beyond.