Find AKStream.Next raw logs and storage paths
This page helps deployment and operations teams locate AKStream.Next raw logs on Linux, Windows, macOS, and Docker, follow new entries, and decide whether to inspect application files or service-host logs.
This page lists the default paths created by the official installers. x64 and ARM64 use the same directories. If you changed the installation directory or the Serilog file path in
akstream.next.json, use the effective configuration of the running instance instead.Logs can contain device identifiers, private addresses, request parameters, and exception stacks. Redact them before sharing. Never publish database connection strings, passwords, tokens, secrets, or customer information.
flowchart LR
A[AKStream.Next main service] --> B[Daily application files]
A --> C[Standard output and error]
C --> D[Linux journald]
C --> E[Windows Event Log]
C --> F[macOS launchd files]
C --> G[Docker container logs]
Quick reference
AKStream.Next produces two kinds of logs:
- Application file logs are written by Serilog. A file is normally named
akstream-next-YYYYMMDD.log; size-based rolling can create additional numbered files for the same day. Use these files for historical queries and archiving. - Service-host logs receive standard output from the main service and NodeAgent. Inspect these first when initial setup is incomplete, configuration is invalid, or a process exits before file logging starts.
| Deployment | Main-service application files | Main-service and NodeAgent host logs |
|---|---|---|
| Linux x64 / ARM64 | /opt/AKStream.Next/AKStream.Next/logs/akstream-next-YYYYMMDD*.log |
systemd journal, read with journalctl or akn logs |
| Windows x64 / ARM64 | %ProgramFiles%\AKStream.Next\AKStream.Next\logs\akstream-next-YYYYMMDD*.log |
Windows Application event log, read with Event Viewer or akn logs |
| macOS Intel / Apple Silicon | /Library/Application Support/AKStream.Next/AKStream.Next/logs/akstream-next-YYYYMMDD*.log |
stdout and stderr files under /Library/Application Support/AKStream.Next/Data/Logs/ |
| Docker | /app/Data/Logs/akstream-next-YYYYMMDD*.log in the container and <deployment-root>/Data/Logs/ on the host |
Read with docker logs; the Docker logging driver controls the underlying storage path |
After initial setup, the generated main configuration enables both console output and daily rolling files. Before setup is complete, the daily file might not exist, so inspect the service-host log directly.
View logs on Linux
Linux x64 and ARM64 use the same default paths. With the official installer and default installation directory, application files are stored in:
/opt/AKStream.Next/AKStream.Next/logs/
List the available files:
sudo ls -lh /opt/AKStream.Next/AKStream.Next/logs/
Show the latest 500 lines from the main service and its managed MediaServer:
sudo akn logs -n 500 main
Follow the main-service log. Press Ctrl+C to stop:
sudo akn logs -f main
Follow only NodeAgent:
sudo akn logs -f agent
You can also query the systemd journal directly:
sudo journalctl -u akstream-next.service -n 500 --no-pager
sudo journalctl -u akstream-next-agent.service -n 500 --no-pager
sudo journalctl -u akstream-next.service -f
The systemd journal is not a plain-text log. With persistent storage enabled, its data is usually under /var/log/journal/; volatile storage normally uses /run/log/journal/ and may be lost after a restart. Do not edit these binary files. Use journalctl to export the required time range.
If you installed with --install-dir, the application-file path follows the program directory:
<custom-install-directory>/AKStream.Next/logs/
Read the effective systemd working directory to confirm it:
systemctl show akstream-next.service -p WorkingDirectory
View logs on Windows
With the default official installation, main-service application files are stored in:
%ProgramFiles%\AKStream.Next\AKStream.Next\logs\
List the files in PowerShell:
Get-ChildItem "$env:ProgramFiles\AKStream.Next\AKStream.Next\logs" `
-Filter 'akstream-next-*.log' |
Sort-Object LastWriteTime -Descending
Read or follow the latest main-service log with the management command:
akn logs -n 500 -LogScope main
akn logs -f -LogScope main
Follow only NodeAgent:
akn logs -f -LogScope agent
If the main service does not create a file or exits before file logging starts, open Event Viewer → Windows Logs → Application and inspect events from AKStream.Next or AKStream.Next.NodeAgent.
Older installations and custom Windows service hosts can resolve a relative log path against another working directory. For compatibility, akn logs selects the newest akstream-next-*.log from these trusted locations:
%ProgramFiles%\AKStream.Next\AKStream.Next\logs%ProgramData%\AKStream.Next\Logs%ProgramData%\AKStream.Next\Config\logs%SystemRoot%\System32\logs
If logs appear outside the default location, inspect the service command and main configuration instead of relying permanently on a compatibility directory.
View logs on macOS
macOS stores both main-service application files and the standard output and error captured by launchd.
Main-service application files are stored in:
/Library/Application Support/AKStream.Next/AKStream.Next/logs/
launchd logs are stored in:
/Library/Application Support/AKStream.Next/Data/Logs/
The directory contains:
akstream-next.stdout.log
akstream-next.stderr.log
akstream-next-agent.stdout.log
akstream-next-agent.stderr.log
Use the management command:
sudo akn logs -n 500 main
sudo akn logs -f main
sudo akn logs -f agent
You can also read the launchd files directly:
sudo tail -n 500 \
'/Library/Application Support/AKStream.Next/Data/Logs/akstream-next.stdout.log'
sudo tail -F \
'/Library/Application Support/AKStream.Next/Data/Logs/akstream-next.stderr.log'
When the service exits during initial setup, permission checks, or runtime loading, stderr often records the cause before the application file is available.
View logs in Docker
The main container stores application files in:
/app/Data/Logs/akstream-next-YYYYMMDD*.log
/app/Data is a bind mount for persistent host data. With the default deployment root, the host files are stored in:
~/AKStream.Next-Docker/Data/Logs/
If installation used --root, the effective host path is:
<deployment-root>/Data/Logs/
Show the latest 500 lines from all three containers:
docker logs --tail 500 akstream-next
docker logs --tail 500 akstream-next-agent
docker logs --tail 500 akstream-next-mysql
Follow the main container:
docker logs --follow --tail 500 akstream-next
Resolve the host directory mounted at /app/Data:
docker inspect akstream-next \
--format '{{range .Mounts}}{{if eq .Destination "/app/Data"}}{{.Source}}{{end}}{{end}}'
Show the Docker logging driver and underlying log path:
docker inspect akstream-next \
--format 'driver={{.HostConfig.LogConfig.Type}} path={{.LogPath}}'
On native Linux, the json-file driver normally stores container output at /var/lib/docker/containers/<container-id>/<container-id>-json.log. Docker Desktop keeps that directory inside its virtual machine. Do not edit, truncate, or delete the underlying JSON file. Use docker logs and configure Docker log rotation to control disk usage.
Confirm the effective path
Default paths apply only to configurations generated by the official installers. The Serilog File sink in the main configuration controls the final file location:
Serilog → WriteTo → Async → configure → File → Args → path
The default value is:
logs/akstream-next-.log
This relative path is resolved from the effective working directory of the AKStream.Next main service. The official Docker configuration uses the absolute path /app/Data/Logs/akstream-next-.log.
Inspect only the Serilog section when checking this setting. Do not paste the complete configuration into chats, tickets, or screenshots because the same file can contain database passwords and MediaServer secrets.
Verify that you found the correct log
All three conditions should be true:
- The last modification time is close to the current server time.
akn logs -f,journalctl -f, ordocker logs -fcontinues to show new entries from the current instance.- The node ID, cluster ID, and version in the log match the current instance shown by
akn info.
If the service cannot start, preserve the earliest exception, the complete stack trace, and at least 50 lines of surrounding context. Do not keep only the last line, delete the logs, or repeatedly reinstall first.
Next: Manage services with akn. If you have the logs but still cannot locate the failing layer, use the problem finder.