Server Configuration

Authentication, security, and server management

Server configuration is stored in the .env file. Changes saved here are reference values — update .env and restart the server for changes to take effect.

Authentication & Security

Access token lifetime (300–86400 seconds / 5min–24hr)
Refresh token lifetime (1–30 days)
Failed attempts before account lockout
Time window for rate limiting (60–3600 seconds)

Server Settings

Requires server restart

Session Management

How often to clean expired sessions (1–168 hours)

AWS Configuration

AWS credentials and infrastructure settings

AWS credentials are stored in environment variables. Restart required after .env changes.

AWS Credentials

Configured via environment variable (AWS_ACCESS_KEY_ID)
Configured via environment variable (AWS_SECRET_ACCESS_KEY)

CloudFront Settings

CloudFront distribution for HLS proxy stream delivery
Changes to AWS settings require a server restart. Update the .env file for persistence.

SSO Configuration

Configure SAML 2.0 and OpenID Connect identity providers

Identity Providers

Loading...

How SSO Works

  • When an SSO provider is enabled, a login button appears on the login page
  • Users are redirected to the identity provider to authenticate
  • New users are auto-provisioned with the mapped role (or default role)
  • SSO users cannot use password-based login
  • For SAML: download the SP metadata from the provider detail view
  • For OIDC: use the callback URL shown in the provider detail view

Connecting Okta via OIDC

Step-by-step guide to connect Okta as an OpenID Connect identity provider.

Step 1: Create an App Integration in Okta
  1. Log in to your Okta Admin Console
  2. Navigate to Applications → Applications → Create App Integration
  3. Select OIDC - OpenID Connect as the sign-in method
  4. Select Web Application as the application type
  5. Click Next
Step 2: Configure the App Integration

Set the following values:

  • App integration name: MediaLive Nexus
  • Grant type: Authorization Code (default)
  • Sign-in redirect URI: https://<your-domain>/auth/sso/oidc/callback
  • Sign-out redirect URI: Leave empty
  • Controlled access: Select which users/groups should have access

Click Save.

Step 3: Collect the Credentials

From the app's General tab, copy:

  • Client ID
  • Client Secret

Issuer URL: Go to Security → API → Authorization Servers and copy the Issuer URI.
Default: https://dev-12345678.okta.com/oauth2/default

Step 4: Configure Group Claims (for role mapping)

To map Okta groups to roles, add a groups claim:

Option A — Via App Settings:

  1. In the Okta app, go to Sign On → OpenID Connect ID Token
  2. Under Groups claim type, select Filter
  3. Claim name: groups, Filter: Matches regex .*

Option B — Via Authorization Server:

  1. Go to Security → API → Authorization Servers → default → Claims
  2. Add Claim: name groups, include in ID Token + Access Token, value type Groups, filter regex .*
Step 5: Add the Provider in MediaLive Nexus
  1. Click "+ Add Provider" at the top of this page
  2. Set Display Name to Okta
  3. Set Protocol to OpenID Connect (OIDC)
  4. Paste the Issuer URL, Client ID, and Client Secret
  5. Set Scopes to openid profile email groups
  6. Choose a Default Role and optionally add Group → Role Mappings
  7. Check Enable this provider, then Save
Step 6: Test the Connection
  1. Click the Test button on the provider card above
  2. If successful, the OIDC discovery document was fetched
  3. Open the login page — a login button should appear for the provider
  4. Click it to verify the full authentication flow
Troubleshooting
  • invalid_client — Double-check Client ID and Secret. Regenerate in Okta if needed.
  • redirect_uri_mismatch — Sign-in redirect URI must match exactly: https://<your-domain>/auth/sso/oidc/callback
  • No groups in token — Verify the groups claim is configured (Step 4) and the groups scope is included.
  • SSO button missing — Make sure the provider is enabled.
  • BASE_URL mismatch — The server's BASE_URL env var must match your domain exactly.

Database Backups

Manage database backups with automatic daily scheduling and manual triggers

Create Backup

Create a manual backup of both databases. Includes user accounts, settings, Kinetica templates, library metadata, reference data, and all saved configurations.

Available Backups

Last 7 backups are retained. Daily automatic backups run at 3:00 AM.

Filename Size Created Actions
Loading...

Server Failover

Active-passive failover between primary and backup EC2 instances

Current Status

Setup Guide

Step-by-step guide to configure active-passive failover between two EC2 instances.

How It Works
  • Primary runs all services normally and uploads SQLite database snapshots + a heartbeat file to S3 every 15 seconds
  • Backup polls the primary's health endpoint every 3 seconds. It pre-downloads DB snapshots to stay warm
  • After 3 consecutive health check failures, the backup checks the S3 heartbeat. If stale (>30s), it promotes itself
  • Promotion downloads the latest DBs, reinitializes them, reassigns the Elastic IP, and starts all services (~1 second)
  • Clients (overlays, dashboards, automation) reconnect automatically via the Elastic IP
  • Split-brain prevention: when the old primary recovers, it reads the S3 heartbeat. If another instance owns it, it starts as backup
Step 1: AWS Resources
  1. Elastic IP — Allocate one in EC2 → Elastic IPs. Associate it with the primary instance. Note the eipalloc-xxx allocation ID
  2. S3 Bucket — Create a bucket in the same region (e.g. mlnexus-backup). No public access needed
  3. IAM Role — Create an instance role with S3 read/write (s3:GetObject, s3:PutObject, s3:ListBucket) and EC2 EIP permissions (ec2:DescribeAddresses, ec2:AssociateAddress, ec2:DisassociateAddress). Attach to both instances
Step 2: Backup Instance
  1. Launch a second EC2 instance (same type as primary, same VPC/subnet)
  2. Install Node.js 20: curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - && sudo apt install -y nodejs
  3. Install nginx, PM2, and clone the repo: sudo apt install -y nginx && sudo npm install -g pm2 && git clone <repo> ~/nexus && cd ~/nexus && npm install
  4. Copy the nginx config and SSL certs from the primary
  5. Copy the .env from the primary, then change the failover vars (see Step 3)
Step 3: Environment Variables

Add to the primary's .env:

FAILOVER_MODE=primary
FAILOVER_S3_BUCKET=mlnexus-backup
FAILOVER_PARTNER_URL=http://<backup-private-ip>:8080/health
FAILOVER_ELASTIC_IP_ALLOC_ID=eipalloc-xxxxxxxxx

Add to the backup's .env:

FAILOVER_MODE=backup
FAILOVER_S3_BUCKET=mlnexus-backup
FAILOVER_PARTNER_URL=http://<primary-private-ip>:8080/health
FAILOVER_ELASTIC_IP_ALLOC_ID=eipalloc-xxxxxxxxx
Step 4: Security Groups

Both instances need port 8080 TCP open from the partner's private IP (for health check polling). Add inbound rules:

  • Primary SG: allow TCP 8080 from <backup-private-ip>/32
  • Backup SG: allow TCP 8080 from <primary-private-ip>/32
  • Both: 80/443 TCP from 0.0.0.0/0 (nginx), 22 TCP from your IP (SSH)
Step 5: Start & Verify
  1. Start the primary first: pm2 restart all. Wait for "Sync complete" in the logs
  2. Then start the backup: pm2 restart all. It should log "Starting in BACKUP mode"
  3. Return to this page — the status tiles above should show Role: PRIMARY, Partner: Healthy
  4. Test failover: stop the primary (pm2 stop all). Within ~9 seconds the backup should promote and the site stays live
Optional: Tuning
FAILOVER_SYNC_INTERVAL_MS15000DB upload frequency (min 5000)
FAILOVER_HEALTH_INTERVAL_MS3000Health poll frequency (min 1000)
FAILOVER_DEAD_THRESHOLD3Missed checks before promotion
FAILOVER_HEARTBEAT_STALE_MS30000Heartbeat age before considered stale
Troubleshooting
  • Partner shows "Down" — Check that port 8080 is open between instances. Test with: curl http://<partner-ip>:8080/health
  • Backup keeps trying to promote — The primary isn't running or hasn't written a heartbeat to S3 yet. Start the primary first
  • EIP reassignment fails — Check that the IAM role has ec2:AssociateAddress and ec2:DisassociateAddress permissions
  • SSH disconnects after failover — The EIP moved. Clear the old host key: ssh-keygen -R <eip>, then reconnect
  • Both instances in backup mode — Promote one manually via the button above or API: POST /api/failover/promote

AI Assistant

Configure the Claude AI integration for the Kinetica template builder

Claude API Key

Enter your Anthropic API key to enable the AI assistant in the builder. The key is stored server-side and never sent to the browser.

Model

Select which Claude model to use. Sonnet is recommended for most tasks — fast and precise. Opus is slower but more capable for complex template generation. Haiku is fastest and cheapest for simple edits.

User Management

Create, edit, and manage user accounts

-
Total
-
Admin
-
Manager
-
Operator
-
Viewer

Users

Username Full Name Email Role Last Login Status Actions
Loading...

Role Management

Configure roles with custom permission sets

Roles

Name Description Level Permissions Users Type Actions
Loading...

Audit Log

View all administrative actions and system events

Time User Action Resource Details IP
Loading...
Page 1

Native Renderer

Download and manage the Kinetica native renderer for HDR fill+key output via NDI, OMT, or SDI

Download Installer

Install the native renderer on your render machine. It will connect to this Nexus server and output graphics via NDI, OMT, or DeckLink/AJA SDI.

Version: —

Connected Instances

Active renderer instances connected to this server

Hostname IP Pipelines Output Mode Version Uptime
No connected instances

Default Configuration

Default settings baked into new renderer installations