AKStream.Next · 文档中心

Pre-deployment Planning

Pre-deployment Planning

This page is used for pre-installation review. Create an actionable deployment table before proceeding to the setup wizard.

flowchart LR
    A[Devices, concurrency, retention days] --> B[Size nodes, bandwidth, disks]
    B --> C[Choose single or multi-node topology]
    C --> D[List ports, domains, certificates, owners]
    D --> E[Install only after review]

Five Key Decisions

1. Deployment Topology

Scenario Recommended Starting Point Additional Confirmations Required
Demo, Development, Few Channels Single-machine All-in-One Data must be persisted; do not use temporary container directories for production
Single-site Production Control plane, MediaServer, and MySQL can be on separate disks or machines Recording disk throughput, backup windows, process supervision
Multi-site or Cross-network Control node + Multiple media nodes External media address per node, routing, clock synchronization, and failure domains
Existing independent media service AKStream.Next connects to a remote media node API secret, WebHook, version compatibility, and bidirectional reachability

Currently, it is not guaranteed by default that all tasks in a multi-instance Active/Active control plane can be consumed in parallel unconditionally, nor is it guaranteed that existing media sessions will migrate losslessly during a node failure. If high availability is required, first define how the database, control plane, and media plane will be recovered respectively.

2. Operating System and Architecture

Standard release targets include Linux x64/ARM64, Windows x64/ARM64, and macOS Intel/Apple Silicon. Business programs, MediaServer, and FFmpeg must match the target system and CPU architecture. For Linux ARM32 outside the standard package, you must perform your own release and prepare dependencies for the same architecture.

3. Database

The initial setup wizard allows configuration of MySQL, PostgreSQL, SQL Server, or SQLite; however, verification should still be performed based on the current version and site scale before formal deployment. Do not use single-machine file database sharing for production multi-node deployments. Prepare the following:

  • Database address, port, database name, and dedicated account;
  • Boundaries for database/table creation permissions and minimum runtime permissions;
  • Character set, time zone, connection limits, and backup strategies;
  • Actual network tests from the AKStream.Next host to the database.

Do not write passwords into deployment records, command history, or screenshots.

4. Storage

Separate the lifespans of different types of data:

  • Config and Data/Security: Small but critical; must be backed up with restricted permissions.
  • Database: Stores business truth, tasks, recording indices, and audits.
  • Recording root: Largest capacity; bytes, inodes, write latency, and growth rate should be monitored independently.
  • Clipping output: High temporary IO; set separate retention and cleanup policies.
  • Logs: Enable rotation and total size limits to avoid competing with recordings for system disk space.

Capacity estimation should not rely solely on multiplying the bitrate. Reserve overhead for the file system, segment peaks, index lag, temporary clipping space, and a safety margin.

5. Network and Domains

Map at least three types of access relationships:

  1. Administrator/Business system to WebUI/API;
  2. Cameras or upstream/downstream platforms to protocol and RTP ports;
  3. End players to HLS, FLV, RTSP, RTMP, or WebRTC addresses.

Reverse proxies only resolve HTTP/HTTPS/WSS; they do not automatically proxy SIP, RTP, RTSP, RTMP, and all WebRTC media. For details, see Ports, Domains, HTTPS, and NAT.

Capacity Baseline

Before deciding on CPU, memory, and disk, fill in the following metrics:

  • Number of managed channels, estimated simultaneous online streams, and peak new stream rate;
  • Number of concurrent viewers and the playback protocols used;
  • Number of concurrent recording sessions, average bitrate, segment duration, and retention days;
  • GB28181 registration volume, Catalog scale, and RTP port range;
  • RTC rooms, publishers, subscribers, and TURN relay ratio;
  • Intensity of protocol polling, events, WebHooks, recording scans, and log retention.

Perform benchmark tests using the target devices and target bitstreams. License quotas are business limits and do not equal server capacity.

Pre-installation Review Checklist

  • Stable node IDs, hostnames, time zones, and NTP have been determined.
  • Owners, backup, and recovery targets for the database and recording directories have been determined.
  • Source network segments, destination network segments, and protocols for required ports have been listed.
  • HTTPS certificates and domain paths have been determined; whether to deploy TURN for public network RTC has been decided.
  • Camera models, firmware, protocol versions, and test channels to be used have been prepared.
  • Backup locations for old packages, configurations, databases, and keys required for rollback have been determined.

Once completed, proceed to Install and Manage Services.